<div dir="ltr"><div>Hi,</div><div><br></div><div>Thanks for your replies. Just some precision I'd like to add:</div><div class="gmail_extra"><br><div class="gmail_quote">2018-07-03 9:15 GMT+02:00 matteo <span dir="ltr"><<a href="mailto:matteo.ghetta@gmail.com" target="_blank">matteo.ghetta@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi guys,<br>
<span class="gmail-"><br>
> I know that those processing alg help pages are programmatically(?)<br>
> generated by Alexander B (in bcc), because we did not have anything<br>
> there, and it that way we at least had the list of parameters. The idea<br>
> was that humans then could add more information. We had some discussion<br>
> at that time to either put it all in separate files, or group them or<br>
> one file (we started with separate files, exploding the number of<br>
> resources for transifex).<br>
> <br></span></blockquote><div> </div><div>I did not check the history of those files but i'm pretty sure they 
didn't get updates for years (other than visual cleanup or file restructuring). And i'm 
sceptic that they get any in upcoming years (afaics there's no sign out there that would contradict me).<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"><span class="gmail-">
> In general: having our own docs gives us a chance to have some<br>
> consistency, add our own text and images, they are translatable and<br>
> potentially to be packaged in an offline help package (still on the todo<br>
> list :-) ).<br>
> <br></span></blockquote><div>Yes. If only we really have valuable text to show to users and our hundreds of <put parameter description here> does not sound a plus-value imho.</div><div>Also, shouldn't we keep work on a project documentation close to the project itself? I understood that we were getting rid of those providers from Core and we would link to the upstream release. In that case, I suppose that we'll be using the upstream release hence no more custom parameters. so we can safely rely on upstream doc if it exists.</div><div>Shouldn't we follow the same logic as devs?</div><div><br></div><div>Maintaining a documentation of eg SAGA algs in QGIS docs while SAGA has a documentation site sounds to me like spreading energy. Better maintain and translate (if available or maybe help them to build that translation platform) on their side. I don't know how things were at the time the community made the choice to pull our own docs. Given the lack of love those docs get, how hard it'll be to keep them up to date, the poor look of those pages, and that there's a doc in SAGA side, should we continue to keep them?<br></div><div></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"><span class="gmail-">
> But we should(!) link to them from within QGIS, else I agree we should<br>
> get rid of the burden to maintain them.<br>
<br>
</span>I agree with Harrissou: there is already a huge effort to maintain just<br>
our algorithm docs (only speaking for Processing docs and not all the<br>
manual). Maintaining also gdal/saga/ecc.. is too much for different reasons:<br>
<br>
* some parameter changes and we have to update the docs by testing<br>
what's new<br>
* lack of docs from source (e.g. SAGA). If the source docs are poor<br>
there is no way (and also reasons I'll say) for us to document them<br>
<span class="gmail-"><br></span></blockquote><div>Actually, I do not find that there is a lack or poor doc outside (compared to what we propose). Some random choices:</div><div>Saga: see <a href="https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/saga/terrain_analysis_hydrology.html#flow-width-and-specific-catchment-area">https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/saga/terrain_analysis_hydrology.html#flow-width-and-specific-catchment-area</a> vs <a href="http://www.saga-gis.org/saga_tool_doc/2.2.0/ta_hydrology_19.html">http://www.saga-gis.org/saga_tool_doc/2.2.0/ta_hydrology_19.html</a> (see whole index at <a href="http://www.saga-gis.org/saga_tool_doc/2.2.0/a2z.html">http://www.saga-gis.org/saga_tool_doc/2.2.0/a2z.html</a>)<br>
R: i don't know how to find correspondences nor if that's the official site but give a look to <a href="https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/r/home_range_analysis.html#single-linkage-cluster-analysis">https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/r/home_range_analysis.html#single-linkage-cluster-analysis</a> vs algs description at <a href="https://stat.ethz.ch/R-manual/R-devel/library/stats/html/">https://stat.ethz.ch/R-manual/R-devel/library/stats/html/</a><br>
Otb: See <a href="https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/otb/feature_extraction.html#grayscalemorphologicaloperation-closing">https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/otb/feature_extraction.html#grayscalemorphologicaloperation-closing</a> vs <a href="https://www.orfeo-toolbox.org/CookBook/Applications/app_GrayScaleMorphologicalOperation.html">https://www.orfeo-toolbox.org/CookBook/Applications/app_GrayScaleMorphologicalOperation.html</a></div><div><br></div><div>Most of the times, our doc lists only the possible values and the default one.</div><div><br></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"><span class="gmail-">
> It is a community choice, I think, if in QGIS we should be linking to<br>
> third-party docs or linking to QGIS docs (which then can link to the<br>
> third-party docs).<br>
> <br>
> We (as QGIS) really have a problem maintaining the docs.<br>
> People outside the community often complain about sparce documentation,<br>
> but (even with funding) we have problems keeping them up to date with<br>
> the developers. We really need more help, both from developers (which<br>
> more often should write some lines in the commit messages) and from<br>
> users (which could try to write some text).<br>
> Not sure if extra funding would help...<br>
<br>
</span>Besides a lack of funding I see a lack of people.. I don't know how else<br>
we can attract more people to help documenting QGIS..<br>
<br></blockquote><div>Imho, it's really a lack of people. Not a money problem afaik. If I'm not wrong (and Andreas could correct me), the budget assigned to documentation in these last years was never covered.</div><div>And people that complain about sparce documentation should stop doing it and try to give a hand (an hour per week or per month on an area they know about is enough and would help others to fill the gaps in the parts they do not know about). And removing those processing algs from our docs may give a less sparce look to our docs.<br></div><div><br></div><div><div>Regards,</div><div>Harrissou</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">
Cheers<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Matteo<br>
______________________________<wbr>_________________<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">Qgis-community-team@lists.<wbr>osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>community-team</a></font></span></blockquote></div><br></div></div>