<div dir="ltr"><div><div>Hello Harrissou et al.,<br><br></div>Sorry if I sounded too harsh. That was not my intention, at all. Neither was my intention to point my finger to you. Intead I wanted to point to a situation that this commit exposed. Also, I don't think no one got offended by the comments to the commit or that it looked like people are not welcome.<br><br></div><div>I totally agree with the PR methodology. So I totally agree on your comments on that.<br><br>My concerns are about this part:<br><br><i>"Then, afaict, a part of this commit is more about QGIS 3 changes and I am not sure we are currently documenting QGIS3 stuffs (still waiting for comments and decision in this <a href="https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005060.html">thread</a>)."<br><br></i></div><div>So, with my email, I just wanted to go back to the discussion of what versions we are planning/want to release and have a decision. Also, make sure that whatever the decision on that, we have a solution that does not put a developer's (or anyone else) PR on hold (not merged) if they want to contribute documentation for the current is master version. Mainly because people's availability and motivation can be affected by that.<br><br></div><div>Kind Regard,<br><br></div><div>Alexandre Neto<br></div><div><div><div><div><br><div class="gmail_quote"><div dir="ltr">DelazJ <<a href="mailto:delazj@gmail.com">delazj@gmail.com</a>> escreveu no dia quarta, 8/02/2017 às 09:57:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Hi Alexandre,</div><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"></div></blockquote></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg">First
of all, sorry if ever i offended someone with my request in the linked commit although, after
proofreading the PR and its comments, I fail to get the link with your real concerns in this mail.<br class="gmail_msg"></div></div></blockquote><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"></div><div dir="ltr" class="gmail_msg">I
guess we all agree that the documentation needs help from
everyone. And none of us, I think, hesitate to remind this need and invite people
to contribute
whenever possible. I also agree that core developers are somehow the
best
interlocutors to help documenting features they develop so, when they
are available to help,
they are more than welcome.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">BUT I'm sorry, IMHO you took the wrong example (if ever there's one) to show that someone is not welcome.<br class="gmail_msg"></div></div></div></blockquote><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Nowhere
in the discussion you pointed I can see a barrier to any contribution
from core dev. What was asked is to do like most of us: make a pull
request that can be reviewed and discussed by interested people. This
way, we avoid breaking silently documentation build (not only the
application
repo is concerned, you know that - it has already occured) and ensure a
contribution free of typo or mistake. I'm sure there's no need to
replay a recent discussion on psc-list about contributing "large chunks"
of code without any review. I mistakenly(?) thought (and was proud) that the option taken to proceed through PRs
submission (for not obvious fixes) to QGIS repo was already in the DNA
of QGIS-DOC contributors.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This
was on the form, and on the substance I have some concerns about the
commit itself: eg, do we need to remove any mention of Taudem, including
instructions on configuring its provider when linked to QGIS? <br class="gmail_msg">Btw here's a perfect example of a core
dev contribution through pull request, few days before the aboce mentioned commit and, covering the <b class="gmail_msg">same issue</b>:
<a href="https://github.com/qgis/QGIS-Documentation/pull/1670" class="gmail_msg" target="_blank">https://github.com/qgis/QGIS-Documentation/pull/1670</a> This pull request was being
discussed. Honestly, we can't be discussing an issue, a way to fix things and have a related commit pushed in our back, ignoring that discussion.<br class="gmail_msg">In brief, there are enough things to discuss and it's worth a
pull request imo.<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">Any other kind of action you were thinking of to help <b class="gmail_msg">any contributor</b> follow doc guidelines and make a great contribution?<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"></div></blockquote></div><div dir="ltr" class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg">Some
time ago, we decided that we are going to release documentation for LTR
releases. That was for us to concentrate efforts for documenting those
special releases and, as soon it's finished, branch the repo. If we keep
trying to complete version 2.x documentation, before we even start
working on the 3.X version, we can end up wasting efforts in documenting
things that have already changed in master.<br class="gmail_msg"><br class="gmail_msg">So, IMHO, after the
release and branch a QGIS LTR version, we can delay the documentation
branching for a while to give time for a good documentation release, but
we can't do it for too long, to avoid the situation mentioned above.<br class="gmail_msg"><br class="gmail_msg"></div></blockquote></div><div dir="ltr" class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"></div></blockquote><div class="gmail_msg">About
branches and doc releases, I have already expressed my "slight
reluctance" on LTR-only releases (given that the next LTR is not 3.0 but
3.2 and is far away) so unless there's a real move from the team to push
a bunch of fixes to QGIS
3.0 issues, i opted to keep documenting 2.x features (and not only 2.16) I could work on.<br class="gmail_msg">A recent proposal to workaround this "issue" was exposed in (another long) message I sent few weeks ago (with few
feedbacks) in the psc-list:
<a href="https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005047.html" class="gmail_msg" target="_blank">https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005047.html</a><br class="gmail_msg"> <br class="gmail_msg"></div></div><div dir="ltr" class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg">Also,
IMHO, after documentation LTR branching (e.g. 2.14), documenting any
feature introduced in an intermediate version (e.g. 2.16, 2.18) should
be done, if possible, taking into account changes make to it in QGIS
master (e.g. 2.99).<br class="gmail_msg"><br class="gmail_msg"></div></blockquote></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg">I might miss it but I'm not aware of any feature recently documented that was removed in 3.0. And I agree that this is something to take into consideration.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Kind Regards,<br class="gmail_msg"></div>Harrissou</div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">2017-02-07 18:29 GMT+01:00 Paolo Cavallini <span dir="ltr" class="gmail_msg"><<a href="mailto:cavallini@faunalia.it" class="gmail_msg" target="_blank">cavallini@faunalia.it</a>></span>:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ola Alexandre,<br class="gmail_msg">
<span class="gmail_msg"><br class="gmail_msg">
Il 07/02/2017 18:18, Alexandre Neto ha scritto:<br class="gmail_msg">
<br class="gmail_msg">
> So, IMHO, after the release and branch a QGIS LTR version, we can delay<br class="gmail_msg">
> the documentation branching for a while to give time for a good<br class="gmail_msg">
> documentation release, but we can't do it for too long, to avoid the<br class="gmail_msg">
> situation mentioned above.<br class="gmail_msg">
><br class="gmail_msg">
> Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting<br class="gmail_msg">
> any feature introduced in an intermediate version (e.g. 2.16, 2.18)<br class="gmail_msg">
> should be done, if possible, taking into account changes make to it in<br class="gmail_msg">
> QGIS master (e.g. 2.99).<br class="gmail_msg">
<br class="gmail_msg">
</span>seems fine to me - any objection?<br class="gmail_msg">
All the best, and thank you for raising the issue.<br class="gmail_msg">
<span class="m_-7480356437625651322HOEnZb gmail_msg"><font class="gmail_msg" color="#888888"><br class="gmail_msg">
--<br class="gmail_msg">
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" class="gmail_msg" target="_blank">www.faunalia.eu</a><br class="gmail_msg">
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" class="gmail_msg" target="_blank">http://www.faunalia.eu/training.html</a><br class="gmail_msg">
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" class="gmail_msg" target="_blank">https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Qgis-developer mailing list<br class="gmail_msg">
<a href="mailto:Qgis-developer@lists.osgeo.org" class="gmail_msg" target="_blank">Qgis-developer@lists.osgeo.org</a><br class="gmail_msg">
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br class="gmail_msg">
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></font></span></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
Qgis-developer mailing list<br class="gmail_msg">
<a href="mailto:Qgis-developer@lists.osgeo.org" class="gmail_msg" target="_blank">Qgis-developer@lists.osgeo.org</a><br class="gmail_msg">
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br class="gmail_msg">
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div></div></div></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>Alexandre Neto</div><div>---------------------</div><div>@AlexNetoGeo</div><div><a href="http://sigsemgrilhetas.wordpress.com">http://sigsemgrilhetas.wordpress.com</a></div><a href="http://gisunchained.wordpress.com">http://gisunchained.wordpress.com</a><br></div></div>