Difference between revisions of "Season of Docs Ideas 2019"
(copied across from google docs (using OpenOffice->MediaWiki plugin), formatting needs work) |
(Revised text (formatting still with problems)) |
||
Line 1: | Line 1: | ||
− | ''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 | + | ''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, software users and those participating in Google’s [https://developers.google.com/season-of-docs/ Season-of-Docs].'' |
− | + | We, the communities behind the [https://www.osgeo.org/ OSGeo Foundation’s] open source geospatial projects, are 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 bursts of effort, toward small, discrete and achievable tasks, to collectively achieve an extraordinary impact. | |
+ | Leveraging Google’s Season-of-Docs | ||
− | + | <div style="margin-left:0in;margin-right:0in;">Google’s [https://developers.google.com/season-of-docs/ Season-of-Docs] is an initiative to bring open source and technical writer communities together to write documentation. We propose we use this initiative as a focal point to attract a collaborative community to pilot big ideas. In particular:</div>* <div style="margin-left:0.5in;margin-right:0in;">Open source projects face sustainability challenges. How will docs developed during Season-Of-Docs be maintained long term?</div> | |
+ | * <div style="margin-left:0.5in;margin-right:0in;">Can a writer’s expertise be amplified to help community users and developers write good docs more effectively and efficiently?</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">Could best practices developed in one project be applied to the greater open source eco-system? </div> | ||
− | |||
− | |||
+ | We propose to focus on one (or more) writing initiatives, for one of our leading OSGeo projects. Goals should focus on:* <div style="margin-left:0.5in;margin-right:0in;">Being directly applicable for the project.</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">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.</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">Engages a Season-of-Docs sponsored writer, along with volunteers from project and writing communities. </div> | ||
− | + | <div style="color:#434343;">Key roles sought</div>* <div style="margin-left:0.5in;margin-right:0in;">'''Mentor''': As an experienced project team member, provide technical mentorship toward a writing initiative.</div> | |
− | + | * <div style="margin-left:0.5in;margin-right:0in;">'''Writer''': As someone keen to give back to open source through docs, volunteer to be mentored and tackle our OSGeo writing initiatives.</div> | |
− | + | * <div style="margin-left:0.5in;margin-right:0in;">'''Senior writer''': Drive the writing aspects of an initiative, including empowering other participants. (Eligible for a stipend from Google).</div> | |
− | + | * <div style="margin-left:0.5in;margin-right:0in;">'''Learning expert''': Help shape documentation templates and guides by linking back to educational theory. (This role is highly prized).</div> | |
− | + | * <div style="margin-left:0.5in;margin-right:0in;">'''Administrator''': As an engaged OSGeo community member, act as a Season-of-Docs administrator.</div> | |
− | * <div style="margin-left:0.5in;margin-right:0in;"> | ||
− | * <div style="margin-left:0.5in;margin-right:0in;"> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | <div style="color:#434343;">Interested?</div> | ||
+ | If you are considering helping, or maybe just want to learn a bit more, then please reach out to us on our [https://lists.osgeo.org/mailman/listinfo/seasonofdocs email list]. If keen, then add yourself to the list below. ''(Be concise: Name, brief background, how you’d like to contribute.)'' | ||
− | <div style="color:# | + | <div style="color:#434343;">People keen to take part</div>* <div style="margin-left:0.5in;margin-right:0in;">'''Cameron Shorter''': Geospatial business analyst. Co-founder of OSGeoLive. Co-editor of OSGeoLive doc templates; reviewer of most of the 50 Project Overview and Quickstart documents. Ex-board member of OSGeo Foundation. Keen to provide connections to our community and to be practically involved in writing initiatives.</div> |
− | * <div style="margin-left:0.5in;margin-right:0in;">'''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, | + | * <div style="margin-left:0.5in;margin-right:0in;">'''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, code-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.</div> |
* <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | * <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | * <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | * <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | ||
− | * <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | + | * <div style="margin-left:0.5in;margin-right:0in;">'''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 the Transifex platform). Keen to support others in the use of these tools.</div> |
* <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | * <div style="margin-left:0.5in;margin-right:0in;">'''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.</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;"><span style="color:#000000;">Ok, I'll try to write to you ASAP</span><span style="color:#000000;">Hi 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.")</span>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.</div> | * <div style="margin-left:0.5in;margin-right:0in;"><span style="color:#000000;">Ok, I'll try to write to you ASAP</span><span style="color:#000000;">Hi 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.")</span>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.</div> | ||
Line 42: | Line 41: | ||
− | <div style="margin-left:0in;margin-right:0in;"></div>* <div style="margin-left:0.5in;margin-right:0in;"> | + | <div style="margin-left:0in;margin-right:0in;"></div>* <div style="margin-left:0.5in;margin-right:0in;"><add your name here></div> |
+ | |||
+ | <div style="margin-left:0in;margin-right:0in;"></div> | ||
− | + | The back story | |
− | + | 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 [http://cameronshorter.blogspot.com/2019/02/inspiring-techies-to-become-great.html this article on inspiring techies to become great writers]. | |
− | + | Ideas | |
<div style="color:#434343;">Best practice templates</div> | <div style="color:#434343;">Best practice templates</div> | ||
Line 63: | Line 64: | ||
Potential resources:* <div style="margin-left:0.5in;margin-right:0in;">Daniele Procida’s [https://www.divio.com/blog/documentation/ What nobody tells you about documentation].</div> | Potential resources:* <div style="margin-left:0.5in;margin-right:0in;">Daniele Procida’s [https://www.divio.com/blog/documentation/ What nobody tells you about documentation].</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">[https://github.com/mdyd-dev/nearme-documentation/tree/master/marketplace_builder/views/pages/doc-templates Nearme writing templates] with [https://www.platform-os.com/blog/post/blog/building-our-documentation-site-on-platformos-part-2-content-production-and-layouts accompanying blog post].</div> | * <div style="margin-left:0.5in;margin-right:0in;">[https://github.com/mdyd-dev/nearme-documentation/tree/master/marketplace_builder/views/pages/doc-templates Nearme writing templates] with [https://www.platform-os.com/blog/post/blog/building-our-documentation-site-on-platformos-part-2-content-production-and-layouts accompanying blog post].</div> | ||
− | * <div style="margin-left:0.5in;margin-right:0in;">[http://cameronshorter.blogspot.com/2018/06/technical-documentation-writing.html Document type definitions] | + | * <div style="margin-left:0.5in;margin-right:0in;">[http://cameronshorter.blogspot.com/2018/06/technical-documentation-writing.html Document type definitions].</div> |
* <div style="margin-left:0.5in;margin-right:0in;">[https://wiki.osgeo.org/wiki/OSGeoLive_AddProject#Documentation Writing instructions for OSGeoLive Project Overviews and Quickstarts].</div> | * <div style="margin-left:0.5in;margin-right:0in;">[https://wiki.osgeo.org/wiki/OSGeoLive_AddProject#Documentation Writing instructions for OSGeoLive Project Overviews and Quickstarts].</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">The [https://www.writethedocs.org/about/stay-connected/ Write-The-Docs community] are a likely source of potential co-contributors and defacto owners of such templates.</div> | * <div style="margin-left:0.5in;margin-right:0in;">The [https://www.writethedocs.org/about/stay-connected/ Write-The-Docs community] are a likely source of potential co-contributors and defacto owners of such templates.</div> | ||
Line 100: | Line 101: | ||
<span style="color:#000000;">would be a great enhancement</span> | <span style="color:#000000;">would be a great enhancement</span> | ||
− | <span style="color:#000000;"><nowiki>* Cleaning the | + | <span style="color:#000000;"><nowiki>* Cleaning the issue tracker in github (> 400 issue now) in many different ways:</nowiki></span> |
<span style="color:#000000;">verifying issues, closing duplicates, make order in the labels, etc</span>This is a great opportunity to:# <div style="margin-left:0.5in;margin-right:0in;">Help document a great project.</div> | <span style="color:#000000;">verifying issues, closing duplicates, make order in the labels, etc</span>This is a great opportunity to:# <div style="margin-left:0.5in;margin-right:0in;">Help document a great project.</div> | ||
Line 110: | Line 111: | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">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</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">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/ https://qgis.org/test/en/].</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">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</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">Cleaning the issue tracker in github (> 400 issue now) in many different ways: verifying issues, closing duplicates, make order in the labels, etc</div> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 124: | Line 123: | ||
* <div style="margin-left:0.5in;margin-right:0in;">[https://github.com/qgis/QGIS-Documentation/issues QGIS Documentation Issues]</div> | * <div style="margin-left:0.5in;margin-right:0in;">[https://github.com/qgis/QGIS-Documentation/issues QGIS Documentation Issues]</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">[http://spatialquerylab.com/foss4g-academy-curriculum/ University-level lectures and labs, created by GeoAcademy] (based on the older QGIS 2.18)</div> | * <div style="margin-left:0.5in;margin-right:0in;">[http://spatialquerylab.com/foss4g-academy-curriculum/ University-level lectures and labs, created by GeoAcademy] (based on the older QGIS 2.18)</div> | ||
− | |||
Line 130: | Line 128: | ||
<div style="color:#434343;">Other OSGeo Project Docs </div> | <div style="color:#434343;">Other OSGeo Project Docs </div> | ||
− | <div style="color:#ff0000;">TBD: Are there other projects that are at a tipping point - that could achieve the QGIS momentum if they get a push | + | <div style="color:#ff0000;">TBD: Are there other projects that are at a tipping point - that could achieve the QGIS momentum if they get a push?</div> |
<div style="color:#434343;">Improve OSGeoLive writing instructions</div> | <div style="color:#434343;">Improve OSGeoLive writing instructions</div> | ||
Line 143: | Line 141: | ||
<div style="color:#434343;">New OSGeoLive Quickstarts and Overviews:</div> | <div style="color:#434343;">New OSGeoLive Quickstarts and Overviews:</div> | ||
− | 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). | + | 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 the latest releases. (Reviewing 50 Quickstarts to ensure they still work is a time-consuming exercise). |
Resources:* <div style="margin-left:0.5in;margin-right:0in;">Ask OSGeoLive team about which new projects are joining OSGeoLive</div> | Resources:* <div style="margin-left:0.5in;margin-right:0in;">Ask OSGeoLive team about which new projects are joining OSGeoLive</div> | ||
Line 151: | Line 149: | ||
− | <div style="color:#434343;">Simplify OSGeoLive’s doc writing process | + | <div style="color:#434343;">Simplify OSGeoLive’s doc writing process</div> |
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. | 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. | ||
Line 158: | Line 156: | ||
− | <div style="margin-left:0.5in;margin-right:0in;">Some of the issues relating to getting started [with writing project documentation] are about bridging the gap between developers and writers. Developers write code in coding tools. They collaborate, they are used to versioning and are at home with unformatted raw text and automation tools. Writers? They work on Windows machines in Word | + | <div style="margin-left:0.5in;margin-right:0in;">Some of the issues relating to getting started [with writing project documentation] are about bridging the gap between developers and writers. Developers write code in coding tools. They collaborate, they are used to versioning and are at home with unformatted raw text and automation tools. Writers? They work on Windows machines in Word - maybe in Google Docs if they are lucky. They don’t know about running build scripts, running Linux variants, Github, chat programs, HTML, RST formats, wikis and the variants of markup languages. </div> |
− | <div style="margin-left:0.5in;margin-right:0in;">It’s one thing to work with the | + | <div style="margin-left:0.5in;margin-right:0in;">It’s one thing to work with the open source software, another to write about it, and a third thing to work out how to write it so that it fits in with the project. It seems as if the developers have created the writing system in a way that they are used to working, not necessarily in a way that works for writers.</div> |
− | There are many ways we can help solve this problem, from small to large:* <div style="margin-left:0.5in;margin-right:0in;">Technical | + | There are many ways we can help solve this problem, from small to large:* <div style="margin-left:0.5in;margin-right:0in;">Technical writers can try using our existing writing guides, and document anything that is difficult to understand, and help us fix it.</div> |
* <div style="margin-left:0.5in;margin-right:0in;">We can revisit and potentially improve the tools and processes we use. [https://www.gitbook.com/ Gitbook] looks promising. We have already adopted [https://www.transifex.com/ Transifex] for translations. Some research into options and what others are doing would help here.</div> | * <div style="margin-left:0.5in;margin-right:0in;">We can revisit and potentially improve the tools and processes we use. [https://www.gitbook.com/ Gitbook] looks promising. We have already adopted [https://www.transifex.com/ Transifex] for translations. Some research into options and what others are doing would help here.</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">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.</div> | * <div style="margin-left:0.5in;margin-right:0in;">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.</div> | ||
Line 171: | Line 169: | ||
<div style="color:#434343;">Define an authoritative style guide</div> | <div style="color:#434343;">Define an authoritative style guide</div> | ||
− | It would be great if there was a compact, authoritative style guide (with | + | It would be great if there was a compact, authoritative style guide (with different configurations), which could be selected in a similar manner to the [https://creativecommons.org/choose/ 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:* <div style="margin-left:0.5in;margin-right:0in;">Reduced time learning and maintaining multiple style guides.</div> | Benefits provided:* <div style="margin-left:0.5in;margin-right:0in;">Reduced time learning and maintaining multiple style guides.</div> | ||
Line 183: | Line 181: | ||
* <div style="margin-left:0.5in;margin-right:0in;">[https://docs.geoserver.org/latest/en/docguide/style.html GeoServer style guide] (also referenced by GeoNode)</div> | * <div style="margin-left:0.5in;margin-right:0in;">[https://docs.geoserver.org/latest/en/docguide/style.html GeoServer style guide] (also referenced by GeoNode)</div> | ||
* <div style="margin-left:0.5in;margin-right:0in;">The Australian government [https://www.themandarin.com.au/102797-the-first-new-edition-of-the-commonwealth-style-manual-since-2002-is-in-the-works/?utm_campaign=TheJuice&utm_medium=email&utm_source=newsletter has announced] that we are updating our style guide. [http://cameronshorter.blogspot.com/2019/01/toward-universal-style-manual.html I’ve suggested collaboration].</div> | * <div style="margin-left:0.5in;margin-right:0in;">The Australian government [https://www.themandarin.com.au/102797-the-first-new-edition-of-the-commonwealth-style-manual-since-2002-is-in-the-works/?utm_campaign=TheJuice&utm_medium=email&utm_source=newsletter has announced] that we are updating our style guide. [http://cameronshorter.blogspot.com/2019/01/toward-universal-style-manual.html I’ve suggested collaboration].</div> | ||
− | * <div style=" | + | * <div style="margin-left:0.5in;margin-right:0in;">TBD: What other style guides should we mention?</div> |
Line 195: | Line 193: | ||
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. | 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:* <div style="margin-left:0.5in;margin-right:0in;">[http://live.osgeo.org/en/overview/overview.html OSGeoLive Quickstarts] </div> | + | The workshop should make use of best practice template structure for presenting, and set up a template which can be expanded out to other OSGeo projects. |
+ | |||
+ | Resources:* <div style="margin-left:0.5in;margin-right:0in;">[http://live.osgeo.org/en/overview/overview.html OSGeoLive Quickstarts].</div> | ||
+ | * <div style="margin-left:0.5in;margin-right:0in;">Nicolas Roelandt, Astrid Emde are proposing such a workshop for the Free and Open Source for Geospatial conference (FOSS4G).</div> | ||
Line 212: | Line 213: | ||
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. | 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:# <div style="margin-left:0.5in;margin-right:0in;">Have Project Overviews and Quickstarts updated to <span style="color:#000000;">could be good to have this standards well explained somewhere</span>our standards, so we can re-introduce Jupyter Notebooks.</div> | + | It would be good to:# <div style="margin-left:0.5in;margin-right:0in;">Have Project Overviews and Quickstarts updated to <span style="color:#000000;">could be good to have this standards well explained somewhere</span>our quality standards, so we can re-introduce Jupyter Notebooks.</div> |
# <div style="margin-left:0.5in;margin-right:0in;">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.</div> | # <div style="margin-left:0.5in;margin-right:0in;">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.</div> | ||
Revision as of 05:10, 10 April 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, software users and those participating in Google’s Season-of-Docs.
We, the communities behind the OSGeo Foundation’s open source geospatial projects, are 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 bursts of effort, toward small, discrete and achievable tasks, to collectively achieve an extraordinary impact.
Leveraging Google’s Season-of-Docs
*
- Can a writer’s expertise be amplified to help community users and developers write good docs more effectively and efficiently?
- Could best practices developed in one project be applied to the greater open source eco-system?
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.
*
- Writer: As someone keen to give back to open source through docs, volunteer to be mentored and tackle our OSGeo writing initiatives.
- Senior writer: Drive the writing aspects of an initiative, including empowering other participants. (Eligible for a stipend from Google).
- Learning expert: Help shape documentation templates and guides by linking back to educational theory. (This role is highly prized).
- Administrator: As an engaged OSGeo community member, act as a Season-of-Docs administrator.
If you are considering helping, or maybe just want to learn a bit more, then please reach out to us on our email list. If keen, then add yourself to the list below. (Be concise: Name, brief background, how you’d like to contribute.)
*
- 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, code-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 the 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.
*
The back story
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.
Ideas
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:*
- 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 issue 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)
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 the 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 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.
The workshop should make use of best practice template structure for presenting, and set up a template which can be expanded out to other OSGeo projects.
Resources:*
- Nicolas Roelandt, Astrid Emde are proposing such a workshop for the Free and Open Source for Geospatial conference (FOSS4G).
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.