Andy, Totally get your points. I imagine that introducing this approach would help keeping dynamic exchanges on pull requests.
In case a PR needs complex/time consuming work (or in case the author is just not in a position to process comments), I think we could have two approaches: - the PR is considered stale after 60 days but is actually closed one week later. I think it leaves time for someone (ideally the author) to comment and give an update so that the PR is not considered stale anymore, no? - for important PRs, it's possible to "remove" this mechanism using specific labels but I guess we would have to ask ASF infra if we want to have rights to add labels on PRs (?) Pierre Le sam. 15 sept. 2018 à 17:44, Andy LoPresto <alopresto.apa...@gmail.com> a écrit : > Pierre, > > I’m going to delay my response on that proposal while I ask for (aka > should gather on my own) some information. Is that really our problem? By > that, I mean are stale PRs where we are getting bogged down? I am sure > there are some old ones that should be closed out. My larger concern is > that even new PRs don’t get reviewed immediately for a number of reasons. > > 1. Balance of committers to submissions. As the project continues to grow, > we have far more people providing code than can review it. > 2. Quality of PR. Not that the code is necessarily bad, but the PR doesn’t > clearly explain the problem and how they are solving it, provide test > cases, provide templates or a Docker container if interacting with an > external service, etc. All of these things add up to make the cost of > reviewing higher. > 3. What PRs cover. Previously, there was still a lot of low-hanging fruit, > and less complexity. While the project is still fairly cleanly organized, > many PRs now are less “add this simple functionality” and more “improve > this complicated feature.” > > I guess I would not have a problem with your proposal, but I do wonder if > there are more effective ways to reduce the backlog by identifying other > areas of improvement. > > Andy LoPresto > alopre...@apache.org > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Sep 15, 2018, at 08:33, Pierre Villard <pierre.villard...@gmail.com> > wrote: > > > > Hi, > > > > The number of open PRs is still growing and it could make think people > that > > the project is not healthy/active (even though a quick look at the last > > commit date or the commits rate is a clear indication that the project is > > healthy). > > > > In order to encourage people to review code and keep active discussions > on > > the PRs, I suggest to find a way to keep this number as small as > possible. > > To do so, I'd like to ask the wider community if the approach taken by a > > project like Apache Beam would be a good idea: > > > > "A pull request becomes stale after its author fails to respond to > > actionable comments for 60 days. Author of a closed pull request is > welcome > > to reopen the same pull request again in the future." > > > > This approach is managed by a file [1] in the .github directory of the > > repository. > > > > What do you think about this approach? > > > > [1] https://github.com/apache/beam/blob/master/.github/stale.yml > > > > Pierre >
