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

[Alessandro Pasotti]

On Wed, May 5, 2021 at 12:05 PM Martin Dobias  wrote:

> Hi Andreas
>
> Thanks for the overview of the financial side of things. Regarding budget
> allocation it would make sense to me to reduce bug-fixing and grants budget
> and increase the spending on reviews. In my opinion both bug-fixing and
> grants need some improvements anyway to bring more value to QGIS project,
> but that's for a separate discussion (e.g. more focus on high priority
> bugs, better voting system for grants to consider relevance/impact +
> proposal quality + cost).
>

Yeah, we can certainly discuss how to improve both processes but, if I
mostly agree with you about the grants I believe that the bugfixing budget
should not be reduced (perhaps increased) and that being able to focus on
QGIS bugfixing for a given number of days really makes a difference.


>
> Speaking of myself, I would be happy to join the paid reviews efforts to
> lower the fatigue of reviewers. And I hope it would attract some other QGIS
> devs to join as well...
>
>
That would be awesome, thank you!

Cheers

-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Martin Dobias]

Hi Andreas

Thanks for the overview of the financial side of things. Regarding budget
allocation it would make sense to me to reduce bug-fixing and grants budget
and increase the spending on reviews. In my opinion both bug-fixing and
grants need some improvements anyway to bring more value to QGIS project,
but that's for a separate discussion (e.g. more focus on high priority
bugs, better voting system for grants to consider relevance/impact +
proposal quality + cost).

Speaking of myself, I would be happy to join the paid reviews efforts to
lower the fatigue of reviewers. And I hope it would attract some other QGIS
devs to join as well...

Regards
Martin


On Wed, May 5, 2021 at 11:06 AM Andreas Neumann  wrote:

> Hi all,
>
> To answer the financial question here:
>
> we had 6k € in the 2020 budget. This was distributed between Nyall (2.7k
> €) and Matthias/OPENGIS (2.7k €) and Alessandro (600 €, 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 € 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  wrote:
>
> Hi all
>
> On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson 
> 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 s 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

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

[Andreas Neumann]

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  
wrote:


Hi all

On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson  
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 s 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
_

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

[Alessandro Pasotti]

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  wrote:

> Hi all
>
> On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson 
> 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 s 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@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
ItOpen:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Régis Haubourg]

Hi all,

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)

Best regards

Régis


On 01/05/2021 12:33, Martin Dobias wrote:
> Hi all
>
> On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson  > 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 s 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@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Martin Dobias]

Hi all

On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson 
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 s 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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Matthias Kuhn]

On Fri, Apr 23, 2021 at 2:00 AM Nyall Dawson  wrote:

> On Fri, 9 Apr 2021 at 19:10, Matthias Kuhn  wrote:
> >
> > Hi,
> >
> > Thanks for the continued effort in reviewing. It's one of the
> not-so-visible-highly-technically-and-socially-qualified-people-needed-but-very-important
> aspects of (open source) software development.
> >
> > I try to go over the PR queue every now and then and
> merge/comment/review what's possible, but these days I find less time than
> in the past. While at the same time it seems pull request activity
> increases it seems.
> > I'll make sure we raise this topic at an upcoming OPENGIS.ch meeting and
> encourage people to participate.
> >
> > Additionally to what has been said already, backports are easy to forget
> / ignore by the original author because they have been opened by a bot and
> as an author you won't receive notifications by reviewers or the stale bot.
> I wonder if we could get the original author more involved if we'd mention
> them in the backport comment and increase their responsibility for this
> part. This might be worth some automation.
>
> I definitely think this would help. The mentality at the moment is
> predominantly that "as soon as the original PR is merged, the
> responsibility is no longer mine" and that "someone else" will handle
> the backports. In part this is due to how easy the bot has made
> backporting.. we've now all got the mentality that the bot will handle
> everything for us, but that's not the case in reality. I think
> tweaking the backport message so that the author is mentioned will
> help here, as at least they'll get notified if we close the backport
> due to merge conflicts/etc. I'd also love to see the bot fixed so that
> commits are cherry-picked and the ORIGINAL author name is attributed
> to the commit. I think this is very important for accountability...
> currently all the backport commits are anonymous and attributed to the
> bot only, which makes it hard to tell who is responsible for the
> change. I wish we could keep the original author here, as I think this
> helps increase burden of responsiblity for that author... A poor
> quality or buggy backport will directly reflect on their reputation,
> so they are more likely to self-police backport PRs and ensure they
> are suitable for merge. (At least, I hope so).
>

