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

[Alessandro Pasotti]

On Fri, Apr 9, 2021 at 11:11 PM Alexis R.L. <alroyliz0 at gmail.com> wrote:
>
> I agree with Gio and I was curious as to why some bugs are funded but not reviewing. Reviewing can help prevent some bugs and has also the potential to improve a PR.
>
> I'd also say that improving the review pace will help losing PR to stalebot. In my eyes bugfix are crucial, but new features are also important, and those seem to require more time to review. New features also help promote QGIS and compete against other software.
>
> Funding could be done like bugs or like grants, with or without a selection process. This would help competent devs to devote more of their time to reviewing.
>
> Alex
>
>
> Le ven. 9 avr. 2021 à 12:42, Giovanni Manghi <giovanni.manghi at gmail.com> a écrit :
>>
>> Hi all,
>>
>>
>> > 2.  we may have a (partially paid?) role for the review manager, to go
>> > through the PR queue, ping people for reviews, etc.
>>
>> Has this been considered/discussed (having 1 or more paid reviewers)?
>>
>> At very least this seems a reasonable solution until we are not able
>> to bring in more reviewers.
>>


Hi,

this was discussed a few times, just to clarify where we stand now:

- during the last few year there has been a small QGIS.org budget for
PR queue management which includes reviews to some extent, see the
budget documents and financial reports
https://www.qgis.org/en/site/getinvolved/governance/finance/index.html?highlight=finances,
Matthias, Nyall and (recently, for a small part) myself have been the
recipients of the funds. I can only speak for myself but I'm pretty
sure that this stands also for Nyall and Matthias when I say that
these funds only covered a tiny fraction of the time that we spend on
PR reviews.
- most core developers that I personally know, regularly allocate
budget for doing PR reviews when they do paid work, this budget is
used for PR reviews by other QGIS core committers of the same company
(if your company is so lucky to have more than one) or on an exchange
basis, for example Nyall asks me to review his PR and I ask him to do
the same for me (which happens more often than the opposite): this
happens all the times.
- when we (core developers) work on the QGIS.org paid bugfixing
program before the releases we switch to full "QGIS dev" mode and we
also do PR reviews because it's just part of the process.

Now, my personal opinion about where the problems are and how to
possibly solve them, I'm talking about the most complex PRs, obviously
there are PRs that are really trivial and quick to review:

- PR reviews may be very hard and time consuming and are an assumption
of responsibility, I don't think that there is any single developer
who feels comfortable to do reviews on the entire (huge) QGIS code
base.
- As already mentioned by Matthias, there are blurry lines between
what is acceptable for backporting, the policy has changed a few times
and it is not yet entirely clear to me, this can slow down the PR
review process on backports.
- PR reviews require a deep understanding of the QGIS internals plus a
knowledge of the history of the project and why things have been
implemented in a certain way (that doesn't obviously mean that they
couldn't be refactored).
- The entry barriers for QGIS developments are very high, we all know
that, the code base is huge, the different technologies you need to
know are many and the QA process (CI, tests, code style, spelling,
name your favourite blocker here) is terribly complex (with a reason
because it ultimately leads to better and more robust code!).

That said, I feel that we are now in a better situation than we were a
couple of years ago when the PR queue was much longer compared to now.

But how can we speed up the process?

- the obvious solution is to increase the budget for PR reviewers and
enlarge the number of developers involved to make sure we can cover a
larger area of the code base. Ideally we should be able to pay for a
regular time slot of each involved developer (say, just for example: 4
hours a week?), this may not be evenly distributed, for example a
developer that takes care of the server PRs might require a smaller
time slot than one that works on 3D (just an example, really).
- have clear rules about what can or cannot be backported and when (do
we skip a point release now?, for LTR only?)
- all developers that are working on a funded feature/bugfix/whatever
**MUST** allocate budget for PR reviews (including backports) and take
care of that by paying another developer (if possible from a different
company).
- bring in more developers!

The last one is clearly very difficult and probably worth its own
thread, also because it cannot happen overnight.

What I am 100% sure about is that we cannot just hire some random
developer that knows little about QGIS development to do the work for
us, the burden of PR reviews must stay on the QGIS core developers
team, we must find a way to allow the core developers to **regularly**
spend more time on that activity.

And last but not least: time is a limiting resource and we all do have a life :)

-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it