[Twisted-Python] overview: new review queue venue

[Clayton Daley]

>
> "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 of the OSS projects of
this caliber and the 4th doesn't make sense in a Github/Bitbucket/Gitlab
world (and I fortunately avoided its predecessors).  In fact, I'd be a
little worried if the first there weren't required in a project.
ResourceSpace is the only one I can think of that doesn't require them and
I wouldn't touch it with a 10 foot pole if there were acceptable (free)
alternatives.  So I don't see the link between your success enforcing three
norms of good OSS projects and your desire to break a 4th.

===

The idea that PRs are a substantial burden has caused me pause.  Normally,
a PR is a chance to give back to a project rather than freeload.  In most
projects, new features are part of a virtuous cycle:  a new feature tends
to benefit a large fraction of the user base and expand the user base...
which draws more contributors.

Especially given the recent deprecations (old, unmaintained protocols), it
seems that Twisted doesn't work like this.  If another user adds another
protocol, it doesn't make the system better for most users.  In fact, it
makes sense that it actually increases the maintenance burden.

I tried to look for myself, but was reminded that I don't know the
internals well enough... are patches on non-central protocols a big part of
the backlog?  Or is the backlog mostly core features (like reactors or IO
infrastructure) that most projects depend upon?

Clayton Daley

On Sun, May 22, 2016 at 4:22 PM, Glyph <glyph at twistedmatrix.com> wrote:

>
> 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
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20160522/69291b0e/attachment-0002.html>