[Twisted-Python] overview: new review queue venue

[Glyph]

> On May 22, 2016, at 6:18 AM, Clayton Daley <clayton.daley at gmail.com> wrote:
> 
> The thing is, if you perceive it as "hostile" that a project closes a PR - i.e. "says that they're not going to do more work on it" - that is a cultural problem; it suggests a certain implicit level of passive aggression in opening a PR which I don't want to assume.  It's sort of like having a culture where you can just send anybody an email asking them to do whatever and it would be "hostile" for them to refuse.  In such a culture people don't say "yes", but they do start to ignore messages  Closing the PR is a more accurate reflection of reality - the project (twisted) is not going to do anything about the PR in its current state, so it shouldn't be left open.  It also clearly demarcates the completion of a review.
> ... 
> I'd much rather our new contributors get a little confused about the culturally unusual step of closing a PR than to have their work be accidentally but systematically discriminated against in favor of people who know how to bug the right people in IRC or email.
> 
> It's your party, but I think this vastly undervalues first impressions in OSS engagement.  From all the projects I've contributed to on Github -- yes technically Github not Git though Bitbucket has equivalent features (and unlimited private repos for free!) -- closing means "this is off the table".  It's a nice clear signal that there's nothing the contributor can do to fix it -- e.g. I had an LSP-valid change that passed all tests run afoul of some obscure PHP method signature limitation when mixed with other packages.
>  
> I'll wager only the active contributors will remember the proposed subtlety a month from now.  As a big break from Github norms, It's going to hit everyone else at the worst time... a first PR submission.  That's the moment when a contributor is trying to get a sense of the culture of the team that manages the project.  They're at their most vulnerable and violating *their* norms significantly increases the odds that they'll leave the fix in a private fork and disengage.
> 
> Twisted operates at a different level so this may not be a bad thing.  You may benefit from actively discouraging dabblers -- especially given resource constraints.  But there aren't going to be a lot of "first PR" folks on this list to point out the effect of this break from norms.

This is roughly the same story I've been getting for the last decade and a half:

"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,

that's a terrible burden to put on new contributors!"

Somehow we've survived much longer than most projects, and while some would say "in spite of" these restrictions, I think it's "because of".  So, we are not trying to "discourage dabblers"; we would like new contributors who want to contribute only a little bit.  So while I don't want to throw up arbitrary barriers, if you aren't willing to invest the effort to even read a single comment on your PR explaining why it was closed and how to reopen it, I cannot imagine that chances are good that you'll read the rest of the comments explaining what changes need to be made and make them effectively.

Further, people who contribute trivial changes that can be immediately merged, like documentation typos, won't need to deal with this, because they won't see the intermediary "needs feedback" closed state; they'll just get their PRs accepted immediately.

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20160522/ffaf8b82/attachment-0002.html>