[Python-Dev] Discussion overload

[Kevin Ollivier]

Hi Nick,



On 6/17/16, 6:12 PM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

>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.

Yeah, the sad truth is that when you start having these problems, it's the good people that leave. The key though is not to treat this as some unsolvable problem, which honestly is what I've seen many projects do. :( My guess is that once these issues are addressed, at least some of the people who left would be willing to give it another try. 

I had written a couple paragraphs about some different tools and approaches that might help with that, but I think Guido's got the right idea by taking it off-list to determine the best way to move forward first.

Regards,

Kevin


>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