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

Fri Sep 27 03:25:00 PDT 2019

That's what GitHub calls to the items you put on projects columns.

On Fri, Sep 27, 2019 at 10:43 AM DelazJ <delazj at gmail.com> wrote:

>
> 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/d666329c/attachment-0001.html>