[Python-Dev] Discussion overload

[Nick Coghlan]

On 16 June 2016 at 19:00, Kevin Ollivier <kevin-lists at theolliviers.com> wrote:
> Hi Guido,
>
> From: <gvanrossum at gmail.com> on behalf of Guido van Rossum
> <guido at python.org>
> Reply-To: <guido at python.org>
> Date: Thursday, June 16, 2016 at 5:27 PM
> To: Kevin Ollivier <kevin-lists at theolliviers.com>
> Cc: Python Dev <python-dev at python.org>
> Subject: Re: [Python-Dev] Discussion overload
>
> Hi Kevin,
>
> I often feel the same way. Are you using GMail? It combines related messages
> in threads and lets you mute threads. I often use this feature so I can
> manage my inbox. (I presume other mailers have the same features, but I
> don't know if all of them do.) There are also many people who read the list
> on a website, e.g. gmane. (Though I think that sometimes the delays incurred
> there add to the noise -- e.g. when a decision is reached on the list
> sometimes people keep responding to earlier threads.)
>
>
> I fear I did quite a poor job of making my point. :( I've been on open
> source mailing lists since the late 90s, so I've learned strategies for
> dealing with mailing list overload. I've got my mail folders, my mail rules,
> etc. Having been on many mailing lists over the years, I've seen many
> productive discussions and many unproductive ones, and over time you start
> to see patterns. You also see what happens to those communities over time.

This is one of the major reasons we have the option of escalating
things to the PEP process (and that's currently in train for
os.urandom), as well as the SIGs for when folks really need to dig
into topics that risk incurring a relatively low signal-to-noise
ration on python-dev. It's also why python-ideas was turned into a
separate list, since folks without the time for more speculative
discussions and brainstorming can safely ignore it, while remaining
confident that any ideas considered interesting enough for further
review will be brought to python-dev's attention.

But yes, one of the more significant design errors I've made with the
contextlib API was due to just such a draining pile-on by folks that
weren't happy the original name wasn't a 100% accurate description of
the underlying mechanics (even though it was an accurate description
of the intended use case), and "people yelling at you on project
communication channels without doing adequate research first" is the
number one reason we see otherwise happily engaged core developers
decide to find something else to do with their time.

The challenge and art in community management in that context is
balancing telling both old and new list participants "It's OK to ask
'Why is this so?', as sometimes the answer is that there isn't a good
reason and we may want to change it" and "Learn to be a good peer
manager, and avoid behaving like a micro-managing autocrat that chases
away experienced contributors".

Cheers,
Nick.

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