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

[Alexandre Neto]

Would be nice if we could create a project for the next release and put the
prioritary issues there. That could be our way of planning, but I wasn't
able to find a way to do it.

I will try on my own repo or something.

A sexta, 27/09/2019, 15:46, DelazJ <delazj at gmail.com> escreveu:

> Alex, OK you are referring to
> https://github.com/qgis/QGIS-Documentation/projects/1. This is some
> completely different project. You'll find the rationale at
> https://github.com/qgis/QGIS-Documentation/pull/4237#issuecomment-530794557
> (in short, these are notes to remember what needs to be done when creating
> a new branch in docs. According to the notes context menu, they can be
> turned into issue reports; to do only at release time to avoid people
> trying to tackle them when unnecessary)
>
> From what I saw in GH we can create as many projects as we want and GH
> also provides the Todo/In Progress/Done structure. The question is what to
> put in and how do we organise the items (by manuals, by chapters, by main
> components of the application?) I don't quite see the right way to do, yet!
> and i'm less confident with blindly play with the shared repo. ;) And is it
> worth it?
>
> Harrissou
>
> Le ven. 27 sept. 2019 à 12:41, Cameron Shorter <cameron.shorter at gmail.com>
> a écrit :
>
>> Hi Harrissou,
>>
>> For OSGeoLive, we apply "docs not complete - package not included". For
>> QGIS, your unit might be a module or feature.
>>
>> We started small and expanded. First, we just asked for a package
>> installer, then a Project Overview, then a Quickstart.
>>
>> We make it clear that a we expect quality and we expect the projects to
>> provide their own volunteers to reach our quality criteria. Projects
>> without a maintainer are removed. This is a principle which you might want
>> to customise for QGIS modules.
>>
>> Eg:
>> https://wiki.osgeo.org/wiki/OSGeoLive_AddProject#What_gets_into_OSGeoLive.3F
>>
>> We also keep track of the status of each project in a publicly visible
>> table, and often reference it to project maintainers. Eg: See doc review
>> column for v11.0 release:
>>
>>
>> https://docs.google.com/spreadsheets/d/1Q5BaEgQtgw4O1bXyeWMlM8XtAOhUgcjZ7Y2O0FZc2H0/edit?hl=en_GB#gid=2014800150
>>
>>
>> On 27/9/19 8:17 am, DelazJ wrote:
>>
>> Hi,
>>
>> Cameron, the idea is to put in actions some affordable items that were
>> pointed in the recent discussion you raised, while "waiting" for some more
>> political (in the honourable sense) moves.
>> Yes, we'll indeed need to find key dates/events that would help us
>> structure the timeline up to the release date (thanks for the pointers).
>> But since we are a single project, it'd be hard to apply the "not complete
>> - not included" rule you apply (or I did misunderstand you?).
>>
>>
>>> 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
>>>>
>>> --
>> Cameron Shorter
>> Technology Demystifier
>> Open Technologies and Geospatial Consultant
>>
>> M +61 (0) 419 142 254
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-community-team/attachments/20190927/520f4f98/attachment-0001.html>