<div dir="ltr"><div dir="ltr">Hi Paolo, all<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 13 nov. 2019 à 19:26, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
we had a lengthy and I think fruitful discussion about the future of<br>
documentation. I think time is ripe to take steps towards a concrete<br>
solution.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">AFAICT, a reasonable proposal stemming out of the discussion was:<br></blockquote><div><div><br></div><div>Do you refer to a recent PSC meeting (I can't find last meetings notes in the wiki btw) or to these last months discussions in the different mailing-lists ?</div><div>Anyways, I agree. Time to act.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* having a core documentation, listing all functions available with at<br>
least a minimal description</blockquote><div> </div><div> Is that something different from our current manuals? I mean, are there things in the current docs that would not have their place in the future docs, following this scenario? And what kind of contents would/could be added (other than the media you mention later)?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> (this could be taken from the commit<br>
description for the upcoming features, and the version number where it<br>
first appeared can be added)<br></blockquote><div> </div><div><a href="https://github.com/qgis/QGIS-Documentation/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+naughty">https://github.com/qgis/QGIS-Documentation/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+naughty</a> represents the issue reports with NO description (because there was none in the commit). Add to that the issue reports whose description is only the commit title. Morality: writers still have to browse qgis/QGIS repository (or wait for the changelog to have more resources to pick from). So imho there's a work to do on the devs side to get them used to descriptive and easily understandable commits or PR.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* allow comments by all interested parties on each function, to<br>
encourage the addition of heterogeneous material, e.g. links to videos,<br>
presentations, and more<br></blockquote><div> </div><div>Do we have an example of what that could look like and how this is managed? Or is this something we'd "invent"? I must confess that I fail to see the "end product".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
UNclear how to handle translations:<br>
* stick to English, and let people adding translations as comments as above<br>
* starting with a multilingual structure from the beginning.<br>
I think we agree that we want to keep a revision-controlled system, so<br>
the main issue would be to have a web interface displaying each function<br>
as a page, and allowing comments.<br></blockquote><div><div><br></div><div>Being a non-native English speaker and surrounded by people who do not speak English and love QGIS, I'd definitely prefer QGIS provides a way to get translation. Having materials in your language also contributes to QGIS adoption.</div><div>There is(was?) a Transifex web feature that allows, from what I understood at that time, to translate directly in the published docs. Never looked at it but maybe someone...<br></div><div> </div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course there are other views, and nothing has been decided yet, so<br>
alternative proposals are most welcome.<br></blockquote><div> </div><div>Maybe it's because I do not yet see what the proposals above would output, but I miss an information: what issue(s) are these changes trying to fix: the lack of contributors to docs, too many resources on personal blogs, docs not targetting the users need (ex of how-to suggestion), outdated information in docs, docs not being enough descriptive/detailed, docs being hard to contribute to, docs being hard to maintain/build, docs not being sexy, attracting more educational world contributors, prioritizing docs, no advertising on official docs... ? Cameron's thread as well as the user survey pointed many (different) levels of issues and since in my case I don't know which ones the PSC wants to prioritize, I'm pretty lost.<br></div><div>I think that without knowing what we want to fix/improve here, it's hard to come with comparable alternatives, if any. My 2cts.</div><div><br></div><div>Best wishes,</div><div>Harrissou<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
All best wishes.<br>
-- <br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
<a href="http://QGIS.ORG" rel="noreferrer" target="_blank">QGIS.ORG</a> Chair:<br>
<a href="http://planet.qgis.org/planet/user/28/tag/qgis%20board/" rel="noreferrer" target="_blank">http://planet.qgis.org/planet/user/28/tag/qgis%20board/</a><br>
_______________________________________________<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="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div></div>