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

Fri Sep 27 02:43:02 PDT 2019

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

>
> 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.
>
> notes? Which ones?

Alex
>
> On Fri, Sep 27, 2019 at 10:09 AM DelazJ <delazj at gmail.com> wrote:
>
>> 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/c9da9cf4/attachment-0001.html>