Points addressed in an update to the backport bot. Merge commits are
"unpacked", responsibility given to the original author. (Rebase merges
still not supported).
I'm not super confident about everything I did here, if the backport bot
behaves weird in the next few days, please let me know.


>
> The other really painful thing with backport bot is that we have to
> manually close and reopen ALL automated backports in order for the
> tests to run. It's a minor thing, but definitely contributes to the
> "chore" and drudgery of maintaining the PR list. Especially because
> only a few have permission to do this, and unless the original
> contributor has merge rights they can't even close/open their own
> backports to help speed things along.
>

Not sure what's happening, any idea why?


>
> Don't get me wrong - backport bot *is* great, and has simplified work
> a lot. But with a bit more investment and refinement it could be
> incredible and save me substantially more time!
>
> > Something else is that for example for me, the process to decide which
> backports get into pending backports was not obvious at first (only the LTR
> or also LR? At which stage of the LTR? How exactly do they get in there?),
> I'm sure for other people there are other parts of the process that are not
> immediately clear. I think documenting the review process could help here
> (the suggestions written by Nyall above for a lower entry barrier into the
> reviewer process would already be worth mentioning).
>
> Right, we should definitely document this better. I'd suggest you and
> I get together sometime to do this, as we've been appointed this
> responsibility by PSC already. Can you ping me off list so we can
> arrange this?
>

Done

Matthias
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On Fri, 9 Apr 2021 at 17:21, Peter Petrik
 wrote:
>
> Hi,
>
> First of all, thanks Nyall for your efforts. I try to review the code that we 
> introduced to QGIS and I find kind-of familiar: for example QgsQuick, 
> MeshLayer or MacOS stuff. But as mentioned in the thread, the less you know 
> the particular code, the more time it takes to review it.  What I see that I 
> can improve is to actively at least twice per week double check the PR queue 
> to see if there is something in this area, since sometimes I need to be 
> pinged to get a notification in email that the PR is waiting for review.
>
> What are my thoughts on other improvements not mentioned by Nyall and others:
> 1. when someone introduces a new feature (and most notably coming from a paid 
> contract), the review process should be taken into account in the quote and 
> the reviewer should be notified. Proper review can take days...

I agree... but realistically, how often is this done? In the 10 years
I've had merge rights I've been paid **once** to review a big PR. I'd
be interested to hear other's experiences here.

