Canonical uses the time after a major release for internal planning. Our own plans as technical authors are no exception to this. And one of the main things we want to do is plan for the next phase of the Open Documentation Academy.
We’ve been overwhelmed by the support so far, but we know it’s essential for the long-term success of the idea that we build upon this to create a solid foundation for the future of the project (too many building metaphors), and this is what we want to try and do over the next six months.
Here are some of the things we’ve been thinking about:
- Inviting more projects to take part
- Making our Documentation Office Hours a little more professional and organised, including a schedule of times and topics, and better production.
- Starting a podcast to cover the kind of subjects we typically encounter with technical documentation
- Add significantly to our task list, and make the list more diverse
- Hosting a documentation summit
- Talking at conferences
We’ll be discussing these things internally over the next 2-3 weeks, but we really want your feedback too.
If there’s anything you think we could improve (there’s a lot, we know, but please let us know), any ideas you’d like us to incorporate, any projects you’d like us to invite - please, leave a comment below.
We’ll consider every proposal, and keep everyone updated through our Office Hours and when we publish our plans.
Thanks for all your support.
6 Likes
On the topic of a podcast, or perhaps “video podcast”…one thing I think is always helpful is to see how someone with facility in a topic does the actual work - not only describing the process and thought behind it, but doing so while actually demonstrating it.
It could be valuable to take a small issue from the task list and walk through the start-to-finish of both the process pieces (mostly the GitHub parts, I imagine) and the writing pieces (what does the process of writing out steps, capturing screenshots, etc., look like?).
Just a thought - I know many learn by just diving in and doing, but if there are others out there like me who learn best from first observing someone successful, then trying to repeat their steps, then trying to make it my own, perhaps that could be a reference to help more folks get over the initial hump of contributing?
2 Likes
Hey @degville!
Here are some thoughts after attending most of the office hours and working on a few issues:
-
More “day-in-the-life of the Docs team” sessions: I enjoyed seeing how the Docs team uses Jira (never thought I would use ‘enjoy’ and ‘Jira’ in the same sentence 
). I would be interested in seeing more sessions on how the Docs team works together, maybe even how the planning of this next phase of ODA is done.
-
Tools of the trade: Somewhat related to the point above, what tools do the Docs team and participating projects use? This could range from IDE and CLI customizations to CI/CD and testing.
-
Overviews of the participating projects: I find it takes a bit of bootstrapping to work on the docs for a tool that’s new to me. There were a handful of issues I was interested in, but decided against working on them seeing that it would take me some time to get up-to-speed on the topic. A crash course on what a technical author needs to know about a participating project would be very helpful. Are there any technical enablement materials that can be shared with ODA contributors?
To the points you listed above:
- Yes to more projects!
- Yes to a schedule of times and topics. I appreciate the current level of professionalism on the calls. I wouldn’t want them to be too much like webinars. I’m not often an active participant, but I like knowing that I can be.
- Agreed with @johnandmegh on videos rather than a podcast.
- Yes to more, and more diverse, tasks. They go fast!
- Yes to a summit, if it’s virtual
- Speaking at conferences would help get more ODA contributors and possibly expand the project
Kudos to you and the team. I appreciate how open it is. I’m learning a lot and looking forward to the next phase. Keep up the good work!
1 Like