Adrian Schmutzler <m...@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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
