[Overload-sig] Experimenting on real-world groups with potential solutions

[Stephen J. Turnbull]

Kevin Ollivier writes:

 > Well, we disagree here, I think most of it in fact can be
 > prevented.

But how?  You have made no argument except that "people don't 'need'
to do it, and so they shouldn't do it."  If you don't have a concrete
proposal that doesn't amount to "we should require people to have
better self-control", we're done here.  People are what they are;
requiring them to change is a recipe for failure and intense
frustration -- because they won't unless encouraged to by procedural
changes.

The only procedural suggestion so far ("provide a concrete case") is
already in place, and worked effectively, in the case of os.urandom.
As far as Python-Dev is concerned, there is no question of the
validity of the bug.  I can say that because it is being addressed in
3.6.  It's just that the RM and the PSRT had very different opinions
about the importance of the case presented, and the consequences of
different policies for dealing with it in 3.5.2.

I also see a big practical problem with what I understand you to be
suggesting in the case of the security brouhaha.  That is, it's the
PSRT members who are frustrated to the point of disengaging from the
community.  According to your analysis, we should impose an even
greater burden on exactly the folks who were most stressed by the
outcome.  Developer retention is an important goal of our work here,
so I think that's counterproductive.

Note that the opposite allocation of burden applies to the case of
inexperienced developers, who did not help develop the patch being
discussed, pontificating aggressively on issues they have (as yet)
only shallow understanding.  The core developers get frustrated, the
new folks find it addicting -- cooling the latter down is a good idea
all around.

Regards,
Steve