<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">https://github.com/qgis/QGIS-Documentation/commit/4e155346641d17a532755f535ff363b355327c91</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>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>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>Cheers,<br><br>Alexandre Neto<br></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>