(Personally I'll always include a disclaimer in my quotes that that
work has to go through peer review and may be blocked by the larger
community. And then I'll trade on social capital or trade
review-for-review in order to get my PRs reviewed as quickly as
possible. I've also never directly paid anyone external for a review.)

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On Fri, 9 Apr 2021 at 19:10, Matthias Kuhn  wrote:
>
> Hi,
>
> Thanks for the continued effort in reviewing. It's one of the 
> not-so-visible-highly-technically-and-socially-qualified-people-needed-but-very-important
>  aspects of (open source) software development.
>
> I try to go over the PR queue every now and then and merge/comment/review 
> what's possible, but these days I find less time than in the past. While at 
> the same time it seems pull request activity increases it seems.
> I'll make sure we raise this topic at an upcoming OPENGIS.ch meeting and 
> encourage people to participate.
>
> Additionally to what has been said already, backports are easy to forget / 
> ignore by the original author because they have been opened by a bot and as 
> an author you won't receive notifications by reviewers or the stale bot. I 
> wonder if we could get the original author more involved if we'd mention them 
> in the backport comment and increase their responsibility for this part. This 
> might be worth some automation.

I definitely think this would help. The mentality at the moment is
predominantly that "as soon as the original PR is merged, the
responsibility is no longer mine" and that "someone else" will handle
the backports. In part this is due to how easy the bot has made
backporting.. we've now all got the mentality that the bot will handle
everything for us, but that's not the case in reality. I think
tweaking the backport message so that the author is mentioned will
help here, as at least they'll get notified if we close the backport
due to merge conflicts/etc. I'd also love to see the bot fixed so that
commits are cherry-picked and the ORIGINAL author name is attributed
to the commit. I think this is very important for accountability...
currently all the backport commits are anonymous and attributed to the
bot only, which makes it hard to tell who is responsible for the
change. I wish we could keep the original author here, as I think this
helps increase burden of responsiblity for that author... A poor
quality or buggy backport will directly reflect on their reputation,
so they are more likely to self-police backport PRs and ensure they
are suitable for merge. (At least, I hope so).

The other really painful thing with backport bot is that we have to
manually close and reopen ALL automated backports in order for the
tests to run. It's a minor thing, but definitely contributes to the
"chore" and drudgery of maintaining the PR list. Especially because
only a few have permission to do this, and unless the original
contributor has merge rights they can't even close/open their own
backports to help speed things along.

Don't get me wrong - backport bot *is* great, and has simplified work
a lot. But with a bit more investment and refinement it could be
incredible and save me substantially more time!

> Something else is that for example for me, the process to decide which 
> backports get into pending backports was not obvious at first (only the LTR 
> or also LR? At which stage of the LTR? How exactly do they get in there?), 
> I'm sure for other people there are other parts of the process that are not 
> immediately clear. I think documenting the review process could help here 
> (the suggestions written by Nyall above for a lower entry barrier into the 
> reviewer process would already be worth mentioning).

Right, we should definitely document this better. I'd suggest you and
I get together sometime to do this, as we've been appointed this
responsibility by PSC already. Can you ping me off list so we can
arrange this?

Nyall


>
> I hope I'll find more time again for reviews myself in the future.
> I actually enjoyed it a lot in the past; it has influenced my development a 
> lot over the years as it allowed me to discuss concepts and approaches with 
> experts from all over the globe, more than I had the chance before in the SMB 
> offices I have been employed before.
>
> Matthias
>
> On Fri, Apr 9, 2021 at 9:21 AM Peter Petrik 
>  wrote:
>>
>> Hi,
>>
>> First of all, thanks Nyall for your efforts. I try to review the code that 
>> we introduced to QGIS and I find kind-of familiar: for example QgsQuick, 
>> MeshLayer or MacOS stuff. But as mentioned in the thread, the less you know 
>> the particular code, the more time it takes to review it.  What I see that I 
>> can improve is to actively at least twice per week double check the PR queue 
>> to see if there is something in this area, since sometimes I need to be 
>> pinged to get a notification in email that the PR is waiting for review.
>>
>> What are my thoughts on other improvements not mentioned by Nyall and others:
>> 1. when someone introduces a new feature (and most notably coming from a 
>> paid contract), the review process should be taken into account in the quote 
>> and the reviewer should be notified. Proper review can take days...
>> 2.  we may have a (partially paid?) role for the review manager, to go 
>> through the PR queue

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

[Andreas Neumann]

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  wrote:

> On Fri, Apr 9, 2021 at 11:11 PM Alexis R.L.  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 
> 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 slo

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

[Nyall Dawson]

On Thu, 8 Apr 2021 at 08:28, Nyall Dawson  wrote:
>
> On Tue, 23 Mar 2021 at 09:06, Nyall Dawson  wrote:
> >
> > Hi list,
> >
> > 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.
> >
> > We NEED more people to be actively (i.e. daily) monitoring for
> > backport PRs and then reviewing them if the backport affects code
> > areas which they're knowledgeable about.
> >
>
> Well my earlier plea seems like it fell on deaf ears, and we've seen
> only minimal assistance coming to maintain the PR queue since I posted
> this.
>

Hi all -- just wanted to send out a quick "thanks" to everyone who has
replied and the valuable discussion this has kicked off. I'm going
(mostly) off grid for the next week (camping) so my replies to
incoming emails will be delayed, but I promise to reply to all the
questions sent my way when I'm back :)

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Alessandro Pasotti]

On Fri, Apr 9, 2021 at 11:11 PM Alexis R.L.  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  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.

An

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

[Alexis R.L.]

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  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.
>
> cheers
>
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Giovanni Manghi]

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.

cheers

-- G --
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Matthias Kuhn]

Hi,

Thanks for the continued effort in reviewing. It's one of the
not-so-visible-highly-technically-and-socially-qualified-people-needed-but-very-important
aspects of (open source) software development.

I try to go over the PR queue every now and then and merge/comment/review
what's possible, but these days I find less time than in the past. While at
the same time it seems pull request activity increases it seems.
I'll make sure we raise this topic at an upcoming OPENGIS.ch meeting and
encourage people to participate.

