<div dir="ltr"><div><div><div><div>Hi,<br>To react on the initial subject, let me thank you, Andreas, for 
having raised it. And as suggested by Tim, here are some inputs from me (<i>Bear with me, I'd written a long and argumented message but I almost lost it while switching devices before I sent it so this one is quickly rewritten and less constructed and, maybe still long. Sorry</i>)...<br><br>This
 issue actually has been floating around in my head for a moment, 
looking at all the great energy and enthusiasm put in the move to QGIS3 
and all the new issues those commits create in the Doc repo. QGIS 3 is 
going to be a nicer application. <br>But I was a little bit disappointed
 to not see any discussion around documentation. In the 
meantime, the Doc repo becomes a low-traffic one: e.g., during the last month,
 16 issues have been fixed while 27 new ones were created [0]. In the 
last months, the mean of active contributors would count on fingers of 
one hand, I think.<br>Browsing stats of the doc repo [1], we currently have:<br>* >120 issues for 3.0<br>* 72 for 2.16 and 2.18<br>* 40 without milestones, sometimes very old issues or global issues related to the doc infrastructure/organisation itself.<br>A heavy task !<br><br>Yes,
 LTR releases should be the target of documentation. But we currently do
 not know when the next LTR (3.2) will be available and until that moment, I think that the majority of users will 
likely stick to a 2.x version. Reason why I think a 2.18 doc should be 
released. I personally do not consider 3.x issues yet when contributing 
to doc. It can be seen like overloading the work given that some features in 2.x are
 broken/removed in 3.0 but other features are improvements of existing features 
and require them to be prealably filled. So given that I don't have any 
idea of the balance, I'm still focusing on 2.18. Maybe it's now time to have, like it was done for QGIS, two branches in Doc repo (master_2/2.18 and master/testing), so that available people can begin tackling some features of QGIS3.<br><br>So, in any case, If 
we want a 3.2 doc to be released nearby QGIS3.2 release, we obviously 
need more people involved in QGIS Documentation and also an idea of what we would like a QGIS3 documentation to look like.<br><br>**People involvment**<br><br>Involving people begins with a descriptive commit of the feature by QGIS developers and by their availability when they are pinged by doc team for more information. The first part seems to work well for most of the developers and would surely be improved by the PR template [2]. <br></div>Then any PR in QGIS-Doc repo should not be left without feedback for weeks (though I know we are all contributing on a volunteer basis). We (englobing all of us, given that you don't need to be a doc repo maintainer before commenting) should ensure this reactivity. Lack of feedback slow down people and can discourage them from contributing. I personally have more fun contributing to QGIS than QGIS-Doc these last weeks(/months?).<br><br></div>For the writing side, I naively thought in the past that the main barrier for contributors was the lack of precise instructions/how-tos (it could have been for me) but despite our efforts to build guidelines more descriptive and complete (with step-by-steps), few new contributors joined us and they were very brief.<br></div>So If we have funds to finance people writing docs, let's do it. But besides any contract with Yves, I think it could be nice to use it also as an opportunity to attract new people to the doc writing. A long-term writer is highly needed. And despite what I earlier mentioned about me working on 2.18, I think that any financed work should target QGIS3 (a backport can be made if the fix applies to 2.18).<br><br></div>Btw, how do other FOSS write their documentation?<br><div><div><div><div><br></div><div>**Which documentation for QGIS 3?**<br><br></div><div>I am very delighted to see that Richard's QEP on linking application and documentation is being implemented. Nice. However, this is at the infrastructure level if I'm not wrong. What do we want to put as contents?<br></div><div>QGIS-Documentation currently provides 5 separate documents, maybe 6 (pending PRs :-) ) [3]. Status of some of these documents question me:<br><br></div><div>The Training Manual: this one is an useful document for beginners but was written for QGIS 2.0 (?). It has got some fixes since, but also has a bunch of issue reports that are not easy to tackle imho if you are not the author nor had followed the exercices (which is my case but i might not be alone among writers). I can't tell how closer it's currently with recent releases but I wonder what it'll be with QGIS 3 (e.g., some plugins/tools described in the manual like SPIT or Raster Terrain Analysis have been removed in recent months... and could require some exercices to be reorganized)<br><br></div><div>The PYQGIS Cookbook: During the grant program, there were two proposals about updating the Cookbook. Anita tried unsuccessfully to revive the discussion about it later  [4]. I think that this is a major document to update (and budgetize) because the API doc (which is worth updating, of course) is not enough for the average developers (<i>a priori</i>, the majority of plugin creators as I read) to build their tools. Having samples of code is more than useful.<br></div><div><br>The PDF docs: We provide PDF docs to help people less connected to still have a doc but these docs (at least the User manual) have some issues  [5] that don't make them always usable/readable.<br><br>Search: Have you ever made a research in the search bar of the doc? Then did you find the results comprehensive/pertinent/right?<br></div><div>I also often see, in french forums, people adding to their comments links to old QGIS docs (2.0, 2.2, 2.6) while there are more recent ones (QGIS 2.14 is the last released doc). I assumed that it's the "millesime" that is returned by their web browser so I wonder why not recent docs are returned in the searches and could that be improved?<br></div><div><br></div><div>I recently realized that QGIS has tools for spelling checks. Any chance to have such tools in Docs repo where there's most likely more chance to have spelling typos? Is that possible?<br></div><div><br></div><div>These last points are to say that, beyond writers, we also need developers to help us maintain/improve the architecture/infrastucture of the doc repo and make it more friendly for users and writers. Thanks, Richard.<br></div><div><br>As I mentioned at the beginning, I quickly write this message and may have forgotten some points. And sorry for my french-to-english style writing.<br></div><div>I don't know on which points PSC could be of help but I had to express them. <br></div><div><br>Hoping that it will be useful for the discussions and actions,<br></div><div>Harrissou<br></div><div><br>[0] <a href="https://github.com/qgis/QGIS-Documentation/pulse/monthly" target="_blank">https://github.com/qgis/QGIS-D<wbr>ocumentation/pulse/monthly</a><br>[1] <a href="https://github.com/qgis/QGIS-Documentation/milestones" target="_blank">https://github.com/qgis/QGIS-D<wbr>ocumentation/milestones</a><br>[2] <a href="https://github.com/qgis/QGIS/pull/3919" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/3919</a><br> [3] <a href="https://github.com/qgis/QGIS-Documentation/issues/1566" target="_blank">https://github.com/qgis/QGIS-<wbr>Documentation/issues/1566</a><br>[4] <a href="http://osgeo-org.1560.x6.nabble.com/Documentation-proposals-Was-Discussion-on-the-QGIS-grant-proposals-td5289918.html" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/Documentation-<wbr>proposals-Was-Discussion-on-<wbr>the-QGIS-grant-proposals-<wbr>td5289918.html</a><br>  [5] <a href="https://github.com/qgis/QGIS-Documentation/issues?q=is%3Aopen+is%3Aissue+label%3A%22PDF+Docs%22" target="_blank">https://github.com/qgis/QGIS-<wbr>Documentation/issues?q=is%<wbr>3Aopen+is%3Aissue+label%3A%<wbr>22PDF+Docs%22</a><br><br><br><br><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-05 9:21 GMT+01:00 Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Il 05/01/2017 09:18, Alexander Bruy ha scritto:<br>
> Hi,<br>
><br>
> there is an ongoing work [0] on implementing generic help system for QGIS<br>
> based on Richard's QEP [1]. Maybe we should also adopt documentation<br>
> to this?<br>
<br>
</span>+1<br>
reducing duplication and having the documentation more ready at hand are<br>
important targets.<br>
Thanks Alex.<br>
<span class="m_-837046754624001620im m_-837046754624001620HOEnZb"><br>
--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/trainin<wbr>g.html</a><br>
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" target="_blank">https://www.google.com/trends/<wbr>explore?date=all&geo=IT&q=qgis<wbr>,arcgis</a><br>
</span><div class="m_-837046754624001620HOEnZb"><div class="m_-837046754624001620h5">______________________________<wbr>_________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/qgis-psc</a></div></div></blockquote></div><br></div></div>