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

Sun Apr 11 23:26:30 PDT 2021

Hi Alex, Hi all,

Thank you for this very good summary, which summarizes the problems and
potential solutions pretty well. On the financial side I can say that for
2021 we increased the budget available for Github and Travis management,
and PR reviewing from 6k in 2020 to 10k in 2021 - related projects like the
Travis to Github CI migration are not included here and have their separate
budget item.

However, as Alessandro pointed out, the main issue here is finding skilled
persons who know the QGIS project and code base good enough to be able to
help in the reviewing process.

Nevertheless, I will try to increase the budget item dedicated to CI
maintenance and PR reviewing again in 2022. Hopefully, in parallel, the
reviewing process and rules can be better formalized and more people can
join the effort.

Greetings,
Andreas

On Sat, 10 Apr 2021 at 10:44, Alessandro Pasotti <apasotti at gmail.com> wrote:

> 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
> _______________________________________________
> 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
>

-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210412/b7c53746/attachment.html>