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

Thu Sep 26 15:17:50 PDT 2019

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

Le mar. 24 sept. 2019 à 23:38, Alexandre Neto <senhor.neto at gmail.com> a
écrit :

> Hello Harrissou et al.,
>
> I like the idea. I don't know if we are able to attract many more writers,
> but the idea of having a fixed timeline and a plan sounds good anyway.
>
> 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)

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