<div dir="ltr">Hi Alexandre,<br><br>2017-02-07 18:18 GMT+01:00 Alexandre Neto <span dir="ltr"><<a href="mailto:senhor.neto@gmail.com" target="_blank">senhor.neto@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"><div dir="ltr">In
my opinion, we need to take action to make sure that a developer that
is working on a master version feature is not prevented from documenting
it because the documentation team is still working on the 2.16 version
issues. Example:<br><br><a href="https://github.com/qgis/QGIS-Documentation/commit/4e155346641d17a532755f535ff363b355327c91" target="_blank">https://github.com/qgis/QGIS-D<wbr>ocumentation/commit/4e15534664<wbr>1d17a532755f535ff363b355327c91</a><br><br>Documentation
needs all the help it can get. If we expect core developer to help with
documentation, the only time this is remotely possible is when they are
making changes to QGIS master. For that reason, QGIS Documentation and
QGIS master branches must be in sync regarding the version.<br><br></div></blockquote><div>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><div dir="ltr"><br></div><div dir="ltr">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><br></div><div>BUT I'm sorry, IMHO you took the wrong example (if ever there's one) to show that someone is not welcome.<br><br></div><div>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><br></div><div>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>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>same issue</b>:
<a href="https://github.com/qgis/QGIS-Documentation/pull/1670" target="_blank">https://github.com/qgis/QGIS-<wbr>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>In brief, there are enough things to discuss and it's worth a
pull request imo.<br></div><div><br>Any other kind of action you were thinking of to help <b>any contributor</b> follow doc guidelines and make a great contribution?<br></div><div><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"><div dir="ltr">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><br>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><br></div></blockquote><div>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>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" target="_blank">https://lists.osgeo.org/<wbr>pipermail/qgis-psc/2017-<wbr>January/005047.html</a><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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><br></div></blockquote><div>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><br></div><div>Kind Regards,<br></div>Harrissou</div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-07 18:29 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">Ola Alexandre,<br>
<span class=""><br>
Il 07/02/2017 18:18, Alexandre Neto ha scritto:<br>
<br>
> So, IMHO, after the release and branch a QGIS LTR version, we can delay<br>
> the documentation branching for a while to give time for a good<br>
> documentation release, but we can't do it for too long, to avoid the<br>
> situation mentioned above.<br>
><br>
> Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting<br>
> any feature introduced in an intermediate version (e.g. 2.16, 2.18)<br>
> should be done, if possible, taking into account changes make to it in<br>
> QGIS master (e.g. 2.99).<br>
<br>
</span>seems fine to me - any objection?<br>
All the best, and thank you for raising the issue.<br>
<span class="HOEnZb"><font color="#888888"><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/<wbr>training.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=<wbr>qgis,arcgis</a><br>
______________________________<wbr>_________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></font></span></blockquote></div><br></div>