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

[Stefan Behnel]

Stephen,

thank you for your very thoughtful answer.

Stephen J. Turnbull, 03.10.2013 04:23:
> 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.

I'm aware of that, and I apologise to those who felt offended by my post. I
really didn't mean for it to read that way, but I can see in retrospect
that my phrasing and its implications were bound to be read as offence,
both personally and to the audience.


>  > 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.

I'm also aware of that. In one of the OSS projects that I lead, bad bug
reports are actually quite frequent due to a broad distribution of user
experience (simplicity has its drawbacks, it seems). It can sometimes take
way more time than I'd have wanted to invest to decipher them and/or ask
back until it's clearer.


> 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.

Here, you are mostly saying that it's ok to say that for illegitimate and
unclear complaints. Even in that case, I'd personally be very careful with
that phrase. But I guess that seconds Brett's remarks on subjectivity.


>  > 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.

I also agree here. Personally, I can't recall a situation where I ever said
that in my OSS projects (and I apologise to everyone I forget here ;)


> 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.

The problem is that these two can go hand in hand. As a non-committer, you
are always at the mercy of core developers, and it feels bad to be made
aware of it. If the situation (however it was phrased) is essentially "it's
committed, and now find someone else to listen", then reverting is no
longer really an option. It's very hard to convince one core developer to
revert a commit of another (and in fact, it should be).

So, basically, by simply turning away, you are forcing the bagger into
fixing it themselves, i.e. into writing the patch, into "cleaning up the
mess you left", not even knowing if there will ever be someone else to then
apply it. That's a very awkward situation for them. Not uncommonly, writing
that patch is way more work than the original core developer invested into
his/her change, both because the non-committer is likely to have less
experience with that specific code, and because the core developer (being a
good developer) most likely took the lazy path already, so you are left
with the less lazy and more involved options.

I find that it helps me (personally) as a core developer to keep that heavy
unbalance in mind. That pretty much sums up my reasons for the post that
triggered this thread.


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

I agree with both points.


> 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).

I actually agree with your conclusions, and I renew my apologies to those
who felt offended.

Stefan