[QGIS-Developer] A plea: more volunteers needed for reviewing backports

Andreas Neumann a.neumann at carto.net
Wed May 5 02:06:27 PDT 2021


Hi all,

To answer the financial question here:

we had 6k EUR in the 2020 budget. This was distributed between Nyall 
(2.7k EUR) and Matthias/OPENGIS (2.7k EUR) and Alessandro (600 EUR, 
Server related reviews).

In 2021 we increased and approved the budget to 10k. I am waiting for a 
proposal how to distribute this amount in 2021.

Without having more sustaining members we can only increase these 10k by 
chipping away money from bug fixing (the bulk of our expenses) or the 
grant program (which is with 25k EUR not very large in 2021, less than 
in 2020).

But finances are only parts of the problem, as discussed here. The main 
issue might be finding skilled devs who know the code base well and 
distribute this task more evenly between diffferent shoulders. Of course 
there is a connection between available funds and finding people working 
on reviewing ...

Greetings,

Andreas

On 2021-05-01 13:04, Alessandro Pasotti wrote:

> Thank you Martin,
> 
> 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.
> 
> On Sat, May 1, 2021 at 12:33 PM Martin Dobias <wonder.sk at gmail.com> 
> wrote:
> 
> Hi all
> 
> On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson <nyall.dawson at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 

Alessandro Pasotti
QCooperative:  www.qcooperative.net [1] ItOpen:   www.itopen.it [2]
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



Links:
------
[1] https://www.qcooperative.net
[2] http://www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210505/22418620/attachment-0001.html>


More information about the QGIS-Developer mailing list