Additionally to what has been said already, backports are easy to forget /
ignore by the original author because they have been opened by a bot and as
an author you won't receive notifications by reviewers or the stale bot. I
wonder if we could get the original author more involved if we'd mention
them in the backport comment and increase their responsibility for this
part. This might be worth some automation.

Something else is that for example for me, the process to decide which
backports get into pending backports was not obvious at first (only the LTR
or also LR? At which stage of the LTR? How exactly do they get in there?),
I'm sure for other people there are other parts of the process that are not
immediately clear. I think documenting the review process could help here
(the suggestions written by Nyall above for a lower entry barrier into the
reviewer process would already be worth mentioning).

I hope I'll find more time again for reviews myself in the future.
I actually enjoyed it a lot in the past; it has influenced my development a
lot over the years as it allowed me to discuss concepts and approaches with
experts from all over the globe, more than I had the chance before in the
SMB offices I have been employed before.

Matthias

On Fri, Apr 9, 2021 at 9:21 AM Peter Petrik <
peter.pet...@lutraconsulting.co.uk> wrote:

> Hi,
>
> First of all, thanks Nyall for your efforts. I try to review the code that
> we introduced to QGIS and I find kind-of familiar: for example QgsQuick,
> MeshLayer or MacOS stuff. But as mentioned in the thread, the less you know
> the particular code, the more time it takes to review it.  What I see that
> I can improve is to actively at least twice per week double check the PR
> queue to see if there is something in this area, since sometimes I need to
> be pinged to get a notification in email that the PR is waiting for review.
>
> What are my thoughts on other improvements not mentioned by Nyall and
> others:
> 1. when someone introduces a new feature (and most notably coming from a
> paid contract), the review process should be taken into account in the
> quote and the reviewer should be notified. Proper review can take days...
> 2.  we may have a (partially paid?) role for the review manager, to go
> through the PR queue, ping people for reviews, etc. (Alternatively) create
> some github-action bot to assign the maintainers to the PRs as reviewers?
> 3. reintroduce the maintainers of particular QGIS code-base. For example
> here the motivation for companies could be to advertise their logo in the
> "sustainable member section"  or introducing some other category to
> advertise their efforts.
>
> Cheers,
> Peter
>
>
> On Fri, Apr 9, 2021 at 7:45 AM Nyall Dawson 
> wrote:
>
>> On Thu, 8 Apr 2021 at 18:26, Julien Cabieces
>>  wrote:
>> >
>> >
>> > Hi Nyall,
>> >
>> > We (at Oslandia) heard your call for more volunteers in reviewing the
>> backports and PRs.
>> >
>> > We are very well aware that our contribution effort for this task is
>> not enough. I see mainly two reasons:
>> > - Lack of time and human ressources to fullfill this task. This is a
>> bad reason, and a well known situation that we need to take care of
>> internally, to free our schedule.
>> > - A very partial knowledge of the code base in which we feel relevant
>> to review. I try myself to review all Oracle related PRs, or take a look in
>> some part of the code I know enough to make a good review,
>>
>> It would certainly be remiss of me not to acknowledge your hard work
>> in maintaining the Oracle provider over recent months -- it's
>> certainly very highly valued!
>>
>> > but it's very little compared to the QGIS code base.
>>
>> This is where things get really tricky. We do have a very small pool
>> of people with the required expertise to handle the reviewing process,
>> and it's a very fine balancing act of "opening this up to a wider
>> community" vs "ensure that nothing nasty gets through". I don't have
>> any easy answers here, but a few random thoughts:
>>
>> - ANY review is appreciated, even if it's just a "I had a look at this
>> and the c++ code looks good to me, but I'm not familiar with the QGIS
>> raster api so can someone else check this part out".
>> - There's a lot of "chore" work in the pr review process which has a
>> lower barrier of entry. For instance guiding new contributors through
>> the QGIS processes such as the formatting scripts and CI setup. We
>> regular

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

[Peter Petrik]

Hi,

First of all, thanks Nyall for your efforts. I try to review the code that
we introduced to QGIS and I find kind-of familiar: for example QgsQuick,
MeshLayer or MacOS stuff. But as mentioned in the thread, the less you know
the particular code, the more time it takes to review it.  What I see that
I can improve is to actively at least twice per week double check the PR
queue to see if there is something in this area, since sometimes I need to
be pinged to get a notification in email that the PR is waiting for review.

