<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body 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">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 class="moz-cite-prefix">On 20/9/19 12:28 am, DelazJ wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAECJsSq4C60JKnT+JdHhU6NHJ1_Ox5vcO6xzkBxmY+1U38kExA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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 class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-community-team@lists.osgeo.org">Qgis-community-team@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254</pre>
</body>
</html>