Re: [Twisted-Python] overview: new review queue venue

2016-05-23 Thread Glyph
> On May 23, 2016, at 11:56 AM, Clayton Daley wrote: > > Closing PRs will make them less likely to be found by searchers. If every PR > has an issue (common for bug fixes, less common for new features), this is > less of a problem -- is this something the bot would need to verify/fix? The bo

Re: [Twisted-Python] overview: new review queue venue

2016-05-23 Thread Clayton Daley
> > I mostly frequent Physics Stack Exchange > . At any time some number of the > questions on the front page are either "closed" or "on hold" for not living > up to site standards in some way. We've asked almost exactly the same > question as is being asked in th

Re: [Twisted-Python] overview: new review queue venue

2016-05-23 Thread Daniel Sank
FWIW I thought of another "open source" community which uses a similar idea to closing pull requests if they won't be accepted in their current form: Stack Exchange. I mostly frequent Physics Stack Exchange . At any time some number of the questions on the front

Re: [Twisted-Python] overview: new review queue venue

2016-05-23 Thread Glyph
> On May 22, 2016, at 10:51 PM, Tristan Seligmann > wrote: > > Note that even without the bot, I believe you can just create a new PR for > the same branch, so it's not *too* bad, but definitely a little clunky. Many of my comments have had to do why we want this kind of process generally, r

Re: [Twisted-Python] overview: new review queue venue

2016-05-23 Thread Glyph
> On May 22, 2016, at 9:39 PM, meejah wrote: > > > Personally, I find closing PRs that aren't going to be merged "soon" > mostly-beneficial. Even if it *might* be perceived as "hostile" by some > contributers, a simple explanation should suffice. (And, if simply > closing a PR with a nice note

Re: [Twisted-Python] overview: new review queue venue

2016-05-23 Thread Glyph
> On May 22, 2016, at 18:12, Clayton Daley > wexternalote: > > "You can't: > require test coverage, > require documentation, > require coding standard compliance, > require people to file a ticket before sending a patch to the mailing list, > The first three of these are *already* norms in all