[Python-Dev] project culture: take responsibility for your commits

[Stephen J. Turnbull]

Stefan Behnel writes:

 > Hi, I'm looking back on a rather unpleasant experience that I
 > recently had in this developer community. Actually, twice by
 > now. Here's what I take from it: You should take responsibility for
 > your commits.

I have no clue who you're addressing this advice to.  If it's not
yourself (from the following, I gather it's not), I think the
implication of what you are saying is mistaken.  Core devs (by which I
mean the high-profile developers who are candidates for PEP delegate)
regularly do take responsibility for their commits, just like any
other committer, by changing or reverting them.  That's visible on
this list as well as in the commit logs.

 > Let's assume these complaints [about the code] are reasonable

That's not sufficient.  They must also be presented reasonably, by the
standards of the community.  Not everybody is good at doing that, and
those who aren't suffer, as does the project for losing a useful
contribution.  Unfortunate, but digging out what matters from unclear
or high-handed presentations requires an enormous amount of effort,
like pyschotherapy.  Good psychotherapists bill hundreds of dollars an
hour.  The very best "pythotherapists" bill nothing, at least not to
this community.

Regarding the specific core dev behavior that offended you, I can
speak from my experience in another project.

 > What do you do in that case? Do you tell them that what's in is in?

I've done that and later reversed my position.  In retrospect, I
believe I was correct at the time of first approach in the majority of
cases, though, on the grounds of the "lesser of two evils" as I
understood the issues (or occasionally that the contributor had
completely misunderstood the issues).

In most cases the original requester never did come up with a coherent
argument, just that something unclear to me didn't work for them.
Reversal in such cases was due to a third party who was able to
explain the requester's requirements, and often contribute (most of) a
specification of a complete fix or a good compromise.

 > Do you tell them that you are a core developer and they are not?

I've done that.  I don't know if it applies to the cases you have in
mind, but invariably that was a last retort when I just wanted to shut
down a conversation that had already come back to the same place
twice, and polite guidance seemed to be a complete failure.  Childish,
I guess, but it's been effective.  That's not sufficient reason to use
it in Python, which has higher standards for courtesy than my other
project does.

Caveat: as with the next item, I have to wonder if you mistook an
explanation that

    in such disputes, the Python default is to go with the core dev's
    gut feeling unless there's good reason to do otherwise, and you
    haven't explained well enough yet

for a snotty "I am and you're not, so go away!"

 > That they can try to do better, and if they are lucky, find someone
 > else who applies their patch?

Definitely, and I would advise any core developer to use exactly that
response as soon as they feel the discussion is becoming unprofitable.
Of course they should spin it differently, something like

    Well, I don't agree that reverting my patch is necessary, and
    something needs to be done to address the issue it handles.
    You are welcome to propose your own patch, but I suggest you
    seek out an alternative reviewer as it's hard for me to be
    objective about my own code once I'm convinced it's correct.

Are you *sure* that your phrasing above is what the reviewers wrote,
and not merely what you took from their writing?  "Insult is far more
frequently taken than given."

In sum, I don't see what you're complaining about.  Sure, you may have
been mistreated in the case(s) in question, which sucks, of course.
If so, you should provide details, and maybe the particular kind of
case would be a lesson to all of us.  Or perhaps some core devs
systematically abuse their positions (but as Brett says you should be
very careful about making that statement in public!)  But I don't see
evidence that there's a systematic failure to review "core dev"
commits, or that "core devs" deny their own fallibility.  Nor do I
think any of the behaviors you describe *out of context* are always
wrong (except "I'm a core dev and you're not" should be avoided even
if effective; it's rude and ad hominem).