<div dir="auto">Hello Harrissou et al.,<div dir="auto"><br></div><div dir="auto">I like the idea. I don't know if we are able to attract many more writers, but the idea of having a fixed timeline and a plan sounds good anyway.</div><div dir="auto"><br></div><div dir="auto">We kinda did this release-before-ready with 3.4, and I think it went well. Although, I am not sure how much of a burden was to backport most of the work from master.</div><div dir="auto"><br></div><div dir="auto">So, I am very interested in setting that plan and define what are the priorities. We may need to have some help from the most active developers to point us to big changes that really need to be documented.</div><div dir="auto"><br></div><div dir="auto">Anyway, releasing before ready have mostly advantages, as it will still be more update than 3.4 docs are.</div><div dir="auto"><br></div><div dir="auto">The only disadvantage I see, is that translators may be working on a moving target for a while...</div><div dir="auto"><br></div><div dir="auto">So, how do we do this? Time to start our regular docs team meetings?</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Alex</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">A domingo, 22/09/2019, 09:28, Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com">cameron.shorter@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi Harrissou,</p>
<p>Great ideas here around setting a documentation generation
schedule. You might want to borrow from the countdown schedule we
use for OSGeoLive, which has key milestones for docs included. We
align our schedule with the international FOSS4G. <br>
</p>
<p><a href="https://docs.google.com/spreadsheets/d/1kO6zzmLFfprZGgp5x7Sjwi-EVN6NTGDR4KXvFVtNpR0/edit?hl=en_GB&hl=en_GB#gid=0" target="_blank" rel="noreferrer">https://docs.google.com/spreadsheets/d/1kO6zzmLFfprZGgp5x7Sjwi-EVN6NTGDR4KXvFVtNpR0/edit?hl=en_GB&hl=en_GB#gid=0</a></p>
<p>We go one step further in that we state that if a project's
documentation is not complete, then it is not included. (We
occasionally bend this rule, and let a project be included, but if
it's docs are not linked in, then people can't find the project.)</p>
<p>Cheers, Cameron<br>
</p>
<div>On 20/9/19 12:28 am, DelazJ wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi folks,</div>
<div><br>
</div>
<div>I'd like to hear your opinion about setting a due date for
the official documentation release. In recent years, we used
to release when "ready". And sometimes (<i>read always</i>),
be ready (aka, fix most of the relevant issues) takes months,
so many months that new releases are already out and people
either have learnt by themselves, blog, list... the new
features or grumbled all the time against us ;)</div>
<div><br>
</div>
<div>How about releasing the docs when the target QGIS release
becomes LTR, I mean release 3.10 docs in february when QGIS
3.4 EOL and 3.10 is promoted? With a clear deadline:</div>
<div>- The users know when a (translatable) documentation will
be available</div>
<div>- We could focus on priority issues (that we would need to
define)</div>
<div>- We can use the 3.10 LTRing to communicate about the
release of its associated documentation <br>
</div>
<div>- 4 months: it's not too late in the life of the release
(it could still be in use for a year)</div>
<div>
<div>- Because 3.10 would already be released, not only early
testers would know about the new features, so we can expect
(still need to figure out how) more potential writers</div>
</div>
<div>- Because we have a deadline, we can make calls during the
last month for more writers (maybe we can attract more people
if they think it's only for a month than "forever") and/or
organize doc sprints</div>
<div>- There might be other advantages...</div>
<div><br>
</div>
<div>For issues not documented at the release time, well, we can
take the next two/four(?) months to write and backport what we
can. Hence consider that in june, the 3.10 doc is "sealed".
And the single target for docs writers would then be 3.16 LTR.
And a new cycle...<br>
</div>
<div><br>
</div>
<div>I think that setting a planning for docs and let the
community know about it would not harm. neither does syncing
it with the software release cycle.</div>
<div><br>
</div>
<div>Looking forward to hearing from you,</div>
<div>Harrissou<br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..
<a href="mailto:Qgis-community-team@lists.osgeo.org" target="_blank" rel="noreferrer">Qgis-community-team@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" target="_blank" rel="noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></pre>
</blockquote>
<pre cols="72">--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254</pre>
</div>
_______________________________________________<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" rel="noreferrer">Qgis-community-team@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></blockquote></div>