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

[DelazJ]

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