What are my thoughts on other improvements not mentioned by Nyall and
others:
1. when someone introduces a new feature (and most notably coming from a
paid contract), the review process should be taken into account in the
quote and the reviewer should be notified. Proper review can take days...
2.  we may have a (partially paid?) role for the review manager, to go
through the PR queue, ping people for reviews, etc. (Alternatively) create
some github-action bot to assign the maintainers to the PRs as reviewers?
3. reintroduce the maintainers of particular QGIS code-base. For example
here the motivation for companies could be to advertise their logo in the
"sustainable member section"  or introducing some other category to
advertise their efforts.

Cheers,
Peter


On Fri, Apr 9, 2021 at 7:45 AM Nyall Dawson  wrote:

> On Thu, 8 Apr 2021 at 18:26, Julien Cabieces
>  wrote:
> >
> >
> > Hi Nyall,
> >
> > We (at Oslandia) heard your call for more volunteers in reviewing the
> backports and PRs.
> >
> > We are very well aware that our contribution effort for this task is not
> enough. I see mainly two reasons:
> > - Lack of time and human ressources to fullfill this task. This is a bad
> reason, and a well known situation that we need to take care of internally,
> to free our schedule.
> > - A very partial knowledge of the code base in which we feel relevant to
> review. I try myself to review all Oracle related PRs, or take a look in
> some part of the code I know enough to make a good review,
>
> It would certainly be remiss of me not to acknowledge your hard work
> in maintaining the Oracle provider over recent months -- it's
> certainly very highly valued!
>
> > but it's very little compared to the QGIS code base.
>
> This is where things get really tricky. We do have a very small pool
> of people with the required expertise to handle the reviewing process,
> and it's a very fine balancing act of "opening this up to a wider
> community" vs "ensure that nothing nasty gets through". I don't have
> any easy answers here, but a few random thoughts:
>
> - ANY review is appreciated, even if it's just a "I had a look at this
> and the c++ code looks good to me, but I'm not familiar with the QGIS
> raster api so can someone else check this part out".
> - There's a lot of "chore" work in the pr review process which has a
> lower barrier of entry. For instance guiding new contributors through
> the QGIS processes such as the formatting scripts and CI setup. We
> regularly get PRs from first-time contributors and they almost always
> need some mentoring in the QGIS processes before they pass the CI
> setup and are ready for an in-depth review. This is the kind of thing
> which we should ideally do ASAP, as the faster we get the contributors
> through the initial maze of QGIS contributions the more likely they
> are to continue to contribute.
> - We've discussed this before, but a quick comment from a
> non-developer on new contributors PRs to say "great work, welcome
> abroad, this sounds like a very valuable contribution" is enough to
> give the project a positive vibe and give motivation to the submitter
> to get their PR in shape to merge
> - PR reviewing is a great way to learn new parts of the QGIS codebase ;)
>
> > I hesitated answering your first email, saying basically that we will
> try to improve the situation, but it would have been just a promise, and
> I'm not sure that we would have been able to keep it, regarding the points
> I described above.
>
> I really appreciate the reply, and the time you've taken to drop your
> thoughts into this conversation!
>
> Nyall
>
>
>
>
> >
> >
> > Kind regard,
> > Julien
> >
> > > On Tue, 23 Mar 2021 at 09:06, Nyall Dawson 
> wrote:
> > >>
> > >> Hi list,
> > >>
> > >> 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.
> > >>
> > >> We NEED more people to be actively (i.e. daily) monitoring for
> > >> backport PRs and then reviewing them if the backport affects code
> > >> areas which they're knowledgeable about.
> > >>
> > >
> > > Well my earlier plea seems like it fell on deaf ears, and we've seen
> > > only minimal assistance coming to maintain the PR queue since I posted
> > > this.
> > >
> > > I'll ask nicely once more. If you're an organisation involved in QGIS
> > > development, you NEED to donate time to maintaining this li

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

[Nyall Dawson]

On Thu, 8 Apr 2021 at 18:26, Julien Cabieces
 wrote:
>
>
> Hi Nyall,
>
> We (at Oslandia) heard your call for more volunteers in reviewing the 
> backports and PRs.
>
> We are very well aware that our contribution effort for this task is not 
> enough. I see mainly two reasons:
> - Lack of time and human ressources to fullfill this task. This is a bad 
> reason, and a well known situation that we need to take care of internally, 
> to free our schedule.
> - A very partial knowledge of the code base in which we feel relevant to 
> review. I try myself to review all Oracle related PRs, or take a look in some 
> part of the code I know enough to make a good review,

