[Python-ideas] Civility on this mailing list

[Nick Coghlan]

On 19 October 2016 at 21:29, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
> +1.
>
> I read many disagreements, and people being rude and unprofessional on
> occasions, but nothing that would make me have a bad day, even when I was
> the target of it.
>
> I feel like people are really getting hyper sensitive about communications.

As Paul says, assuming good intent is highly desirable, but at the
same time, we need to fully appreciate as post authors that
python-ideas is a shared communications channel where hundreds of
other people are offering us their time and attention for the shared
purpose of attempting to ensure that future versions of Python offer
an even better programming environment for all kinds of programmers.

Respecting that means learning to somehow balance the interests of
kids taking their first steps into programming with MicroPython on the
micro:bit, adults picking up Python as a possible first step in
pursuing a career change, professional web service developers wringing
every last ounce of performance out of PyPy that they can, scientists
& analysts trying to make sense of their data sets in CPython, system
administrators and infrastructure engineers automating their daily
activities, etc, etc.

Sure, many of us are mainly here because we'd like to make future
versions of Python better for ourselves as individuals, but the sheer
scope of Python's existing adoption means we're all operating under
the basic constraint that even unambiguously positive changes impose
non-trivial costs on the rest of the ecosystem, as other
implementations need to be updated, books, course notes, and other
educational materials require changes, and every current Pythonista
gains a new thing to keep in mind where they're wondering which
features they can and can't rely on when targeting particular
versions. Even the consequences for future Pythonistas aren't
unambiguously good, as they'll not only gain a new capability that
they'll learn in newer versions, and then have to unlearn when
maintaining software written to also run on older versions, but will
also often receive confusing advice from folks that first learned an
earlier version of Python, and may not have kept up with all of the
changes in more recent versions.

This constraint is exacerbated by the fact that we're still in the
midst of the Python 3 migration, where many of our current users still
have software compatibility hurdles between them and their ability to
benefit from the work being done on the Python 3 series.

This all means that with "post your language design ideas for
collaborative critique" being an inherently conflict prone activity,
and with "No, that's not a good fit for Python" being such a common
answer, it takes a lot of collective effort for us to ensure that this
remains a primarily positive and rewarding experience both for folks
posting suggestions for change, and for folks reviewing and commenting
on those suggestions.

In practice, this mainly boils down to attempting to follow the guidelines:

- Don't make people regret posting their idea (however much we
personally dislike it)
- Be willing to graciously accept 'No' for an answer when posting a
suggestion for change
- Remember that fixing problems just for ourselves and folks that
choose to adopt our solution is a perfectly fine option - we don't
necessarily have to change the default characteristics of the entire
language ecosystem
- 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

Cheers,
Nick.

P.S. Given the existence of the constraints discussed above, folks may
then be curious as to why we have a brainstorming list at all, given
that the default answer is almost always going to be "No", with folks
being encouraged to instead find a way to use the existing flexibility
in the language and interpreter design to solve the problem to their
own satisfaction in a 3rd party module or even a language variant
(with MacroPy and Hylang being a couple of significant examples of
folks taking that path for ideas that would never be accepted into the
default implementation). 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.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia