Hi all,<br><br>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?<br>Btw, last PSC meeting minutes are missing at <a href="https://github.com/qgis/QGIS/wiki#psc-meeting-minutes">https://github.com/qgis/QGIS/wiki#psc-meeting-minutes</a>. PSC, could that be fixed, please? Thanks.<br><br>Alexandre, I agree with most of your points:<br>* 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...);<br>* let the obsolete PyQGIS Cookbook to devs (or new writers, if ever) and Training manual to trainers;<br>* prioritize the doc infrastructure update. Richard, any news on this?<br><br>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.<br><br>Regards,<br>Harrissou<br><br>2017-06-15 11:30 GMT+02:00 Yves Jacolin <<a href="mailto:yjacolin@free.fr">yjacolin@free.fr</a>>:<br>><br>> Alexandre,<br>><br>> On mercredi 14 juin 2017 23:05:49 CEST Alexandre Neto wrote:<br>> > Harrissou et al.,<br>> ><br>> > Sorry for the silence, but this threads are so big that I never find time<br>> > to read and answer properly.<br>> ><br>> > Harrissou, thanks for gathering all that ideas and TODOs. Most of them are<br>> > in fact very important for 3.x (I dare to say 3.2 as I don't think we<br>> > should do an official doc release for 3.0).<br>> ><br>> > Our biggest problem is (still) not having enough human power. We are barely<br>> > able to keep the User's Manual updated on time. Training manual probably is<br>> > few versions behind and PyQGIS cook book I have no idea. So, IMHO, we<br>> > should focus our efforts on what's more important. And for me it's the User<br>> > manual. Which I consider to be mandatory to deliver. The other two are nice<br>> > to have. For the cook book we need developers to take care of it, and the<br>> > training, we need trainers (people o rely on it to give training) to take<br>> > care of it.<br>> ><br>> > I say we should not ambiss to change 2.18 structure. Nor to make it<br>> > perfect. I would vote for setting a deadline and release the docs, even if<br>> > something was not completed. July would be ok for me.<br>> ><br>> > From that point on, we can focus on 3.x users manual and all the<br>> > improvements we would like to do. Planning the docs Restructuring would be<br>> > my top priority as we might not be  able to do it again soon (to not break<br>> > help links).<br>> ><br>> > My second priority would go to update the sphinx / bootstrap etc versions.<br>> ><br>> > Assuming that all tasks make sense, before even go to the PSC, I would add<br>> > a column with the needed (human) resources for each task. That will<br>> > probably determine what is going forward and what is not.<br>> ><br>> > I would not rush in converting the tasks into github issues for now. a wiki<br>> > or Google Doc may be more practical as we can see the all picture easily.<br>> > And we can elaborate a final document to send to others.<br>><br>> I agree with all above except this part: I am not sure that a wiki or Google<br>> doc will give you a nice picture of task to do. We can filter issue easily in<br>> "project" and/or milestone.<br>><br>> Y.<br>><br><br><br>