[Overload-sig] Experimenting on real-world groups with potential solutions

[Kevin Ollivier]

Hi Stephen,



On 6/24/16, 11:05 AM, "Overload-sig on behalf of Stephen J. Turnbull" <overload-sig-bounces+kevin-lists=theolliviers.com at python.org on behalf of stephen at xemacs.org> wrote:

>Donald Stufft writes:
>
> > * Topic based workflow that includes built in support for moderation.
> >     * Close a topic to new replies when it’s obvious that
> >       discussion is not productive.
>
>That would not have worked in the security discussion.  There was
>still work for Guido and mostly Larry to do even after pronouncement,
>and there were useful comments from third parties.  Yes, they could
>have moved to private email, but doing that would have made the
>security advocates even less happy.
>
>In general I don't think python-{dev,ideas} has a problem with
>unproductive threads.  It has a problem with unproductive posts, and
>(rarely) unproductive posters.

Actually, I have yet to be convinced that there was anything regarding os.urandom that needed discussing at all. The whole discussing revolved around a hypothetical use case that, as far as I am aware, is both pretty unlikely to happen and has never actually even been reported.

I think this is actually a good example of how going straight to the issue tracker would have led to a much different outcome. Imagine the ticket created:

Title: Python script calling os.urandom on hardware init may block
Affects: embedded / rPI (Others?)
Priority: Low (if it was marked high I'm pretty certain a review of it would get it marked down)
Attachment: None (no actual use / test case that I saw)
Assigned To: (would someone take ownership?)
Blocks: None
Watching: <probably almost no one>

Already we can see that this would not be put at the top of the ticket list. If it was investigated at all, someone probably would have asked for a test case so we can know the specific nature of the problem we're trying to fix. Probably would have been pretty quiet after that. It may eventually have gotten marked Won't Fix.

A lot of people talk about filtering in mailing lists, but the only piece of information you have when skimming mailing list discussions is the title. How serious the issue is, how many people it affects, what the impact of doing something vs not doing something would be, those are all only discernible by reading the thread. Once a few people have jumped in, many if not all those factors may even be in dispute. Issue trackers let you easily see context and priority at a glance, this is all missing from mailing lists and there's no easy way to add it. 

I think Guido is exactly right that switching to better tools would have a significant impact on the project. Of course, the only way to find out is by trying. Doing > discussing, the brain is actually hard wired to learn from doing, so that gives you the best bang for the buck. So I personally am eager to just try some things. :)

Thanks,

Kevin