Thanks for bringing this up David. I'm in favor of some automatic ways to clean up stale PRs. More specifically:
* I think there are indeed many root causes why we have so many stale PRs that we should consider, and admittedly the reviewing manpower cannot keep up with the contributing pace is a big one of them. But in this discussion I'd personally like to keep this out of the scope and maybe keep it as a separate discussion (I think we are having some discussions on some of these root causes in parallel at the moment). * As for just how to handle the existing stale PRs, I think having an automatic way would be possibly the most effective manner, as I suspect how maintainable it would be to do that manually. The question though would be: do we just automatically close those PRs silently or should we also send notifications along with it. It seems https://github.com/actions/stale can definitely do the first, but not sure if it could the second? Plus let's say if we want notifications and it's doable via Action, could we configure just the committers list (as sending notifications to all community subscribers may be too spammy)? Personally I feel setting 6 months for closing and notifying committers on a per-week basis seems sufficient. Guozhang On Sun, Feb 6, 2022 at 9:58 AM Matthias J. Sax <mj...@apache.org> wrote: > I am +1 to close stale PRs -- not sure to what extend we want to > automate it, or just leave it up to the committers to do the cleanup > manually. I am happy both ways. > > However, I also want to point out, that one reason why we have so many > stale PRs is the committer overload to actually review PRs. It's a pity > that committer cannot keep up with the load (guilty as charged myself). > Not sure if it would help if more contributors could help doing reviews, > such that PRs are "pre-reviewed" and already in good shape before a > committer reviews it? > > > > > For KIPs, there is actually two more categories: > > - "Dormant/Inactive" > - "Discarded: > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals#KafkaImprovementProposals-DiscardedKIPs > > For Kafka Streams in particular, we also try to make the status of KIP > clear in the corresponding sub-page: > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams > > I might be useful thought to just do a better job to update KIP status > more frequently -- we could also re-organize the main KIP wiki page -- I > think it contains too much information and is hard to read. > > For the Kafka Streams sub-page, we use it for all "active" KIPs, while > we maintain a second page for adopted KIPs grouped by release: > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+KIP+Overview > > I find this much more digestible compared to the main KIP page. > > Might also be good to have a sub-page for Connect KIPs? > > > -Matthias > > > On 2/5/22 05:57, Luke Chen wrote: > > Hi Nikolay, > > > > That's a good question! > > But I think for stale KIP, we should have another discussion thread. > > > > In my opinion, I agree we should also have similar mechanism for KIP. > > Currently, the state of KIP has "under discussion", "voting", and > > "accepted". > > The KIP might stay in "discussion" or "voting" state forever. > > We might be able to have a new state called "close" for KIP. > > And we can review those inactive KIPs for a long time like PR did, to see > > if these KIPs need to close or re-start the discussion again. > > > > Thank you. > > Luke > > > > On Sat, Feb 5, 2022 at 9:23 PM Nikolay Izhikov <nizhi...@apache.org> > wrote: > > > >> Hello, David, Luke. > >> > >> What about KIPs? > >> Should we have some special state on KIPs that was rejected or can’t be > >> implemented due to lack of design or when Kafka goes in another > direction? > >> Right now those kind of KIPs just have no feedback. > >> For me as a contributor it’s not clear - what is wrong with the KIP. > >> > >> Is it wrong? Is there are no contributor to do the implementation? > >> > >>> 5 февр. 2022 г., в 15:49, Luke Chen <show...@gmail.com> написал(а): > >>> > >>> Hi David, > >>> > >>> I agree with it! This is also a good way to let both parties (code > author > >>> and reviewers) know there's a PR is not active anymore. Should we > >> continue > >>> it or close it directly? > >>> > >>> In my opinion, 1 year is too long, half a year should be long enough. > >>> > >>> Thank you. > >>> Luke > >>> > >>> On Sat, Feb 5, 2022 at 8:17 PM Sagar <sagarmeansoc...@gmail.com> > wrote: > >>> > >>>> Hey David, > >>>> > >>>> That's a great idea.. Just to stress your point, this keeps both > parties > >>>> informed if a PR has become stale. So, the reviewer would know that > >> there > >>>> was some PR which was being reviewed but due to inactivity it got > >> closed so > >>>> maybe time to relook and similarly the submitter. > >>>> > >>>> And yeah, any stale/unused PRs can be closed straight away thereby > >> reducing > >>>> the load on reviewers. I have done some work on kubernetes open source > >> and > >>>> they follow a similar paradigm which is useful. > >>>> > >>>> Thanks! > >>>> Sagar. > >>>> > >> > >> > > > -- -- Guozhang
