I also have work to do on the screenshots. I am currently updating processing and there are many figures that must be replaced, and maybe some text.
I am going to take care of it before the deadline. A sex, 16/06/2017, 09:52, Yves Jacolin <yjaco...@free.fr> escreveu: > 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 <yjaco...@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. > > -- Alexandre Neto --------------------- @AlexNetoGeo http://sigsemgrilhetas.wordpress.com http://gisunchained.wordpress.com
_______________________________________________ Qgis-community-team mailing list for organizing community resources such as documentation, translation etc.. Qgis-community-team@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-community-team