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

[Petr Štetiar]

Adrian Schmutzler <mail at adrianschmutzler.de> [2019-10-28 13:17:34]:

Hi,

> 1. Those where the submitter left track after (initial) feedback
> I would even choose a relatively short time span for that (e.g. one month).

so this probably means PRs with `needs changes` tag and defined inactivity,
right?

> 2. Those where there never was any feedback
> However, I do not think it's fair to just close an old submission without
> any developer (or others people's) feedback (category 2), just because
> nobody is interested in it.

And whats the point to keep them lingering on the GH forever? My feeling is,
that people are simply afraid to reject the PRs so they simply ignore them,
but in the end, net result is the same.

> I'd see this differently if the old submissions would do any harm, but since
> they are just lying around and making a list a little longer, it's not like
> they pose a big problem.

If we're talking about following GH PR filter:

 is:pr is:open comments:0 updated:<2019-04-28 sort:created-asc 

Then it yields following result:

 kernel: add kmod-frame-vector                   https://github.com/openwrt/openwrt/pull/1518
 kernel: build kmod-dma-buf properly if required https://github.com/openwrt/openwrt/pull/1519

Both PRs from the same author, almost 1 year old. I believe, that if some bot
would autoclose those (or at least marked those with `stale` label which would
mean autoclose in next 30 days without any activity) it might signal the
author, that there probably is more effort needed to make it merged.

> one could provide a standardized
> feedback that 1. patches do not apply anymore, 
> This will remove inapplicable patches from the list, 

this could (and should) be automated and it's not an issue I would say.

> 2. it seems to be that interest in the subject isn't there

what could be more explicit then no activity for > 6 months?

>  and 3. that resubmission of a rebased patch is possible if the author wants
>  that

indeed, but rebased patch (and additional work attached to that) wouldn't
necessarily mean, that it wouldn't linger in the patchwork for the following
year, until next pre-christmas cleanup.

> but reach out for those having invested time in an enhancement to OpenWrt

To me it seems, that it might make more sense to take a look around for
inspiration, how it's being handled in other FOSS projects and try to improve
current workflow.

This PW/GH/FS fragmentation still makes me crazy, but anyway just a quick
ideas for PW/GH, we could handle the aging of the contributions more gradualy,
like in more phases:

 1. change patch status from 'New' to 'Needs Review / ACK' after 30 days of
    inactivity

    - on GH label=`needs reviewer` 

 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`

 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

 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

This way (backed up with some details on wiki page) it should hopefully make
more sense to the contributors.

-- ynezz

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