Google Summer of Code witnessed its 15th consecutive year encouraging students and organizations to delve into open source. Programs like GCI and GSoC are prodigious in the world of open source and yet again Google is back with another mentoring program, GSoD (Google Season of Docs) that is, GSoC for documentation, as you may call it.
“Ink is better than the best memory”. This Chinese proverb correctly articulates the importance of documentation. A module without documentation is not only harder to maintain but also serves as a blockade during the knowledge transfer. GSoD aims to draw together the open source communities and the technical writers, which ends up in both the parts profiting immensely. GSoD will be a great exposure to the world of open source for the technical writers and vice versa. Google also makes sure that the writers are treated with a handsome stipend for a 3 month long commitment. Documentation still occupies a dark spot even in the biggest of all code bases. GSoD here, will spread a lot of awareness about technical writing and documentation. The technical writers are desired to work with the organization for 3 months wherein they’ll bring in there expertise along with the guidance by the open source community and render some useful text.
Interested organizations were required to put in an application to be a part of the program. The final list was out by the end of April. BRL-CAD emerged as one of the mentoring organizations. Talking of BRL-CAD, it is a powerful cross platform open source solid modeling system widely used for a variety of engineering and graphics applications. The documentation and the data files here are either in the public domain or a part of the modified BSD license family. BRL-CAD originated at the Ballistic Research Laboratory, hence the acronym “BRL”. Later on BRL was absorbed into the U.S. Army Research Laboratory, but continued with the original name.
This is a spiffing opportunity to get to know more about the open source organizations for the technical writers, especially those who’ve never dived into the world of open source formerly. The developers too get to scout out the documentation side of the codebase. The org list is already made public by Google. Now it is the time for technical writers to explore the projects. Discussions with the community regarding the ideas is highly appreciated. Regarding the project ideas, an org may either decide to build a new documentation base or may refurb the existing support.
Documentation is the most neglected aspect of a code base. Technical writers have an expertise in structuring the documentation that’ll make it easier for people to understand the modules and be a part of the organization. The manner of documentation which fits best for an audience is also a major strand that technical writers are proficient to handle.The project ideas enlisted by BRL-CAD are present on the wiki. The projects are rated according to their difficulty level ranging from easy to hard. So we’ve got some projects that are as easy as they sound. Now if you as a writer want an additional “kick” in your life, you can always opt for some hard difficulty project. For a start, interested people can go through the guide which we call as “HACKING BRL-CAD” doc. This is the bible of documentation here at BRL-CAD.
BRL-CAD was a part of the Google Summer of Code Doc Camp back in 2013. Our community members got together in California and came up with the “HACKING BRL-CAD” within a few days. This doc introduces and guides all the new contributors be it developers, writers or artists with all the information required to set an inertia. Coming back to GSoD, we have migrated to Zulip for our irc based needs. All discussions related to the community find their place here. Newbies are welcome to this channel, we’ll be using the Google Season of Docs stream under the channel. All project related queries, suggestions and discussions can be brought up here, we’ll be more than happy to interact with you all. Interested peeps can also communicate via our mailing list. An introduction along with the prospective interests should serve as an icebreaker here at the communication platforms. We’ll help you align your interests and shape your proposal based on the interests and the project requirements.
The writers are expected to come up with some writing samples that will in turn help the mentors in choosing the right candidate. Remember, the ideas mentioned on the project ideas page are just a headline i.e. kind of rough ideas. The writers are welcome to expand upon the idea or even refine it after discussions with community. Here we have some guidelines for the application which are meant for the Google Summer of Code basically but should behave similarly for the Season of Docs as well.
The application period starts from May 29 and goes on till June 28. The writers would be required to prepare a proposal on the same lines as that of GSoC. Prior to that, writers are free to interact with the community and discuss the plan of action. Accepted projects come out of the dark on July 30. Writers are encouraged to keep on contributing after submission of the applications. Google Season of Docs is indeed a great opportunity for the technical writers as well as the open source communities. The 3 month long program will not only produce some rich documentation but will also be really good learning experience for both the writers and the open source community. Although the program is limited to 3 months but that should not stop the writers to contribute to the organization after the period gets over. As an open source organization we always encourage people who want to make a contribution, be it big or small.
My final dig at the selection procedure; For a successful application, the writers should ensure that they get involved early and work on the details of the idea in depth. Regarding the proposal, it should lie within this world. There is no point mentioning some sheer futuristic things that are too unrealistic to handle. Plus the scope should be limited, it should justify the time period of 3 months. We are not here to enlist things that surely won’t be put to closure by the end of the time period. Mention enough content to be completed in the given time. While drafting the proposal a tentative schedule for 3 months arranged in a timeline will be highly appreciated. Most importantly this is not a one man journey, the mentors will always be there to assist the writers. “We’ll turn the code into documentation”.
Some tips by Gabbar