[Python-Dev] How far to go with user-friendliness

Ben Finney ben+python at benfinney.id.au
Mon Jul 20 14:34:29 CEST 2015


Paul Moore <p.f.moore at gmail.com> writes:

> Again, I'm sorry to pick on one sentence out of context, but it cut
> straight to my biggest fear when doing a commit (on any project) -
> what if, after all the worrying and consideration I put into doing
> this commit, people disagree with me (or worse still, I made a
> mistake)? Will I be able to justify what I decided?

That seems quite healthy to me. On a collaborative project with effects
far beyond oneself, yes, any change *should* be able to be justified
when challenged.

That isn't a mandate to challenge every change, of course. It does mean
that every change should be considered in light of “Can I justify
this, if challenged?”

So what you describe sounds like a healthy barrier: one which works to
keep out unjustifiable changes.

What is needed is to have both that *and* the support of the community
so it's not a barrier to the *contributors*. The contributors should not
feel excluded merely because some of their changes might need to be.

> Hmm, maybe I'd better hold off and let someone else make the
> decision...

What of the (obvious, to me) option to retain the authority to make the
decision, but take the doubt as a sign that one should consult with
others before making the decision?

That is, there's no need to feel that one shouldn't make the decision.
But perhaps one shouldn't make it solely on one's own experience or
insight. Get others involved, even non-committers, and discuss it, and
understand the issue better. With that improved basis, then make the
decision.

Am I naive to think that's desirable for PYthon core committers?

-- 
 \     “Ours is a world where people don't know what they want and are |
  `\       willing to go through hell to get it.” —Donald Robert Perry |
_o__)                                                          Marquis |
Ben Finney



More information about the Python-Dev mailing list