I'm for cleaning up the outstanding inactive PR's and putting this in the dev guidelines. I would actually like to push for a time that is less than 6 weeks. Why not 4? We don't risk much - a submitter can always reopen a closed PR, and the history is maintained. Closed PR's don't disappear afaik - they remain in perpetuity.
M On Fri, Apr 13, 2018 at 1:41 PM, Otto Fowler <ottobackwa...@gmail.com> wrote: > I would make sure that each clause is consistent with the distinction. > Contributor is def. better. > > > On April 13, 2018 at 15:27:39, Nick Allen (n...@nickallen.org) wrote: > > Yes, that is a good edit Otto. If I formally submit this as a change to > dev guidelines, I will use your edit. > > One small thing, instead of "submitter", I'll stick with "contributor" > because I use that everywhere else. > > A pull request is 'inactive' if no comments or updates have been made by > the contributor in the previous 6 weeks. > > > > On Fri, Apr 13, 2018 at 3:06 PM, Otto Fowler <ottobackwa...@gmail.com> > wrote: > > > I would be more explicit that the inactivity was the inactivity of the > > submitter. > > It should be clear that this is not for PRs that have not been reviewed, > > or PRs where the submitter has asked a question > > or answered a question and the reviewers have abandoned the effort. Not > > that that ever happens. > > > > “A pull request where a review has been initiated will be considered > > inactive if it is waiting on > > reply or action on the part of the submitter and has had no activity by > > that submitter in the previous six weeks” > > > > etc etc > > > > > > > > A pull request is 'inactive' if no comments or updates have been made by > > the submitter > > in the previous 6 weeks > > > > > > On April 13, 2018 at 14:44:40, Nick Allen (n...@nickallen.org) wrote: > > > > 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 > > > > >