It would certainly be remiss of me not to acknowledge your hard work
in maintaining the Oracle provider over recent months -- it's
certainly very highly valued!

> but it's very little compared to the QGIS code base.

This is where things get really tricky. We do have a very small pool
of people with the required expertise to handle the reviewing process,
and it's a very fine balancing act of "opening this up to a wider
community" vs "ensure that nothing nasty gets through". I don't have
any easy answers here, but a few random thoughts:

- ANY review is appreciated, even if it's just a "I had a look at this
and the c++ code looks good to me, but I'm not familiar with the QGIS
raster api so can someone else check this part out".
- There's a lot of "chore" work in the pr review process which has a
lower barrier of entry. For instance guiding new contributors through
the QGIS processes such as the formatting scripts and CI setup. We
regularly get PRs from first-time contributors and they almost always
need some mentoring in the QGIS processes before they pass the CI
setup and are ready for an in-depth review. This is the kind of thing
which we should ideally do ASAP, as the faster we get the contributors
through the initial maze of QGIS contributions the more likely they
are to continue to contribute.
- We've discussed this before, but a quick comment from a
non-developer on new contributors PRs to say "great work, welcome
abroad, this sounds like a very valuable contribution" is enough to
give the project a positive vibe and give motivation to the submitter
to get their PR in shape to merge
- PR reviewing is a great way to learn new parts of the QGIS codebase ;)

> I hesitated answering your first email, saying basically that we will try to 
> improve the situation, but it would have been just a promise, and I'm not 
> sure that we would have been able to keep it, regarding the points I 
> described above.

I really appreciate the reply, and the time you've taken to drop your
thoughts into this conversation!

Nyall




>
>
> Kind regard,
> Julien
>
> > On Tue, 23 Mar 2021 at 09:06, Nyall Dawson  wrote:
> >>
> >> Hi list,
> >>
> >> 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.
> >>
> >> We NEED more people to be actively (i.e. daily) monitoring for
> >> backport PRs and then reviewing them if the backport affects code
> >> areas which they're knowledgeable about.
> >>
> >
> > Well my earlier plea seems like it fell on deaf ears, and we've seen
> > only minimal assistance coming to maintain the PR queue since I posted
> > this.
> >
> > I'll ask nicely once more. If you're an organisation involved in QGIS
> > development, you NEED to donate time to maintaining this list. It's
> > not enough to just ensure your own PRs get through the queue, you HAVE
> > to help with the shared burden of getting others PRs reviewed and
> > merged.
> >
> > This callout applies to ALL organisations who are making money from
> > core QGIS development. You know who you are, and you can ALL afford to
> > donate 30 minutes of a staff member's time each week to helping with
> > this shared burden. If your boss is blocking this then you NEED to let
> > them know how big a risk they are running here. It's not fair to leave
> > this responsibility on the already burdened shoulders of a few
> > overworked individuals.
> >
> > Nyall
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Julien Cabieces]

Hi Nyall, 

We (at Oslandia) heard your call for more volunteers in reviewing the backports 
and PRs.

We are very well aware that our contribution effort for this task is not 
enough. I see mainly two reasons: 
- Lack of time and human ressources to fullfill this task. This is a bad 
reason, and a well known situation that we need to take care of internally, to 
free our schedule.
- A very partial knowledge of the code base in which we feel relevant to 
review. I try myself to review all Oracle related PRs, or take a look in some 
part of the code I know enough to make a good review, but it's very little 
compared to the QGIS code base. 

I hesitated answering your first email, saying basically that we will try to 
improve the situation, but it would have been just a promise, and I'm not sure 
that we would have been able to keep it, regarding the points I described above.

Kind regard, 
Julien

