Hi all, I quite agree with Martin here. That's the only way to avoid the open source maintainer fatigue syndrom . As a community member, I think i t would be fair to have less expenses on Grants and more on the backgrounnd mandatory tasks like review, packaging and documentation. And I want to stress out we also need to ensure that at least two persons can run the tasks, because of this bus-factor thing for sure, but also because we all deserve vacations sometimes (included looong ones sometimes)
Best regards Régis On 01/05/2021 12:33, Martin Dobias wrote: > Hi all > > On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson <nyall.daw...@gmail.com > <mailto:nyall.daw...@gmail.com>> wrote: > > > This is a public plea for more developers who are very familiar with > different parts of the QGIS codebase to become actively involved in > backport PR management. > > > (Nyall later clarified this is not only about backport PRs, but all > reviews in general) > > Thanks for starting this thread - it is a discussion we definitely > need to have. (And apologies for getting back to this soooo late!) > > 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... > > 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 :-) > > 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... > > 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. > > 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. > > My proposal would be therefore along these lines: > - PSC allocates annual budget to reviews > - core devs interested in participating would indicate their > availability (eligibility may be the same as with paid bug fixing) > - PSC tells devs how much paid time they can spend on reviews > - paid devs should do reviews regularly, e.g. at least twice a week, > ideally every day - not just once a month or so > - paid devs would self-assign themselves to PRs and do reviews > - 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 > - paid devs keep track of their time in a spreadsheet and invoice > (quarterly?) up to the amount they were allocated > > I believe this approach should solve our problems: > - remove stress from growing PR queue and reviewer burnout > - get more core devs (who otherwise may not be available) to do reviews > - reduce frustration from devs submitting PRs when their PRs are not > getting attention > > 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... > > We could start with a relatively small budget and compensate the > extremely valuable work that reviewers (Nyall and others) are already > doing. > > Regards > Martin > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer