<div dir="ltr"><div dir="ltr">Hi Paolo,<div><br></div><div>Maybe I misread the PSC ideas, appologies for that.</div><div><br>Some random ideas for something in between what we have, and google docs documentation:<br> - Start doing a call for documentation (maybe focused on the user manual) to help finish the work before the release of each LTR (February 2020 for 3.10). In it, we can:</div><div> 1. Point them to the list of active issues.</div><div> 2. Point them to the writing docs guidelines and videos about how to do it.</div><div> 3. Suggest them to contribute with content by writing it in the actual github issues, describing the proposed text and where it should go in the docs. In issues, they can use markdown and add images.</div><div>- Let the experienced sphinx gurus (those highlighted being) convert that into sphinx and integrate in the docs.</div><div>- If needed, use the available funds (if any) to hire someone (it can be a non-gis person) to "sphinxify" the contents.<br>- Ask/request/demand that Developers provide more information about the new features they produced. Maybe another check mark in the PR check list?<br>- Hire a professional Tech Writer to analyze and propose changes to the current organization of the Docs, focused on making it easier to maintain.</div><div><br></div><div>On the Docs team side (don't worry we are all on the same side here), we can:</div><div>- <b>Try</b> to make the guideline simpler with less mandatory components; (we no longer request that images are in a particular distribution)</div><div>- <b>Try</b> to narrow down the "fancy" sphinx directives that make understanding the content harder for a beginner (for example stop using the :guilabels and stick to bolds and italics?</div><div>- <b>Try</b> to do reviews ASAP and without requiring too much from the effort from the contributor (Harrissou and Havart are being quite fast theses days, thank you)</div><div>- Maybe in some cases, if the contributor does not mind (I don't), let a core contributor simply edit the PR and fix the errors or problems for the user. This may make his experience better than requesting too many changes.<br><br>There is also some work we have been talking about for a long time, that I think that can make things easier for new comers, move static content (stuff that don't change in each version) from the QGIS-Documentation repository into the QGIS Website. Example: Documentation guidelines, the developer guide, maybe even the Gentle Introduction to GIS.</div><div><br></div><div>Thanks,<br><br>Alexandre Neto</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 17, 2019 at 6:55 AM Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>> wrote:<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 Alexandre,<br>
<br>
On 17/10/19 01:46, Alexandre Neto wrote:<br>
<br>
> I must say I am quite disappointed. I would expect more support from the<br>
> PSC, not less...<br>
<br>
sorry if we gave this impression. we deeply appreciate all the wonderful<br>
work you and others have done on the documentation.<br>
our considerations stem simply for the hard fact that despite all the<br>
efforts, the budget set out for this, and the goodwill, we are not able<br>
to maintain a full up to date documentation.<br>
as I wrote earlier, the only way I see to change this would be to hire<br>
several full time professional writers, which is far beyond our budget.<br>
do you see a different way to solve this?<br>
<br>
> I am not sure the bottleneck is the documentation structure complexity.<br>
> It's just not a sexy work. Like testing... People don't even like to<br>
> discuss it.<br>
> <br>
> From previous talks with the "docs team" we all agreed that moving away<br>
> from sphinx would be a bad move.<br>
> <br>
> I don't think many people will join the documentation effort just<br>
> because we moved to markdown or google docs. If they do, they probably<br>
> won't stick around for long (my personal feeling), and who ever is left<br>
> will have an harder task to keep the docs updated.<br>
> <br>
> Unless we skip versioning all together, we still need pull requests,<br>
> commits, conflict resolution... which is, IMHO is the worst part for new<br>
> comers.<br>
> <br>
> BTW, sphinx can use markdown as an input format, it renders quite well<br>
> in github, but you lose most of the benefits of using RST.<br>
fully agreed on all the above.<br>
<br>
Cheers.<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-community-team mailing list for organizing community resources such as documentation, translation etc..<br>
<a href="mailto:Qgis-community-team@lists.osgeo.org" target="_blank">Qgis-community-team@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></blockquote></div></div>