On 21 July 2015 at 00:34, Ben Finney email@example.com wrote:
Paul Moore firstname.lastname@example.org 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:
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.
-- Robert Collins email@example.com Distinguished Technologist HP Converged Cloud