-
Notifications
You must be signed in to change notification settings - Fork 81
Adding Doc-as-code article #269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,70 @@ | ||||||||||||||||||||||
# Documentation as Code: A Comprehensive Study Guide | ||||||||||||||||||||||
**Presented by:** [Robert Krátký](https://github.com/rkratky) at Documentation Office Hours - ODH-015 | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion:
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
**Link to the video:** [Documentation as Code](https://www.youtube.com/watch?v=AVNfH99KiME) | ||||||||||||||||||||||
|
||||||||||||||||||||||
## What does "Docs as Code" mean? | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: |
||||||||||||||||||||||
Is a methodology that treats documentation like software source code, applying similar development practices to create and maintain documentation. | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion:
Suggested change
|
||||||||||||||||||||||
This approach emphasizes using specialized tools for different stages of documentation development. | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion:
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
### Key Characteristics of Documentation as Code | ||||||||||||||||||||||
The main difference between **Documentation as Code** and traditional documentation approaches is that instead of using a single monolithic system for the entire process, | ||||||||||||||||||||||
it employs specialized tools for each step of the documentation lifecycle. | ||||||||||||||||||||||
Comment on lines
+11
to
+12
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I would also swap "specialized tools for each step of the documentation lifecycle." by "specialized tools can be used to write, test, publish, or maintain documentation." because I don't want users to think that you have to use specialized tools at each step.
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
#### Tooling Components | ||||||||||||||||||||||
|
||||||||||||||||||||||
| **Goals** | **Tools** | **Reason** | | ||||||||||||||||||||||
|----------|----------|----------| | ||||||||||||||||||||||
| Content authoring | Text editors | Not binary format, quite easy to start | | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion:
Suggested change
|
||||||||||||||||||||||
| Formatting, styling | Markup languages | The formatting and styling is based in semanticity as oppossed to the formatting being applied directly to the content enabling multiple output formats | | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. typos and suggestion:
Suggested change
|
||||||||||||||||||||||
| Version control | Git, SVN, Mercurial, ... | Utilizes distributed version control systems like Git | | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I think we usually utilize one version control system.
Suggested change
|
||||||||||||||||||||||
| Issue tracking | JIRA, Bugzilla, Mantis... | Provides comprehensive change tracking capabilities | | ||||||||||||||||||||||
| Testing, validation | Scripts, linters, spell-checks | Inspired by software testing (like unit tests). When scripts or filters are applied, proper testing ensures reusable checks for content accuracy | | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I would also try to create only one concise sentence from those sentences: "Inspired by software testing (like unit tests). When scripts or filters are applied, proper testing ensures reusable checks for content accuracy". What do you think? |
||||||||||||||||||||||
| Publishing | Site builders, CMS, ... | Uses Site builders to produce web ready HTML or feeds content into CMS systems, mirroring software development workflows | | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I would go further than what Robert shared by explaining the reason behind using site builders.
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
## Benefits of Documentation as Code | ||||||||||||||||||||||
|
||||||||||||||||||||||
### Developer Perspective | ||||||||||||||||||||||
1. **Developer Familiarity & Confort:** Developers already know the tools (Git, scripting,etc) making it easier for them to contribute to documentation. | ||||||||||||||||||||||
2. **Higher Engament:** Documentation becomes a natural part of the project, encouraging developers to treat it seriously and make quick, one-off fixes. | ||||||||||||||||||||||
3. **Better Integration:** Documentation can be included in the "definition of done" ensuring it's part of product planning and validation, just like code. | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion:
Suggested change
|
||||||||||||||||||||||
4. **Shared Responsability:** QA teams and developers can validate documentation, fostering alignment and reducing the perception of docs as an afterthought. | ||||||||||||||||||||||
5. **Open Tooling Capabilities:** Using open source tooling for documentation promotes collaboration and consistency with the software development process. | ||||||||||||||||||||||
Documentation integrated into development workflow | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion:
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
Comment on lines
+26
to
+34
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very great section: well summarized and clear. Great work! |
||||||||||||||||||||||
### Organizational Benefits | ||||||||||||||||||||||
Using open source tooling (like plan text markup and version control) avoids vendor lock-in unlike proprietary tools, which risk obsolescense or abandonment. | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I would remove the tools in the parenthesis to make the sentence more concise. We already explained the different tools in details.
Suggested change
|
||||||||||||||||||||||
This approach also offers flexibility in migrating formats, reduces organizational overhead, and aligns processes across teams, | ||||||||||||||||||||||
enabling consistent automation and smoother coordination with software releases. | ||||||||||||||||||||||
Comment on lines
+37
to
+38
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I would separate the sentence into two shorter sentences to make the text easier to read.
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
## Challenges and Considerations | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This section is also very well done, with clear ideas and short explanations. What I really like about this section is that you make it easy for skimming (easy for the users to find information in the page). |
||||||||||||||||||||||
|
||||||||||||||||||||||
1. **Resistance to change:** Teams used to existing workfkows (especially monolithic documentation tools) may push back due to unfamiliarity with new tools or have steep learning curves. | ||||||||||||||||||||||
2. **Developer concerns:** Including documentation in the definition of done might slow down development agility and some developers may dislike increased visibility or accountability for docs. | ||||||||||||||||||||||
3. **Technical hurdles:** Migrating legacy documentation to plain-text markup can be non-trivial, and tight schedules may risk release disruptions during the transition. | ||||||||||||||||||||||
4. **Balancing Trade-offs:** While the benefits often outweigh these challenges, they must be carefully consideredes to ensure smooth adoption. | ||||||||||||||||||||||
|
||||||||||||||||||||||
## Additional Commentaries | ||||||||||||||||||||||
|
||||||||||||||||||||||
The docs as code approach offers key benefits like enabling documentation review in developers familiar environments (Github/Gitlab) and simpliying change tracking by keeping docs with code, | ||||||||||||||||||||||
but also presents challenges such as tying documentation to development cycles and release freezes, difficulty switching between markup languages, significant time spent on formatting issues, | ||||||||||||||||||||||
and the need for specialized tools that handle both writing and technical aspects effectively, potentially requiring dedicated staff for markup-related tasks despite its growing popularity. | ||||||||||||||||||||||
Comment on lines
+47
to
+51
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. typo and suggestion: I would improve it's clarity by making the sentences shorter. If you agree, I'll let you modify it!
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
### Branching and Versioning | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: This section could be a great fit for the "Challenge and considerations" section. What do you think? |
||||||||||||||||||||||
Documentation as code my not suit every situation, its strongest advantage is seamless integration with software development branches, | ||||||||||||||||||||||
Allowing documentation to evolve alongside code versions (e.g. maintaining separate docs for v1.0 fixes while developing v2.0). Key recommendations include using portable formats, | ||||||||||||||||||||||
familiar editors and version control to maintain flexibility This approach is better for collaborative developer documentation but may be less suitable for regulatory and marketing content | ||||||||||||||||||||||
requiring centralized technical writer control. The succesfull documentation as code implementation depends on team structure and documentation purpose, with its greatest value appearing in | ||||||||||||||||||||||
environments where developers actively contribute to documentation. | ||||||||||||||||||||||
|
||||||||||||||||||||||
### Automation Opportunities | ||||||||||||||||||||||
Also documentation as code enables valuable automation, particularly for autogenerated documentation that lives alongside the code. (e.g.incorrect autogenerated documentation actually | ||||||||||||||||||||||
can catch software errors before release). Also keeping documentation in the same repository as code significantly simplifies testing purposes and automation. | ||||||||||||||||||||||
Comment on lines
+60
to
+62
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: |
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
**Please also check:** | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: I would use the header "Next steps" which is commonly used throughout Canonical's documentation. We could also add a link to the next Documentation Community Hour (https://discourse.ubuntu.com/t/community-hour/42771). What do you think?
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
[Slide used in the video](https://docs.google.com/presentation/d/1R6N8rZbV1cfWAcyGep-p8pyylFAwWjfIYsONILRNm8M/edit?slide=id.p#slide=id.p) | ||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. typo:
Suggested change
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
# Explanation | ||
|
||
## Articles | ||
Provide concise summaries to topics presented in Documentation Office Hours. | ||
- [Documentation as Code](documentation-as-code) | ||
|
||
```{toctree} | ||
:hidden: | ||
:titlesonly: | ||
:maxdepth: 1 | ||
|
||
Documentation as Code <documentation-as-code> | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion:
To follow our style guide, all headings and headlines should be sentence case. Only the first letter of the first word should be capitalised, unless it is a product name like Ubuntu for example.