Program announced. See timeline.
Below are some ideas of the type of project that a technical writer can tackle:
Build a documentation site on a platform to be decided by the technical writer and open source mentor, and publish an initial set of basic documents on the site. Examples of platforms include:
Refactor the open source project's existing documentation to provide an improved user experience or a more accessible information architecture.
Write a conceptual overview of, or introduction to, a product or feature. Often a team creates their technical documentation from the bottom up, with the result that there's a lot of detail but it's hard to understand the product as a whole. A technical writer can fix this.
Create a tutorial for a high-profile use case.
Create a set of focused how-to guides for specific tasks.
Create a contributor’s guide that includes basic information about getting started as a contributor to the open source project, as well as any rules around licence agreements, processes for pull requests and reviews, building the project, and so on.
The above ideas intentionally vary in scope and size. The length of time that any project takes depends on a number of factors, including the size of the documentation set, the complexity of the product, the experience of the technical writer and open source mentors, the tools and processes offered by the open source project, and more.
The goal of the above list is to get you started. You can propose other types of projects too.
Creating your own list of project ideas
When you compile your own list of project ideas to submit to Season of Docs, you must provide more specific information than the above list provides. Your ideas list should include at least the following:
- Describe and link to the open source project that needs documentation.
- If you're proposing a technical writing project that involves updates to an existing documentation set, link to that documentation set.
- If you're proposing a tutorial or a set of how-to guides, describe the features or use cases that need documenting.
- If you're proposing a contributor's guide, link to any existing README file or other relevant material if present. If there's nothing available yet, it's fine to say that.
- This video from PyCon Australia 2017 gives hints about organizing your documentation so that people find it useful: What nobody tells you about documentation by Daniele Procida.