[Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

[Robert Collins]

On 21 July 2015 at 00:34, Ben Finney <ben+python at benfinney.id.au> wrote:
> 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.

Depending on what you mean by justification , this leaves no leeway
for hunches, feelings, intuition, or grey area changes.

It's also a terrible way to treat people that are contributing their
own time and effort: assume good faith is a much better starting
point.

I think its reasonable to say that any change should be open to post
hoc discussion. Thats how we learn, but justification and challenging
is an adversarial framing, and one I'm flatly uninterested in. Life is
too short to volunteer on adversarial activies.

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

I don't understand why thats healthy or useful.

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

I don't think that contributors are a problem here. But, I'm going to
dig into that more in reply to Nick.

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

As a case study, this discussion where something like 90% of the
kibbitzing demonstrated a clear lack of understanding of the very
behaviour of Mock, *and* the change in question was discussed, *prior*
to it being done, *and* users have welcomed it....I must conclude that
either:
 - this discussion was the exception to prove your general rule (but
why would we derive that general rule from this discussion)
 - the general rule isn't general.

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

What's the goal here: what actual problem are we trying to solve for?

More contributors? A better Python more people can use? Keeping up
with the contributions we've already received but not actioned? [...]

Like: pick one thing. What we /really/ want to achieve, then lets look
at what will let us get there.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud