On Fri, Apr 9, 2021 at 11:11 PM Alexis R.L. <[email protected]> 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 <[email protected]> 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 [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