> On Tue, 23 Mar 2021 at 09:06, Nyall Dawson  wrote:
>>
>> Hi list,
>>
>> 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.
>>
>> We NEED more people to be actively (i.e. daily) monitoring for
>> backport PRs and then reviewing them if the backport affects code
>> areas which they're knowledgeable about.
>>
>
> Well my earlier plea seems like it fell on deaf ears, and we've seen
> only minimal assistance coming to maintain the PR queue since I posted
> this.
>
> I'll ask nicely once more. If you're an organisation involved in QGIS
> development, you NEED to donate time to maintaining this list. It's
> not enough to just ensure your own PRs get through the queue, you HAVE
> to help with the shared burden of getting others PRs reviewed and
> merged.
>
> This callout applies to ALL organisations who are making money from
> core QGIS development. You know who you are, and you can ALL afford to
> donate 30 minutes of a staff member's time each week to helping with
> this shared burden. If your boss is blocking this then you NEED to let
> them know how big a risk they are running here. It's not fair to leave
> this responsibility on the already burdened shoulders of a few
> overworked individuals.
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Paolo Cavallini]

Hi Nyall,

Il 08/04/21 00:28, Nyall Dawson ha scritto:

> Well my earlier plea seems like it fell on deaf ears, and we've seen
> only minimal assistance coming to maintain the PR queue since I posted
> this.

as a PSC we have talked about this.
With my business hat on, I can assure you we have not been deaf to your
call. I have thought about how to contribute to solve this, bt I did not
find a practical way to do it. The main point (clearly outlined by
Alessandro Pasotti during our latest PSC) is that very few people are
technically able to review the PRs, and usually only for the part of
code they already know well. I think this explains the lack of response.
To improve the situation I think we should provide an easy way to
contribute, in a way that actually favours those who contribute.
All the best.
-- 
Paolo Cavallini
www.faunalia.eu - QGIS.org
training, support, development on QGIS, PostGIS and more
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On Tue, 23 Mar 2021 at 09:06, Nyall Dawson  wrote:
>
> Hi list,
>
> 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.
>
> We NEED more people to be actively (i.e. daily) monitoring for
> backport PRs and then reviewing them if the backport affects code
> areas which they're knowledgeable about.
>

Well my earlier plea seems like it fell on deaf ears, and we've seen
only minimal assistance coming to maintain the PR queue since I posted
this.

I'll ask nicely once more. If you're an organisation involved in QGIS
development, you NEED to donate time to maintaining this list. It's
not enough to just ensure your own PRs get through the queue, you HAVE
to help with the shared burden of getting others PRs reviewed and
merged.

This callout applies to ALL organisations who are making money from
core QGIS development. You know who you are, and you can ALL afford to
donate 30 minutes of a staff member's time each week to helping with
this shared burden. If your boss is blocking this then you NEED to let
them know how big a risk they are running here. It's not fair to leave
this responsibility on the already burdened shoulders of a few
overworked individuals.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Andreas Neumann]

Hi Nyall,

Thanks for raising this issue!

Back in the "old days" we had assigned "maintainers" to different areas of
the code base. Maybe we could revive this idea but rename it to "reviewers"
and ideally assign more than one person to each area of expertise? It could
be published again, somewhere in the governance section of our website,
e.g. at https://www.qgis.org/en/site/getinvolved/governance/governance.html

As a side effect, if we had such a list, a potential customer could also
see - oh this developer is a reviewer/maintainer of this particular topic -
it could be an incentive to pick this developer or company for development
work. For some insiders, it is a well-known which dev/company has expertise
in which area of QGIS, but for non-insiders, this is not really obvious.

Ideally, besides the volunteers, each of the companies that is active in
QGIS development (like Lutra, Oslandia, OPENGIS, 3Liz, etc. - just to name
a few) could offer one person as a reviewer to a certain area in the code
base. Of course, some, such as Norbit and Lutra are already really active
in packaging QGIS ... and North Road and OPENGIS is already quite active in
reviewing and other maintenance work.

Greetings,
Andreas

On Tue, 23 Mar 2021 at 00:06, Nyall Dawson  wrote:

> Hi list,
>
> 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.
>
> We NEED more people to be actively (i.e. daily) monitoring for
> backport PRs and then reviewing them if the backport affects code
> areas which they're knowledgeable about.
>
> Right now there's like... 2... of us doing this on a daily basis, and
> we need more hands and eyes. Regressions are fixed by backports, but
> they can also be introduced by backports. If we don't get more people
> involved in this part of QGIS' maintenance then the stability of the
> patch releases is compromised.
>
> While I'm more than happy to keep reviewing backports which touch
> areas of code I know well, we have a whole stack of backports for
> server fixes, relation fixes, and other parts of QGIS I don't know
> well enough to risk release stability by reviewing myself. These
> backports are currently sitting in the queue for weeks without review,
> and often they stale out and are closed without ever getting merged.
>
> I've also a ton of backports for fixes that I make on a daily basis
> which I cannot self review, so the PR queue gets flooded with my
> backports until I actively pester/harass others to review and approve.
>
> The truth is that the longer the PR queue, the more it stresses me out
> and the less motivation I have to review the incoming feature PRs. We
> have many older feature PRs which are stalled and waiting review for
> months or longer, just because I'm so flooded with managing newer
> incoming PRs that I never have time to review the older ones...
>
> So please, if you know parts of the QGIS code well, and can spare 15
> minutes a day to looking over the backport queue and approving any
> backports you are confident are regression free, then please get
> involved! (or ask your employer to officially allocate you this 15
> minutes/day as a way of them supporting QGIS!)
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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)
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Alexis R.L.]

