<div dir="ltr">That's what GitHub calls to the items you put on projects columns.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 10:43 AM DelazJ <<a href="mailto:delazj@gmail.com">delazj@gmail.com</a>> wrote:<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"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 27 sept. 2019 à 11:23, Alexandre Neto <<a href="mailto:senhor.neto@gmail.com" target="_blank">senhor.neto@gmail.com</a>> a écrit :<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"><div><br></div><div>You talked earlier about using github projects to organize the work, unfortunately, those notes are not very useful as we can't assign them to people. Would be better to be able to use real issues that we could move in a TODO > DOING --> REVIEW --> DONE workflow. Gitlab works like that.</div><div><br></div></div></blockquote><div>notes? Which ones?</div><div> <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"><div></div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 10:09 AM DelazJ <<a href="mailto:delazj@gmail.com" target="_blank">delazj@gmail.com</a>> wrote:<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"><div dir="ltr">Hi Alex,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 27 sept. 2019 à 10:34, Alexandre Neto <<a href="mailto:senhor.neto@gmail.com" target="_blank">senhor.neto@gmail.com</a>> a écrit :<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"><div>Hi Harrissou,</div><div><br></div><div>Shouldn't we move the 2.x issues into 3.4 milestone (the oldest one that we will backport) and add the 2.x label to inform of when they were introduced?</div><div>Then, you would only have two mile stones.</div><div><br></div></div></blockquote><div>Yep, it'd be the option. My point was if these 6-7 issues are not of high importance, are obsolete, or not for user manual we'd better close them now than bring them to 3.4.</div><div>Also this avoids creating 2.x labels.<br></div><div><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"><div></div><div>One thing, having labels for each release, won't that fill the labels list too much? We will need to do some clean up once we see that a certain label is no longer needed.</div><div><br></div></div></blockquote><div>Yep, We're reaching Github limits; If only labels could be organised in trees (I find GitHub poor in tagging issues).</div><div>Yep We'll need to do some clean up as issues are solved or find another way to organize (but keeping milestones for LTR)</div><div><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"><div></div><div>Thanks for your work,</div></div></blockquote><div>you're welcome! <br></div><div><br></div><div>Harrissou<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"><div><br></div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 7:59 AM DelazJ <<a href="mailto:delazj@gmail.com" target="_blank">delazj@gmail.com</a>> wrote:<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"><div dir="ltr">Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 27 sept. 2019 à 00:17, DelazJ <<a href="mailto:delazj@gmail.com" target="_blank">delazj@gmail.com</a>> a écrit :<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"><br><div class="gmail_quote"><div>OK, Alex. With three upvotes (Rosa wrote to me directly) and no objections so far, let's say it's SOLD! I'm going to update the repo accordingly (<a href="https://github.com/qgis/QGIS-Documentation/issues/4249" target="_blank">https://github.com/qgis/QGIS-Documentation/issues/4249</a>)</div><div><br></div></div></div></blockquote><div>Done. A better overview of the issues distribution at <a href="https://github.com/qgis/QGIS-Documentation/milestones" target="_blank">https://github.com/qgis/QGIS-Documentation/milestones</a></div><div>Four milestones instead of eight and I'm pretty sure we can close more if some python-skilled people can look at whether the 2.x reports are still applicable.</div><div><br></div><div>Regards,</div><div>Harrissou<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"><div class="gmail_quote"><div></div><div> The idea is not to set the date and wait; if we have deadlines and nobody is aware of that, let's not expect any help. We'd need to have some key events that would make enough noise around the documentation, eg "code sprint" (or whatever it's called) for documentation, 2-3 days of full documentation. How about devs "stop" to code a day and come to doc features (either with writing PR, add details on "their" features, triage issues, provide screenshots...). With all the noise we can do on social media, i think it can have a big impact in the community.</div><div>This also means that documentation should not stay on the shoulders of the "documentation team" but its responsibility shared between the QGIS team, including PSC, devs, users(?). We should all be concerned.<br></div><div><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="auto"><div dir="auto"></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></blockquote><div>Backport is simpler now with the bot; it conflicts sometimes but there's less to do. And if most of the work is done before the release (!!!), there would not be much to backport.</div><div><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="auto"><div dir="auto"></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></blockquote><div> hmmm... I see two things here:</div><div>- some changes in an area are big because of small incremental changes over the releases. These are easily workable for writers, issue by issue.</div><div>- some are big new features and I think we (the PSC) should find a system that involves the devs more in documenting *their* big features. Some do, some just don't. But this was and is a topic <i>per se </i>and not for this thread.</div><div><br></div><div>I was wondering whether the Projects tab in the header of GitHub repository pages could be of any help in structuring/prioritizing/visualizing the docs issues and if someone has already worked with that.<br></div><div><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="auto"><div dir="auto"></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></blockquote><div>Fair, but still if most of the work (let me dream!) is done before the release, given that translations begin only after release, there should not be much to break. Moreover, I think we should not continuously backport the changes, reason why I'm suggesting the backport extent to 2 or 4 months max. Maybe with regular monthly point releases (like we do for the code - /me now looking at Richard). "If someone wants a fully up to date localized documentation, please, join the team (there is enough to do, even for non English speakers)"</div><div><br></div><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="auto"><div dir="auto"></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></blockquote><div><div>I personally feel that we (?) can't continue the way things are
going currently so _either_ we find a more inclusive, structured and
active/productive system to collectively build the best documentation
for our users...</div><div>Well! Yes, let's schedule a meeting in the next two weeks and put ideas in a wiki!<br></div></div><div><br></div><div></div><div>Greetings,</div><div>Harrissou<br></div><div><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="auto"><div dir="auto"></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" target="_blank">cameron.shorter@gmail.com</a>> escreveu:<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 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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">Qgis-community-team@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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>
_______________________________________________<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">Qgis-community-team@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></blockquote></div>
</div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>