[OpenWrt-Devel] improved handling of contributions [Was: Re: patches from 2018]

[Petr Štetiar]

Adrian Schmutzler <mail at adrianschmutzler.de> [2019-10-29 13:25:27]:

Hi,

> the main difference is just that I prefer some manual interference, where
> you are looking for more automation:

1. DRY
2. Avoiding manual mistakes (and introduce automated ones)
3. Time spent on the tasks which could be automated could be used in other
   parts of the project

> (situation might be answered differently for bug reports).

That's exactly my point 3. above. If you wouldn't need to spend your precious
time on the repeating tasks which could be automated, then you could for
example help with bug reports, code, CI, forums, wiki or whatever part you
enjoy doing the most.

> (Despite, with PRs being autoclosed, I wouldn't be surprised if we get lots
> of duplicate PRs instead of old ones reopened, which would also increase
> maintenance efforts.)

We can take a look at this if/when this happens. I think, that actually
opening new PR (or resending patches) is desired as its more likely to bring
the necessary attention.

> >  2. change patch status from 'Needs Review / ACK' to 'Under Review' and
> >  assign it randomly (to predefined set of volunteer commiters) after 60
> >  days of inactivity
> > 
> >     - on GH label=`awaiting review`
> 
> In principle, yes. However, the volunteers will need to deal with anything
> that comes on the desk.

You can always ping someone on IRC/GH and ask for another pair of eyes.

> I'd personally make that dependant on whether there are volunteers or not.

I'm 100% sure, that there are, otherwise I wouldn't propose that.

> >  3. change patch status from 'Under Review' to 'Needs Review / ACK' after 90 days
> >     of inactivity
> > 
> >     - on GH label=`stale` and remove the randomly assigned reviewer
> 
> That's the same as after 30 days? (Chosen because there is no "stale" equivalent on PW?)

Yes, exactly.

> >  4. change patch status from 'Needs Review / ACK' to 'Rejected' after 120 days
> >     of inactivity, sending out some meaningful mail with a link to
> >     exaplanation of the currently failed merging process on the wiki
> > 
> >     - on GH close the PR
> 
> As introduced earlier, I would require to do this manually, so at least
> someone has to have a brief look at the thing. 

It's already handled in 3. and if even volunteer is not interested even to
ping someone on IRC or GitHub to take over that PR, then simply there is no
interest and you can't do much about it.

You can always merge/reject it by yourself during those ~90 days, right? :-)
The automation is just a last resort to make something happen in short time
span, avoiding us to talk in 2020 about contributions from 2018...

> Despite, if one automates, one of the crucial points will be how to measure "activity".

That's just implementation "detail". PW, Git{Lab,Hub} offer nice APIs, so I
believe, that there's always some way.

> And how to deal with bug reports? In contrast to feature requests, a bug
> report cannot just be closed because nobody is interested in addressing it?

And why not?

After Y days of inactivity, we could update the issue with something like following:

 "It seems like the issue is stale, please consider reading
  https://openwrt.org/bugs again and adjust your bug report accrodingly.

  Consider reproducing this bug on latest https://openwrt.org/releases/snapshot 
  in order to increase your chances... No activity in the next 14 days will make
  this bug report closed with 'No response' reason."

And then close it 2 weeks later. I mean, I'm sometimes doing the same
manually, closing the old issue straight away with "ask for reopen if you can
reproduce it on latest snapshot".

-- ynezz

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel