[Qgis-community-team] 2.18 LTR Documentation

[Yves Jacolin]

Harrissou,

I agreed with 1st of july for release. I will work on my last pending issue 
and work on another one next week.

I will finish the review of your PR next week.

Y.
On jeudi 15 juin 2017 21:17:13 CEST DelazJ wrote:
> Hi all,
> 
> For deadline, I propose to release it as soon as 2.18 is officially LTR
> (this is what we did (or tried?) for 2.14). The LTR status was supposed to
> be in may according to online roadmap but I didn't see any official message
> so I guess it has been postponed to june (ie, 23/06) so a week later, 1st
> of July (to keep Alexandre July proposal :) ) might be good. Would that
> planning be fine for you? Richard?
> Btw, last PSC meeting minutes are missing at
> https://github.com/qgis/QGIS/wiki#psc-meeting-minutes. PSC, could that be
> fixed, please? Thanks.
> 
> Alexandre, I agree with most of your points:
> * keep on prioritizing User manual update despite(/because of?) the
> desperate and demotivating lack of contributors (we don't only need
> writers, we also need readers, reviewers to help fix typo, give their
> opinions on pull requests or issues...);
> * let the obsolete PyQGIS Cookbook to devs (or new writers, if ever) and
> Training manual to trainers;
> * prioritize the doc infrastructure update. Richard, any news on this?
> 
> About the 2.18 doc release (we still have 2 weeks before deadline, if
> agreed), I'd however like to have the pending PRs merged. I have some I
> should complete and others that need feedbacks. This includes the
> restructuring PR which imho could easily allow to later backport fixes for
> some remaining 2.18 issues. Also, while restructuring those chapters is not
> a high priority (for 2.18), I consider it like a good step to ensure a
> better user experience: a use case I have in mind is eg, to configure the
> 2.18 localized doc as the default doc for QGIS 3 so one could access
> localized documentation from the application instead of testing (English
> only) doc. And due to the current implementation using full hyperlink,
> sharing the same structure than testing doc is needed to guarantee it
> succeeds.
> 
> Regards,
> Harrissou
> 
> 2017-06-15 11:30 GMT+02:00 Yves Jacolin <yjacolin at free.fr>:
> > Alexandre,
> > 
> > On mercredi 14 juin 2017 23:05:49 CEST Alexandre Neto wrote:
> > > Harrissou et al.,
> > > 
> > > Sorry for the silence, but this threads are so big that I never find
> 
> time
> 
> > > to read and answer properly.
> > > 
> > > Harrissou, thanks for gathering all that ideas and TODOs. Most of them
> 
> are
> 
> > > in fact very important for 3.x (I dare to say 3.2 as I don't think we
> > > should do an official doc release for 3.0).
> > > 
> > > Our biggest problem is (still) not having enough human power. We are
> 
> barely
> 
> > > able to keep the User's Manual updated on time. Training manual
> 
> probably is
> 
> > > few versions behind and PyQGIS cook book I have no idea. So, IMHO, we
> > > should focus our efforts on what's more important. And for me it's the
> 
> User
> 
> > > manual. Which I consider to be mandatory to deliver. The other two are
> 
> nice
> 
> > > to have. For the cook book we need developers to take care of it, and
> 
> the
> 
> > > training, we need trainers (people o rely on it to give training) to
> 
> take
> 
> > > care of it.
> > > 
> > > I say we should not ambiss to change 2.18 structure. Nor to make it
> > > perfect. I would vote for setting a deadline and release the docs, even
> 
> if
> 
> > > something was not completed. July would be ok for me.
> > > 
> > > From that point on, we can focus on 3.x users manual and all the
> > > improvements we would like to do. Planning the docs Restructuring would
> 
> be
> 
> > > my top priority as we might not be  able to do it again soon (to not
> 
> break
> 
> > > help links).
> > > 
> > > My second priority would go to update the sphinx / bootstrap etc
> 
> versions.
> 
> > > Assuming that all tasks make sense, before even go to the PSC, I would
> 
> add
> 
> > > a column with the needed (human) resources for each task. That will
> > > probably determine what is going forward and what is not.
> > > 
> > > I would not rush in converting the tasks into github issues for now. a
> 
> wiki
> 
> > > or Google Doc may be more practical as we can see the all picture
> 
> easily.
> 
> > > And we can elaborate a final document to send to others.
> > 
> > I agree with all above except this part: I am not sure that a wiki or
> 
> Google
> 
> > doc will give you a nice picture of task to do. We can filter issue
> 
> easily in
> 
> > "project" and/or milestone.
> > 
> > Y.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.osgeo.org/pipermail/qgis-community-team/attachments/20170616/7ab7669a/attachment.sig>