SeasonOfDocs: Difference between revisions
(→Yocto Project Season of Docs: added a "job description" section) |
|||
| (7 intermediate revisions by one other user not shown) | |||
| Line 18: | Line 18: | ||
* excellent written command of the English language | * excellent written command of the English language | ||
* | * you have experience as a writer, preferably writing technical documentation | ||
* able to distill "geek | * able to distill "geek gobbledygook" into simple and understandable prose | ||
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc) | |||
* ability to draw simple but meaningful diagrams, and incorporate them into your writing | |||
* strong ability to work with and use the Linux command-line | |||
* it would be very beneficial for this role to know how to use git, at least at a basic level | |||
* a "nice to have" skill would be the ability to read, run, and understand short snippets of python3 and shell code | |||
* another "nice to have" skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments | |||
* willingness to hang out in the #yocto channel on irc | |||
==Ideas== | ==Ideas== | ||
===Format Overhaul=== | ===Format Overhaul=== | ||
Currently the project's documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don't usually write project documentation to submit patches and updates. An | Currently the project's documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don't usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users. | ||
===One Voice=== | ===One Voice=== | ||
Previously the project's documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it's likely the project's documentation updates will | Previously the project's documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it's likely the project's documentation updates will come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. Currently there are no style guidelines for the project; establishing some written guidelines for that 'voice' may be part of this too. | ||
===Organization=== | ===Organization=== | ||
Currently the project's documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they're looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project's webmaster to present a unified location for all documentation. | Currently the project's documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they're looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project's webmaster to present a unified location for all documentation. Perhaps run a survey to poll users on their thoughts regarding the usefulness of the current documentation, and generate an actionable report. | ||
===Tips and Tricks=== | ===Tips and Tricks=== | ||
| Line 40: | Line 47: | ||
===How-to/Tasks Documentation=== | ===How-to/Tasks Documentation=== | ||
There was work started to convert some of the manual to a more task oriented/'how-to' approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete "how-to" task section. | There was work started to convert some of the manual to a more task oriented/'how-to' approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete "how-to" task section. | ||
===Better Layer Integration=== | |||
The Yocto project is organized as a "core" (which is maintained by The Yocto Project) and "layers" (which are maintained by volunteers). Creating an image for a specific device will often require information for the core and information from individual layer components. There is an opportunity to investigate how to incorporate documentation from various layer projects into a unified whole. | |||
Latest revision as of 23:43, 2 June 2021
Yocto Project Season of Docs
About
The Yocto Project is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the OpenEmbedded (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following core components. This video will help explain what it's all about.
Richard Purdie, the Yocto Project's lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project's tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.
Google Season of Docs
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.
Candidate Criteria
- excellent written command of the English language
- you have experience as a writer, preferably writing technical documentation
- able to distill "geek gobbledygook" into simple and understandable prose
- knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)
- ability to draw simple but meaningful diagrams, and incorporate them into your writing
- strong ability to work with and use the Linux command-line
- it would be very beneficial for this role to know how to use git, at least at a basic level
- a "nice to have" skill would be the ability to read, run, and understand short snippets of python3 and shell code
- another "nice to have" skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments
- willingness to hang out in the #yocto channel on irc
Ideas
Format Overhaul
Currently the project's documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don't usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users.
One Voice
Previously the project's documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it's likely the project's documentation updates will come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. Currently there are no style guidelines for the project; establishing some written guidelines for that 'voice' may be part of this too.
Organization
Currently the project's documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they're looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project's webmaster to present a unified location for all documentation. Perhaps run a survey to poll users on their thoughts regarding the usefulness of the current documentation, and generate an actionable report.
Tips and Tricks
The project started a TipsAndTricks project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.
Update/Release Process
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.
How-to/Tasks Documentation
There was work started to convert some of the manual to a more task oriented/'how-to' approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete "how-to" task section.
Better Layer Integration
The Yocto project is organized as a "core" (which is maintained by The Yocto Project) and "layers" (which are maintained by volunteers). Creating an image for a specific device will often require information for the core and information from individual layer components. There is an opportunity to investigate how to incorporate documentation from various layer projects into a unified whole.
