Jeremy, What about in the scenario where the submitter does everything and we (the committers) are slow? I’m not saying we shouldn’t try to fix all the problems, just that I see a lot more of the latter happening.
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Sep 15, 2018, at 08:51, Pierre Villard <[email protected]> wrote: > > 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 <[email protected]> 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 >> [email protected] >> [email protected] >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >>> On Sep 15, 2018, at 08:33, Pierre Villard <[email protected]> >> 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 >>
