There are a fair number of inactive PRs in our queue that have little to no
chance of being merged.  Tidying up our queue and keeping open only active
PRs should help the community better identify which PRs need reviewed and
actioned.

If the original contributor does not close the PR, the only course of
action that we can take is to open an Apache Infra request to close the
PR.  We have only ever done this after multiple failed attempts to contact
the original contributor.

I suggest that we add to the Metron development guidelines [1] exactly how
inactive PRs should be handled.

(Q1) Should we add to the development guidelines a process for handling
inactive PRs?



Assuming there is support for this, I would suggest the following as a
first draft.  These would serve as an addendum to section 2.6

2.6.1 Inactive Pull Requests


Contributions can often take a significant amount of time to complete the
code review process.  This process requires active participation from the
contributor.  If the contributor is unable to actively participate, the PR
is unlikely to successfully complete this process.  Pull Requests that have
failed to receive active participation for an extended period of time risk
being treated as abandoned.

 Any committer can submit a request  for Apache Infra to close a pull
request that has been abandoned according to the following guidelines.


   - A pull request is 'inactive' if no comments or updates have been made
   in the previous 6 weeks.


   - For any 'inactive' pull request, a committer can request from the
   contributor justification for keeping the pull request open.


   - In that request, the committer should refer the contributor to these
   development guidelines for inactive pull requests.


   - If the contributor does not respond to the request within 2 additional
   weeks, the committer should cast a -1 vote on the PR using these
   development guidelines as justification.


   - Any committer can then submit a request to Apache Infra to close the
   PR based on this -1 vote.


​(Q2) Assuming support for the idea, are these good guidelines?  ​I offer
this only to help drive the discussion. I am open to alternatives.



[1]
https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines

Reply via email to