[Qgis-community-team] Releasing QGIS 3.10 doc when 3.10 "becomes" LTR (fev 2020)

Fri Sep 27 02:09:38 PDT 2019

Hi Alex,

Le ven. 27 sept. 2019 à 10:34, Alexandre Neto <senhor.neto at gmail.com> a
écrit :

> Hi Harrissou,
>
> 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?
> Then, you would only have two mile stones.
>
> 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.
Also this avoids creating 2.x labels.

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.
>
> Yep, We're reaching Github limits; If only labels could be organised in
trees (I find GitHub poor in tagging issues).
Yep We'll need to do some clean up as issues are solved or find another way
to organize (but keeping milestones for LTR)

Thanks for your work,
>
you're welcome!

Harrissou

>
> Alex
>
> On Fri, Sep 27, 2019 at 7:59 AM DelazJ <delazj at gmail.com> wrote:
>
>> Hi,
>>
>> Le ven. 27 sept. 2019 à 00:17, DelazJ <delazj at gmail.com> a écrit :
>>
>>>
>>> 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 (https://github.com/qgis/QGIS-Documentation/issues/4249)
>>>
>>> Done. A better overview of the issues distribution at
>> https://github.com/qgis/QGIS-Documentation/milestones
>> 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.
>>
>> Regards,
>> Harrissou
>>
>>> 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.
>>> 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.
>>>
>>> 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.
>>>>
>>>> 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.
>>>
>>> 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.
>>>>
>>>>  hmmm... I see two things here:
>>> - some changes in an area are big because of small incremental changes
>>> over the releases. These are easily workable for writers, issue by issue.
>>> - 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 *per se *and not
>>> for this thread.
>>>
>>> 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.
>>>
>>> Anyway, releasing before ready have mostly advantages, as it will still
>>>> be more update than 3.4 docs are.
>>>>
>>>> The only disadvantage I see, is that translators may be working on a
>>>> moving target for a while...
>>>>
>>>> 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)"
>>>
>>> So, how do we do this? Time to start our regular docs team meetings?
>>>>
>>>> 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...
>>> Well! Yes, let's schedule a meeting in the next two weeks and put ideas
>>> in a wiki!
>>>
>>> Greetings,
>>> Harrissou
>>>
>>> Thanks,
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>> A domingo, 22/09/2019, 09:28, Cameron Shorter <
>>>> cameron.shorter at gmail.com> escreveu:
>>>>
>>>>> Hi Harrissou,
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> https://docs.google.com/spreadsheets/d/1kO6zzmLFfprZGgp5x7Sjwi-EVN6NTGDR4KXvFVtNpR0/edit?hl=en_GB&hl=en_GB#gid=0
>>>>>
>>>>> 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.)
>>>>>
>>>>> Cheers, Cameron
>>>>> On 20/9/19 12:28 am, DelazJ wrote:
>>>>>
>>>>> Hi folks,
>>>>>
>>>>> 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 (*read always*), 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 ;)
>>>>>
>>>>> 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:
>>>>> - The users know when a (translatable) documentation will be available
>>>>> - We could focus on priority issues (that we would need to define)
>>>>> - We can use the 3.10 LTRing to communicate about the release of its
>>>>> associated documentation
>>>>> - 4 months: it's not too late in the life of the release (it could
>>>>> still be in use for a year)
>>>>> - 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
>>>>> - 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
>>>>> - There might be other advantages...
>>>>>
>>>>> 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...
>>>>>
>>>>> 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.
>>>>>
>>>>> Looking forward to hearing from you,
>>>>> Harrissou
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..Qgis-community-team at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/qgis-community-team
>>>>>
>>>>> --
>>>>> Cameron Shorter
>>>>> Technology Demystifier
>>>>> Open Technologies and Geospatial Consultant
>>>>>
>>>>> M +61 (0) 419 142 254
>>>>>
>>>>> _______________________________________________
>>>>> Qgis-community-team mailing list for organizing community resources
>>>>> such as documentation, translation etc..
>>>>> Qgis-community-team at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/qgis-community-team
>>>>
>>>> _______________________________________________
>>>> Qgis-community-team mailing list for organizing community resources
>>>> such as documentation, translation etc..
>>>> Qgis-community-team at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/qgis-community-team
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-community-team/attachments/20190927/d91d533f/attachment-0001.html>