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

Fri Sep 27 11:23:11 PDT 2019

Dear all,
Interesting discussion.
I was thinking about something pointed in the previous discussion regarding the acknowledgement as a way to attract more contributors.
Perhaps the idea of tasks (Kanban template) can help to do so?
I am not sure since I am not so familiar with projects in GitHub.
Gr,

Rosa

From: Qgis-community-team <qgis-community-team-bounces at lists.osgeo.org> On Behalf Of Alexandre Neto
Sent: 27 September 2019 18:49
To: Junior <delazj at gmail.com>
Cc: qgis-community <qgis-community-team at lists.osgeo.org>
Subject: Re: [Qgis-community-team] Releasing QGIS 3.10 doc when 3.10 "becomes" LTR (fev 2020)

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<mailto: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<mailto: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<mailto: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/f41ea8f6/attachment.html>