[Python-ideas] Meta: Email netiquette

[Nick Coghlan]

On 15 June 2015 at 12:17, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> I'm under 25! It's not *annoying interfaces*; everything has some annoying interface aspect. That's very subjective. Personally, I prefer email to IM.
>
> Remember, you're referring to the nerdy youth, not the normal ones. :)

Folks, before we continue further down the rabbit hole, please take
into account that Anatoly has already been banned from bugs.python.org
and the core-mentorship mailing list for being demonstrably unable to
adjust his own behaviour to appropriately account for the needs and
interests of other members of the Python community, especially the
CPython core development team. (Some additional background on the
latter: https://mail.python.org/pipermail//python-committers/2012-December/002289.html
)

This isn't a case of "poor communication practices from someone that
doesn't yet understand our expectations of appropriate behaviour when
it comes to considering the needs and perspectives of others", it's
"poor communication practices from someone that actively refuses to
meet our standards of expected behaviour despite years of collective
coaching from a range of core developers".

Making a request to the respective list moderators for Anatoly's ban
to be extended to also cover python-dev and python-ideas as the main
core development lists (as has clearly become necessary) has been
approved by the Python Software Foundation Board, but actually putting
that request into effect is unfortunately a somewhat complicated
distributed task with Mailman 2 so it's still a work in progress at
this point in time. (It's my understanding that Mailman 3 improves the
tooling made available to list moderators, but the migration of the
python.org mailing lists from Mailman 2 to Mailman 3 is going to be a
time consuming infrastructure maintenance task in and of itself)

Regards,
Nick.

P.S. Pondering the broader question of managing counterproductive
attempts at contributing to a community, my view on the key reason
that Anatoly's ongoing attempts to "help" the core development team
have proven to be a particularly challenging situation to address
relates to the fact that there are two key aspects to effecting change
in a community or organisation:

* vocally criticising it from the outside (allowing the existing
community leaders to decide whether or not they agree with the
concerns raised, and subsequently come up with their preferred
approach to addressing them)
* working to change it from the inside (often by gaining personal
credibility through contribution in non-controversial areas before
pushing for potentially controversial changes in other areas of
interest)

Making significant structural changes to a community or organisation
usually requires a combination of both activities, as influential
insiders echo and amplify the voices of critical outsiders that they
have come to agree with, as former insiders leave and adopt the role
of critical outsider, and as formerly critical outsiders are brought
into the fold as new insiders to help address the problems they noted.

Refusing to listen to criticism at all is a recipe for stagnation and
decline, so folks are understandably wary of shutting out critical
voices in the general case.

However, these "critical outsider" and "influential insider" roles in
advocating for structural change are also largely mutually exclusive -
for an outsider, "how could we make such a change in practice?" isn't
their problem, while for insiders, agreeing with a diagnosis of a
problem or concern is only the first step, as actually addressing the
concern is then a complex exercise in determining where the time and
energy to address the issue is going to come from, and how the
particular concern stacks up against all the other problems and
challenges that need to be addressed. Expanding the available pool of
contributor time and energy doesn't necessarily eliminate the latter
requirement for collaborative prioritisation, as collective ambition
often grows right along with the size of the contributor base.

It *is* possible for skilled communicators to pursue both roles at the
same time (which can be an amazingly effective approach when handled
well), but it's a difficult task that requires context-dependent
moderation of their own behaviour, such that when they're using
community specific communication channels, they operate primarily in
"influential insider" mode, and largely reserve "critical outsider"
mode for raising their concerns on their own platforms (e.g. a
personal blog). More commonly, folks will choose one approach or the
other based on their current level of engagement with the community
concerned.

By contrast, someone using community specific communication channels
while persisting in operating in "critical outsider" mode counts as
deliberately disruptive behaviour, as it involves privileging our own
personal view of what we think the group's collective priorities
*should* be and *forcing* a discussion on those topics, rather than
gracefully accepting that there's almost always going to be a gap
between our personal priorities and the collective priorities of the
communities we choose to participate in, so we need to adjust our
expectations accordingly.

The combination of "insists on being directly involved in a particular
community" and "refuses to address feedback they receive on the
inappropriateness of their behaviour in that community" is fortunately
rare - most folks will either move on voluntarily once it is made
clear that their priorities and the group's priorities aren't aligned,
or else they will adjust their behaviour to be in line with community
norms whilst participating in that community.

For veterans of entirely unmoderated Usenet newsgroups, the historical
answer to the problematic "doesn't leave voluntarily when it is made
clear that their behaviour is not welcome" pattern has been to adopt
personal filters that automatically delete messages from particularly
unhelpful group participants. One of the realisations that has come
with the growth of online community management as a field of expertise
is that this individual filtering based approach is hostile to new
participants - newcomers don't know who to avoid yet, so they attempt
to engage productively with folks that aren't actually interested in
collaborative discussion (whether they know it or not). In the absence
of enforced bans, experienced group participants then face a choice
between appearing generally hostile (if they warn the newcomers away
from the participants known to regularly exhibit toxic behaviour), or
generally uncaring (if they leave the newcomers to their own devices).

Commercially backed open source communities have actually lead the way
in addressing this, as they're generally far more comfortable with
asserting their authority to ban folks in the interests of fostering a
more effective collaborative environment, and critical voices like
Model View Culture [1] have also had a major part to play in pointing
out the problems resulting from the historical approach of leaving
folks to find their own means of coping with toxic behaviour.

Continuing this meta-discussion here would be taking us even further
off-topic for python-ideas, though, so if anyone would like to
continue, I would suggest the comment thread on
http://www.curiousefficiency.org/posts/2015/01/abuse-is-not-ok.html as
a possible venue.

[1] https://modelviewculture.com/pieces/leaving-toxic-open-source-communities

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