Season of Docs Ideas 2019
From simple to grandiose writing tasks which will improve OSGeo projects, and open source in general. It includes ideas and first steps for tech writers and software users who are considering giving back to open source projects.
Reading time: 10 minutes
We, the communities behind the OSGeo Foundation open source geospatial projects, are well positioned to help solve big documentation challenges faced by all open source projects. We can achieve this by continuing as we are doing now, with ordinary people, gifting small bursts of effort, toward small, discrete and achievable tasks, to collectively achieve an extraordinary impact.
Here we have collated documentation ideas for:*
- Technical writers who have been asking about documenting open source, some of whom are involved in the Google Season of Docs.
For background on the value of communicators, along with ideas on the sort of communities that have proven to be successful in the past, we suggest starting with this article on inspiring techies to become great writers.
We propose to focus on one (or more) writing initiatives, for one of our leading OSGeo projects. Goals should focus on:*
- Be captured as a template, which can be easily applied to other OSGeo projects. Ideally this will grow into an initiative which is of value to all open source projects.
- Engages a Season of Docs sponsored writer, along with volunteers from project and writing communities.
How to get involved:*
- As someone keen to give back to open source through docs, volunteer to be mentored, and tackle writing initiatives we work on.
- As an engaged OSGeo community member, volunteer to act as an administrator of the program.
*
- Astrid Emde: Senior GIS consultant at WhereGroup in Bonn, Germany. OSGeo board member and secretary. Awarded the Sol Katz award for leadership and longtime contributions to open source geospatial communities. Contributor to OSGeoLive, the OSGeo marketing committee and co-coordinator of meetups, corde-sprints, and the annual German speaking open source geospatial conference. She likes documentation and teaching people OSGeo Software. Keen to provide connections to our community and to be practically involved in writing initiatives.
- Johanna Boltman: Ex-English teacher, IT admin, and user of open source software as a geospatial officer at a local council. Keen to be mentored in writing docs.
- Belinda Baker: Background in writing process documentation and user of open source software as a GIS Consultant at a software company. Keen to be mentored in writing docs.
- Liam Turner: GIS Specialist for NSW Government (Australia), previously a high school physics teacher. User of open source technical documentation, keen to make a contribution.
- Nicolas Roelandt: Geospatial engineer at the French Institute of Science and Technology for Transport, Development and Networks. OSGeo charter member and OSGeoLive Project Steering Committee (PSC) member. Works on OSGeoLive documentation and translation build process (using Transifex platform). Keen to support others in the use of these tools.
- Luca Delucchi: Geographer; OSGeo and Open Street Map contributor and advocate. Core developer and translator of the GRASS GIS project; main developer of pyModis library; OSGeoLive and ZOO-Project contributor; president of the Italian OSGeo local chapter. Willing to help improve Jupyter interactive notebook documents in line with a developed template and writing instructions, if one is developed and committed to.
- Ok, I'll try to write to you ASAPHi Sergio, great to have you add your name. Thanks. Have you thought about how you would like to get involved? I'm hopeful to hear long hand how that might be (maybe in an email), and then we can make it concise here. (Later, lets come back and trim this personal description. so we can keep the word count down. "Less words get read more.")Sergio Acosta y Lara: Architect (Universidad de la República/UdelaR) working with Geographic Information Technologies for nearly 30 years. In charge of the Department of Geomatics (Ministry of Transport and Public Works) and member of several Working Groups for Technical Specifications of the IDEuy (Spatial Data Infrastructure of Uruguay). Charter Member of the OSGeo Foundation (Open Geospatial Foundation) and member of the Advisory Board of the Geo4all initiative, Regional chair for Iberoamerica and co-editor of its newsletter. Coordinator for gvSIG Batoví (design and development of a GIS applied to educational environments for the Plan Ceibal (OLPC initiative for Uruguay) based on gvSIG. Co-coordinator of the gvSIG Uruguay Community (web) and of its blog.
*
If you are considering helping, or maybe just want to learn a bit more, then please reach out to us on our email list. I and a few others are personally committed to mentoring people through the process and connecting new contributors with the right people.
You can contact me personally at: c a m e r o n . s h o r t e r @ gmail.com
Good documentation benefits from access to cross-disciplinary skills. Expertise is typically spread across developers, users, domain experts, teachers, technical writers, graphic artists, and translators. Ramp-up time is high for any group attempting to learn another’s skill-set. This creates a significant barrier to entry.
Our OSGeoLive initiative has achieved sustained, cross-domain collaboration by capturing writer’s expertise within templates with clear and punchy writing instructions. These templates were then provided to developers and domain experts. By using an outline/write/review/translate/publish process we’ve achieved significant efficiencies by allowing experts to focus only on the areas they know best. However, OSGeoLive has only tackled the Project Overview and Quickstarts. Projects which have tacked harder documentation types haven’t addressed cross-project consistency.
How can we align our OSGeoLive writing initiatives with other projects and help build best practice templates for key documentation types? This will be valuable if addressed at an OSGeo level. It will be significantly more valuable if extended to an international, cross-domain level. (It will be challenging to attract momentum, but good groundwork is in place, and if implemented it would have a huge positive impact.)
Potential resources:*
- Document type definitions that I’ve written before.
- The Write-The-Docs community are a likely source of potential co-contributors and defacto owners of such templates.
- Bloom’s Taxonomy: Teacher Planning Kit is helpful for selecting language for training.
- Someone has suggested ISO standards, but you need to pay to use them, and they appear overly verbose: ISO/IEC/IEEE 26511, 25612, 25613, 25614, 25615.
To date, our OSGeoLive community have been sustainably maintaining two of the easier documentation types: Project Overviews and Quickstarts. Established OSGeo projects also have documentation, in various stages of currency, completion, relevance, verbosity, and quality.
I believe we are ready to extend our consistency and best practices to some of the harder documentation types - such as tutorials, workshops and howtos. We should start by focusing on one of OSGeo’s flagship projects, such as QGIS or PostGIS. Join the project’s existing documentation initiatives. Provide feedback and improvements as required. Build templates and writing instructions which can be adopted by other projects. Integrate these with the OSGeoLive publishing and translation pipeline.
Resources:*
QGIS, a desktop GIS application, is one of the OSGeo Foundation’s flagship projects with a broad developer and documentation community. In February 2019 QGIS put out their long-awaited 3.4 Long Term Release, which was a major update from the previous 2.18 version. As of March 2019, the project’s documentation hasn’t fully updated been to the new version. Some further ideas discussed during the recent A Coruña Hackfest are:
* Pyqgis cookbook code snipped are now automatic tested, meaning that every new contribution
will be rock solid and code snippets can be taken "as they are" and pasted in QGIS
* We have an idea to change the doc style to the more readable RTD vanilla theme
(fully supported by sphinx). A live example `here <https://qgis.org/test/en/>`_
* Besides from contents, writing documentation isn't easy because of the complex
framework (sphinx, git, github, etc). Improving the github editor (wysiwyg)
would be a great enhancement
* Cleaning the isse tracker in github (> 400 issue now) in many different ways:
verifying issues, closing duplicates, make order in the labels, etcThis is a great opportunity to:#
- Update older documentation.
- Tap into a very engaged community.
- Review against best writing practices and suggest improvements.
- Test best practice writing principles which can be exported and shared with other open source projects.
* Pyqgis cookbook code snipped are now automatically tested, meaning that every new contribution will be rock solid and code snippets can be taken "as they are" and pasted in QGIS
* Change the doc style to the more readable Read-The-Docs vanilla theme (fully supported by sphinx). A live example here https://qgis.org/test/en/.
* Besides from contents, writing documentation isn't easy because of the complex framework (sphinx, git, github, etc). Improving the WYSIWYG github editor would be a great enhancement
* Cleaning the issue tracker in github (> 400 issue now) in many different ways: verifying issues, closing duplicates, make order in the labels, etc
Resources:*
- University-level lectures and labs, created by GeoAcademy (based on the older QGIS 2.18)
- TBD: What else should we mention?
We’ve recently updated our OSGeoLive process for generating documentation, and have moved our documentation repository from MediaWiki to trac. We appear to have introduced a few gaps in the move. In particular, the new docs don’t reference our specific writing instructions which are embedding in Project Overview and Quickstart reference documents. A nice discrete task would be to review the old and new processes, and update the new docs to ensure they still contain relevant information, and are easy to follow.
Resources:*
For our 2019 OSGeoLive release we hope to attract a number of projects which have recently signed up as OSGeo Foundation Community projects. These projects will need help writing their Project Overviews and Quickstarts. Existing project documentation also needs to be updated to align with latest releases. (Reviewing 50 Quickstarts to ensure they still work is a time consuming exercise).
Resources:*
Like most open source projects, OSGeoLive templates and content have primarily been created by developers (and a few users), without access to the insights provided by trained technical writers and teachers.
Johanna Botman explains the challenges our approach has introduced. She started her working career as an English teacher, then moved into IT, website design, and is now uses geospatial software, as a geospatial officer at a local council. She observed:
There are many ways we can help solve this problem, from small to large:*
- Processes, tools and howto-write guides could both draw from international initiatives, and if we find ourselves to be world leading, then we should feed our insights back into international best practices.
It would be great if there was a compact, authoritative style guide (with a different configurations), which could be selected in a similar manner to the selection of a Creative Commons license. It should be freely available, and coordinated by a non-profit community. (One version might be too idealistic, maybe we need a few).
Benefits provided:*
- Improved documentation quality and consistency, resulting in improved reader comprehension.
- Easier for writing tools to support the guide(s).
- Make it easier for projects to set and apply writing standards.
Resources:*
- GeoServer style guide (also referenced by GeoNode)
- The Australian government has announced that we are updating our style guide. I’ve suggested collaboration.
- TBD: What other style guides should we mention?
To date, the OSGeoLive team haven’t selected a style guide. It would be good to get advice from technical writers on which we should choose. We potentially should retrospectively clean up our public facing documentation in line with the selected guide. I’m aware there are tools for auto-checking documentation quality. What options are available for open source projects?
It wouldn’t take much to create a practical 3-hour introductory workshop introducing ~ six to eight of the leading Open Source geospatial applications. It would be a valuable contribution to many spatial conferences. It could use the existing OSGeoLive distribution along with installed data, and can draw upon existing Quickstarts.
Resources:*
Most conferences and open source communities adopt a Code of Conduct and/or a Diversity Statement. It would be great of the multiple variants were consolidated, and selectable via a tick-box selection process, (like the selection of a Creative Commons license).
Resources:*
- Contributor Covenant Code of Conduct, which has attracted a lot of projects.
Jupyter Notebook is a web application that allows you to create and share documents that contain live code, equations, visualizations and explanatory text. It is a useful communication medium for explaining technical concepts. We included Jupyter Notebooks on prior OSGeoLive releases, but we didn’t have a maintainer to bring the documentation up to the standards we expect for OSGeoLive documents.
It would be good to:#
- Consider using Jupyter Notebooks as another documentation type supported by OSGeoLive - which would mean developing templates for its use by other OSGeo projects, and attracting maintainers from these projects to create material.
Resources:*
We maintain a lightning presentation of the ~ 50 projects on OSGeoLive. It is a challenge to keep this presentation concise enough to fit within a conference presentation time-slot and could do with tweaking.