Greetings,

I'm curious to know if all backport should be reviewed. In theory other
than major code rework backports should be retrocompatible. Assuming they
are most often done by domain experts as is mostly the case, would it be
too risky to merge if the main PR was reviewed and the tests are all green?

I'd agree there should be exceptions such as after major refactoring (if
exclusive to some versions).

Or could there be some way to simply identify backport that would require
review and those that would not affect more than the intended area? I'm
also curious to know if there could be a way to rely less on the few
highly-skilled contributors that are active when it comes to more minor
things (if there are such a thing).

Thanks as usual and have a great day,

Alex


Le lun. 22 mars 2021 à 19:07, Nyall Dawson  a
écrit :

> Hi list,
>
> 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.
>
> We NEED more people to be actively (i.e. daily) monitoring for
> backport PRs and then reviewing them if the backport affects code
> areas which they're knowledgeable about.
>
> Right now there's like... 2... of us doing this on a daily basis, and
> we need more hands and eyes. Regressions are fixed by backports, but
> they can also be introduced by backports. If we don't get more people
> involved in this part of QGIS' maintenance then the stability of the
> patch releases is compromised.
>
> While I'm more than happy to keep reviewing backports which touch
> areas of code I know well, we have a whole stack of backports for
> server fixes, relation fixes, and other parts of QGIS I don't know
> well enough to risk release stability by reviewing myself. These
> backports are currently sitting in the queue for weeks without review,
> and often they stale out and are closed without ever getting merged.
>
> I've also a ton of backports for fixes that I make on a daily basis
> which I cannot self review, so the PR queue gets flooded with my
> backports until I actively pester/harass others to review and approve.
>
> The truth is that the longer the PR queue, the more it stresses me out
> and the less motivation I have to review the incoming feature PRs. We
> have many older feature PRs which are stalled and waiting review for
> months or longer, just because I'm so flooded with managing newer
> incoming PRs that I never have time to review the older ones...
>
> So please, if you know parts of the QGIS code well, and can spare 15
> minutes a day to looking over the backport queue and approving any
> backports you are confident are regression free, then please get
> involved! (or ask your employer to officially allocate you this 15
> minutes/day as a way of them supporting QGIS!)
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

Hi list,

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.

We NEED more people to be actively (i.e. daily) monitoring for
backport PRs and then reviewing them if the backport affects code
areas which they're knowledgeable about.

Right now there's like... 2... of us doing this on a daily basis, and
we need more hands and eyes. Regressions are fixed by backports, but
they can also be introduced by backports. If we don't get more people
involved in this part of QGIS' maintenance then the stability of the
patch releases is compromised.

While I'm more than happy to keep reviewing backports which touch
areas of code I know well, we have a whole stack of backports for
server fixes, relation fixes, and other parts of QGIS I don't know
well enough to risk release stability by reviewing myself. These
backports are currently sitting in the queue for weeks without review,
and often they stale out and are closed without ever getting merged.

I've also a ton of backports for fixes that I make on a daily basis
which I cannot self review, so the PR queue gets flooded with my
backports until I actively pester/harass others to review and approve.

The truth is that the longer the PR queue, the more it stresses me out
and the less motivation I have to review the incoming feature PRs. We
have many older feature PRs which are stalled and waiting review for
months or longer, just because I'm so flooded with managing newer
incoming PRs that I never have time to review the older ones...

So please, if you know parts of the QGIS code well, and can spare 15
minutes a day to looking over the backport queue and approving any
backports you are confident are regression free, then please get
involved! (or ask your employer to officially allocate you this 15
minutes/day as a way of them supporting QGIS!)

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer