<div dir="ltr"><div>Thank you Martin,</div><div><br></div><div>I agree with your proposal, this is in line with what we have already discussed and it sounds a sustainable way to solve the problem, I'm not sure about the budget though: Andreas will probably have more information on that.</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 1, 2021 at 12:33 PM Martin Dobias <<a href="mailto:wonder.sk@gmail.com">wonder.sk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This is a public plea for more developers who are very familiar with<br>
different parts of the QGIS codebase to become actively involved in<br>
backport PR management.<br></blockquote><div><br></div>(Nyall later clarified this is not only about backport PRs, but all reviews in general)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks for starting this thread - it is a discussion we definitely need to have. (And apologies for getting back to this soooo late!)<br><br>Pull request reviews are absolutely vital part of the QGIS development, a chance to get bugs fixed before they even get into QGIS code. Quality reviews also need a good amount of expertise of the QGIS code - often the hardest part of a review is not the code included is the pull request, but figuring out what is missing...<br><br>Speaking of myself, I used to review pull requests regularly... But after several years I have to admit I mostly gave up doing that unless someone asks me to do a review. The pace of QGIS development is not getting any slower (which is great!), so there is a constant flow of new pull requests and doing code reviews regularly is not something I want to do in my free time... I am happy to do some QGIS work in my free time, but only doing what I want to do :-)<br><br>For a company, strictly business speaking, sparing 15 minutes a day of a senior developer is roughly equivalent to lost profit of few thousands of EUR (assuming ~50 hours / year). And many reviews need much more time than 15 minutes... Moreover companies doing QGIS dev are often already donating to QGIS as sustaining members...<br><br>In a mail in the thread it was suggested that companies doing QGIS development should add extra cost to quotes to accommodate the time for reviews (of unrelated pull requests). Not sure I agree with that - if a company had constant income from QGIS dev, that's doable, but if we are talking about occasional QGIS dev work, that is hard to plan.<br><br>From all of that above, my thinking is that in order to make things sustainable, regular pull request reviews should be ideally funded by QGIS.org similarly to how paid bug-fixing sprints work. It is the kind of project maintainance work that needs to be done, it is not always super fun and it requires input of someone from a small group of people that are already donating lots of their free time.<br><br>My proposal would be therefore along these lines:<br>- PSC allocates annual budget to reviews<br>- core devs interested in participating would indicate their availability (eligibility may be the same as with paid bug fixing)<br>- PSC tells devs how much paid time they can spend on reviews<br>- paid devs should do reviews regularly, e.g. at least twice a week, ideally every day - not just once a month or so<br>- paid devs would self-assign themselves to PRs and do reviews<br>- if a PR is not picked up by anyone e.g. within 3 days, PR queue manager would assign it to one of the paid devs<br>- paid devs keep track of their time in a spreadsheet and invoice (quarterly?) up to the amount they were allocated<br><br>I believe this approach should solve our problems:<br>- remove stress from growing PR queue and reviewer burnout<br>- get more core devs (who otherwise may not be available) to do reviews<br>- reduce frustration from devs submitting PRs when their PRs are not getting attention<br><br>In my humble opinion, good quality reviews are even more important than the regular paid bug fixing or grants. A review that is rushed due to lack of time may omit important code details, or focus only on code style...<br><br>We could start with a relatively small budget and compensate the extremely valuable work that reviewers (Nyall and others) are already doing.<br><br></div><div class="gmail_quote">Regards</div><div class="gmail_quote">Martin</div><div class="gmail_quote"><br></div></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Alessandro Pasotti</div><div>QCooperative:  <a href="https://www.qcooperative.net" target="_blank">www.qcooperative.net</a><br></div>ItOpen:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div></div>