<div dir="ltr"><div style="font-family:"calibri","sans-serif""><div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi List,<br><br>In the QGIS Documentation repository we maintain and publish different documents:<br></div>A/<br>   - the User Manual<br></div>   - the Training Manual<br></div>   - the PyQGIS Cookbook<br></div>B/<br>   - the Documentation Guidelines (how to write the docs)<br>   - the gentle introduction in GIS (what's GIS)<br></div>   - and (coming soon) the Developer Guidelines (rules to contribute to QGIS Desktop and Server coding)<br><br></div>Each time we release a new doc, we actually publish a new version of all these documents (in html, and some of them also in pdf) and changes in each of these documents are pushed to translation (currently 18 languages published).<br><br></div>While the first three documents are really related to and dependent on QGIS versions, the latter are not. Hence I think we should stop releasing them altogether and have different cycles of releases:</div><div dir="ltr">- release the manuals when they are ready, as we use to do;</div><div dir="ltr">- and release the others when there are new texts, the way we do for QGIS website: this means that there will be a unique version available for these documents, hence a unique url and they will be live updated and translated.</div><div dir="ltr"><br></div><div dir="ltr"><b>Why?</b></div><div dir="ltr"><br></div><div dir="ltr">- The gentle introduction in GIS is almost the same between 2.0, 2.14 and testing (except typo and rendering fixes). Should we still publish all the versions?</div><div dir="ltr">- The documentation guidelines can change between versions but have interest only for the document(s) being written so i'm not sure it's worth publishing previous versions: <span style="font-family:sans-serif">there's actually no reason for anyone to check what were the rules in 2.2 e.g.</span></div><div dir="ltr">- The documentation and developers guidelines will gain to be published and translated when they are needed ie, during writing/coding cycle and not after the battle, once the targeted version is released.</div><div dir="ltr">- with QGIS 3 and its API break, there are some changes to dev guidelines. It makes no sense to put them in 2.18 doc branch so, according to the current process, they'd be merged in master branch, hence available in testing doc. But the testing documentation will not be released before summer 2018 (as of QGIS3.2 release) so no translated version until then. While a doc writer should be able to deal with English version of doc guidelines, speaking English shouldn't be a prerequisite for coders so, imho (from a non English native speaker) it's really a pity in this case.</div><div dir="ltr"> <br></div><div dir="ltr"><br></div><div dir="ltr"><b>What'd that mean?</b></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr" style="font-family:sans-serif">1- remove all links to previous versions of these three documents from <span style="font-family:sans-serif"><a href="http://qgis.org/en/docs/index.html" target="_blank">http://qgis.org/en/docs/index.<wbr>html</a><span></span></span><span style="font-family:sans-serif"> </span>. <span style="font-family:sans-serif">By removing these documents for each previous release, we will aerate a bit</span><span style="font-family:sans-serif"> that page and clean it fom unneeded and repetitive documents. It will also free space in our storage disks.</span></div><div dir="ltr" style="font-family:sans-serif">2- with some magic, point them to a url that won't change  E.g. if someone, for some reasons (bookmark, web search...) try to open <a href="http://docs.qgis.org/2.2/en/docs/documentation_guidelines/do_translations.html" target="_blank">http://docs.qgis.org/2.2/<wbr>nl/docs/documentation_guidelin<wbr>es/do_translations.html</a> we'll rather open something like</div><div dir="ltr" style="font-family:sans-serif"><a href="http://docs.qgis.org/2.2/en/docs/documentation_guidelines/do_translations.html" target="_blank">http://docs.qgis.org/nl/docs/d<wbr>ocumentation_guidelines/do_tra<wbr>nslations.html</a> </div><div style="font-family:sans-serif">3- reorganize the index page to list those unique docs in a more visible way.<br></div><div style="font-family:sans-serif"><br>The only issue I can see is how do we manage the only version related page in documentation guidelines <a href="http://docs.qgis.org/testing/en/docs/documentation_guidelines/substitutions.html" target="_blank">http://docs.qgis.org/testing/<wbr>en/docs/documentation_<wbr>guidelines/substitutions.html</a><br><br><b>What in the backend?</b><br><br></div><div style="font-family:sans-serif">I can see different options:<br><br></div><div style="font-family:sans-serif">1/ Move (back?) those documents to QGIS website repository; It'd be the easiest way but I'm not sure website repo is very appropriate and coherent to store doc source files<br></div>2/ Keeping them in the Documentation repository, use only the master branch (the basement and red wire branch of the repo) as source; it means that the master branch will generate:<br><div dir="ltr" style="font-family:sans-serif">  <font face="sans-serif">- docs in English only (user manual, cookbook and training manual) at <a href="http://docs.qgis.org/testing/en/docs" target="_blank">http://docs.qgis.org/testing/e<wbr>n/docs</a> <br></font><div style="font-family:sans-serif"><font face="sans-serif">  - and translated docs (gentle introduction, developers and documentation guidelines) using e.g. </font><a href="http://docs.qgis.org/nl/docs/" target="_blank">http://docs.qgis.org/nl/docs/</a> Changes to these documents will prioritarily go to master<br></div></div></div>That said, I have no idea of the amount of work it'd require, especially on Transifex infrastructure (and I do not have the skills to do it)- nor even if that's possible.<br><div style="font-family:sans-serif">3/ create a dedicated repo: i think we have enough repos to deal with and if we can avoid a new one, it'd be nice<br><br><br></div></div>I hope that my comments are clear enough.<br>Looking forward to read yours!<span class=""><br><br></span></div><div>Harrissou<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>