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

[Alexandre Neto]

Hi,

A sexta, 27/09/2019, 19:23, r.m.aguilardearchila at utwente.nl <
r.m.aguilardearchila at utwente.nl> escreveu:

> .
>
> 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.
>

Yes, that is exactly what projects try to do, provide a kanban or scrum
board.

Alex

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