<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi all, <br>
</p>
<p>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)</p>
<p>Best regards</p>
<p>Régis<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 01/05/2021 12:33, Martin Dobias
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC2XbFf0n+xZMx_nVeNiJA0=c8DCpx_Aj4gzvx+UT6_p34rPpQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
</pre>
</blockquote>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>