[Python-ideas] Civility on this mailing list

[Paul Moore]

On 21 October 2016 at 15:26, Nick Coghlan <ncoghlan at gmail.com> wrote:
> - Remember that even if something we vehemently consider "wrong" makes
> it into the reference implementation, the language does have a design
> policy that allows us to correct design mistakes after a suitable
> deprecation period, and we also each personally have the option of
> advocating for updates to the coding styles on the projects we
> participate in to prohibit use of the features we consider problematic

This one, I think is particularly relevant to long-time participants
(I know it applies to me). It's very easy to become strongly defensive
out of fear that a chorus of enthusiasm will push something through
that you disagree with. It's worth people (me!) remembering that
there's a large "silent majority" of people who don't participate on
python-ideas, but who have a strong influence on whether proposals get
accepted. Also, the tracker and the PEP process do a great job of
sanity checking proposals. So there's no need for people to feel like
they have to be the lone defender of the language against wild
proposals.

> The reason it's useful to have a
> brainstorming list where folks may be told "That's a bad idea for
> Python", but should never be told "You shouldn't have suggested that",
> is that sometimes someone will challenge a longstanding assumption
> that isn't actually true anymore, or an accident of implementation
> that imposes an unnecessary stumbling block for new users. In those
> cases, the net future benefit to the overall ecosystem may be judged
> significant enough to be worth the costs of adjusting to it.

I wonder. Would there be value in adding a sign-up email to the list
(supported by a posting of that email to the list, to catch existing
contributors) that set out some of the basic principles of how changes
are judged for inclusion in Python? We could cover things like:

* The fact that the default answer is typically "no", along with an
overview of the reasons *why* the status quo wins by default.
* Some of the simple "rules of thumb" like "not every 2-line function
should be a builtin.
* Basic reminders that Python is used by a very diverse set of users,
and proposals that are only beneficial for a limited group need to be
weighed against the disruption to the majority who get no benefit.
* The above comment, that we welcome ideas because it's important that
we don't stagnate and having assumptions challenged is valuable, even
if the bar for getting such ideas accepted is (necessarily) high.

Maybe even make it a regular informational posting, if it seems that a
reminder would be useful.

It's possible that this would come across as too bureaucratic for new
users, though, so I'm not sure...

Paul