(Note that I would personally happily participate in the Discourse experiment -- I'm just asking whether this would appear like a fork to current python-ideas subscribers or more like some kind of alternate UI they can ignore -- the way I ignore GMane.) On Tue, Jun 21, 2016 at 11:44 AM, Guido van Rossum <guido@python.org> wrote:

Excuse my total ignorance -- what's the experience for users who don't interact through Discourse? Do they not see anything that's happening in Discourse, or does it have a gateway (like python-list vs. comp.lang.python, or the various GMane things)?

On Tue, Jun 21, 2016 at 11:38 AM, Brett Cannon <brett@python.org> wrote:

...

I'm willing to offer up python-ideas as an experimental group of people to try a new approach to communicating if we want to try something out on an existing mailing list that isn't as critical as python-dev. I also know that Donald has expressed interest in trying Discourse on distutils-sig as have I (I believe lack of time is what has prevented this experiment from occurring on Donald's side, definitely the reason I haven't tried Discourse on python-ideas).

_______________________________________________ Overload-sig mailing list Overload-sig@python.org https://mail.python.org/mailman/listinfo/overload-sig

-- --Guido van Rossum (python.org/~guido)

-- --Guido van Rossum (python.org/~guido)

I don’t believe there is a gmane gateway for discourse, but as Brett mentioned there is a “mailing list mode” that individual participants can select so that they never need to use the web interface. I’m told that it’s not as good as a dedicated mailing list software, but whether it’s good enough for actual day to day use I don’t know. One thing that we should consider if we attempt to try out discourse, is to keep an eye on collapsing all of the mailing lists to a single discourse instance and having a forum per what we have now as separate mailing lists. I think one good thing about doing this if it’s workable is that we can move topics to different forums (e.g. if someone posts in python-dev but it should have been in python-list) and it allows much easier interlinking and quotes from different forums.

On Jun 21, 2016, at 2:49 PM, Brett Cannon <brett@python.org> wrote:

There is at least a mailing list mode for Discourse: https://meta.discourse.org/t/what-is-mailing-list-mode/46008 <https://meta.discourse.org/t/what-is-mailing-list-mode/46008> . Mozilla actually funded some mailing list interaction work: https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-a... <https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-a...> .

On Tue, 21 Jun 2016 at 11:44 Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote: Excuse my total ignorance -- what's the experience for users who don't interact through Discourse? Do they not see anything that's happening in Discourse, or does it have a gateway (like python-list vs. comp.lang.python, or the various GMane things)?

On Tue, Jun 21, 2016 at 11:38 AM, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote: I'm willing to offer up python-ideas as an experimental group of people to try a new approach to communicating if we want to try something out on an existing mailing list that isn't as critical as python-dev. I also know that Donald has expressed interest in trying Discourse on distutils-sig as have I (I believe lack of time is what has prevented this experiment from occurring on Donald's side, definitely the reason I haven't tried Discourse on python-ideas).

_______________________________________________ Overload-sig mailing list Overload-sig@python.org <mailto:Overload-sig@python.org> https://mail.python.org/mailman/listinfo/overload-sig <https://mail.python.org/mailman/listinfo/overload-sig>

-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) _______________________________________________ Overload-sig mailing list Overload-sig@python.org https://mail.python.org/mailman/listinfo/overload-sig

— Donald Stufft

On Jun 23, 2016, at 9:59 AM, Barry Warsaw <barry@python.org> wrote:

...

(Note that I would personally happily participate in the Discourse experiment -- I'm just asking whether this would appear like a fork to current python-ideas subscribers or more like some kind of alternate UI they can ignore -- the way I ignore GMane.)

This is I think the biggest concern with adopting new forums: fracturing of the community. What happens when a decision is made on Discourse that mailing list members didn't see? I know this happened to me years ago when a decision was made on a Roundup issue that I somehow missed until it was too late.

So I definitely think that long term we should not have parallel forums like both mailman *and* discourse. For a short time period I think it’s fine to try and test the waters, but long term we should pick one tool, whatever that tool is, for this kind of discussion [1] and bless that and get rid of anything else. Whether that’s mailman or discourse or something else. I realize now that I didn’t fully parse what Guido was asking though. If we tried discourse it would essentially be a fork as I don’t think they have a way to mirror that information back into Mailman or provide a two way interface between the two. In my searches it appears that the discourse folks are split on what a project should do if moving from Mailman to Discourse. Some of them suggest that the data models of the two are divergent enough that there’s not a good way to import without it appearing ugly and they suggest closing down the MM list but leaving the archives and starting fresh. However some of them also seem to suggest closing down the MM list and importing past discussions, and they’ve provided a tool to import Mailman’s mbox files. It appears that there is a one-way sync being added via a Mozilla grant so that discourse can act as a read-only front end to an active list, but that won’t allow people to post to the list via discourse, only read it. It appears the Wikimedia foundation is going through a similar question as documented by https://meta.wikimedia.org/wiki/Discourse. It looks like they have a discourse instance setup as a pilot phase and they go over some of the pros/cons between the two systems as they see it. In looking at the MOSS grant, which they’re targeting for completion in July 2016 it appears the main focus was to implement the features required to allow people to use Discourse entirely from within an email client and never need to use the web UI. Details of that grant can be found at https://meta.discourse.org/t/moss-roadmap-mailing-lists/36432 [1] E.g. real time is fine to have somewhere else, but we shouldn’t have two sort of async long form topic based communication mechanisms. — Donald Stufft

On Jun 23, 2016, at 12:00 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:

On Thu, Jun 23, 2016 at 9:27 AM, Donald Stufft <donald@stufft.io <mailto:donald@stufft.io>> wrote: For a short time period I think it’s fine to try and test the waters, but long term we should pick one tool, whatever that tool is, for this kind of discussion [1] and bless that and get rid of anything else. Whether that’s mailman or discourse or something else.

If you decided that (for example) python-dev would move to Discourse, is there

a) some way to suck the old MM archives into Discourse?

Discourse has an importer yes, I don’t know the quality of said importer but it has one (and actually, having discourse being able to function as a read only interface to an MM list is one of the goals of a recent Mozilla Grant they’ve gotten).

b) allow search engines to index them?

It's not clear that the infinite scroll thing allows for (easy) indexing, though I assume Google and Bing have their collective act together in this regard.

Well I haven’t explicitly looked for this, but given that I regularly get discourse results in my google queries I suspect that it works fine.

Would the MM->some-kind-of-forum decision be made on a list-by-list basis, or would some lists always remain MM-hosted? I can see where the natives might get very restless if you migrated comp.lang.python/python-list@python.org <mailto:python-list@python.org> to some sort of forum tool. Python-dev or python-ideas would be bad enough, but for c.l.p it would probably be torches and pitchforks time.

It’s possible to use email to some degree (what degree exactly I’m not sure about, previously it wasn’t able to completely replace the web interface, but it appears that they want to make it so that it’s possible to use Discourse to fully replace the feature set of mailing lists rather than just having email as an added on feature. So it’s sort of a like a cross between a forum and a mailing list. That being said, I think there are benefits to standardizing around one medium, but I suspect that if we did decide to switch to Discourse we wouldn’t be able to shut down MM entirely since it’s also hosting mailing lists for things that aren’t python-dev affiliated but are written in Python and I think we wouldn’t want to force them all onto discourse or to find their own solution. Given that, it seems low cost (besides losing the standardization benefits) to allowing the decision to be made on a per-list basis. Of course, it’s not my decision :) — Donald Stufft

I just want to say that I agree with Guido's assessment that the variety of email workflows and tools is not helping the situation. Notice how many people reply with the same answer to the same email simply because their email client doesn't notify them that there's a new email (e.g. I was about to reply to one of Skip's emails but Inbox notified me of a new email and so I checked and sure enough, Donald beat me to it; most people don't notice this sort of thing as shown on python-dev when someone mis-posts). I wonder how much noise would be cut down if we simply had a system where there was a harmonious UI for everyone that smoothed out things like notifying when there's an update? And the separate topics thing is also something I agree with. Due to email lacking a canonical URL, we can't point people at topics short of saying "search your email history" (which once again varies in abilities from person to person). This comes up not only when we say there's an old topic people should be building off of, but also when a conversation forks. Add to that when someone joins a mailing list mid-conversation and they have no way to reply to a message pre-joining and all of this compounds itself thanks to email's inherent "personal experience". On Thu, 23 Jun 2016 at 09:31 Guido van Rossum <guido@python.org> wrote:

On Thu, Jun 23, 2016 at 7:27 AM, Donald Stufft <donald@stufft.io> wrote:

...

...

On Jun 23, 2016, at 9:59 AM, Barry Warsaw <barry@python.org> wrote:

...

(Note that I would personally happily participate in the Discourse experiment -- I'm just asking whether this would appear like a fork to current python-ideas subscribers or more like some kind of alternate UI they can ignore -- the way I ignore GMane.)

This is I think the biggest concern with adopting new forums: fracturing of the community. What happens when a decision is made on Discourse that mailing list members didn't see? I know this happened to me years ago when a decision was made on a Roundup issue that I somehow missed until it was too late.

So I definitely think that long term we should not have parallel forums like both mailman *and* discourse. For a short time period I think it’s fine to try and test the waters, but long term we should pick one tool, whatever that tool is, for this kind of discussion [1] and bless that and get rid of anything else. Whether that’s mailman or discourse or something else.

I realize now that I didn’t fully parse what Guido was asking though. If we tried discourse it would essentially be a fork as I don’t think they have a way to mirror that information back into Mailman or provide a two way interface between the two. In my searches it appears that the discourse folks are split on what a project should do if moving from Mailman to Discourse. Some of them suggest that the data models of the two are divergent enough that there’s not a good way to import without it appearing ugly and they suggest closing down the MM list but leaving the archives and starting fresh. However some of them also seem to suggest closing down the MM list and importing past discussions, and they’ve provided a tool to import Mailman’s mbox files.

It appears that there is a one-way sync being added via a Mozilla grant so that discourse can act as a read-only front end to an active list, but that won’t allow people to post to the list via discourse, only read it.

It appears the Wikimedia foundation is going through a similar question as documented by https://meta.wikimedia.org/wiki/Discourse. It looks like they have a discourse instance setup as a pilot phase and they go over some of the pros/cons between the two systems as they see it.

In looking at the MOSS grant, which they’re targeting for completion in July 2016 it appears the main focus was to implement the features required to allow people to use Discourse entirely from within an email client and never need to use the web UI. Details of that grant can be found at https://meta.discourse.org/t/moss-roadmap-mailing-lists/36432

[1] E.g. real time is fine to have somewhere else, but we shouldn’t have two sort of async long form topic based communication mechanisms.

You dug up some very interesting research! It's good to know we're not the only ones grappling with this.

Bear with me while I veer off-topic in a variety of directions (this list is exposing the problems we're discussing quite well :-).

I am not that worried about fracturing of the community -- that has already happened, in a sense, with the splits between python-ideas, python-dev, and various SIGs, and the use of the tracker for many discussions (including decisions). We're surviving that part of the problem just fine: the current problem (reflected in the name of this sig) is too many people posting in one place, not too many places where people post.

I know that Stephen believes that we have a social problem and hence shouldn't try to solve it by technical means. That's a common meme, but I'm not sure it is necessarily correct. Technical solutions can very seriously alter social behavior (e.g. chat apps on smartphones). And my sense is that the social problem we have *can* be addressed by a change in technology, if we are willing to invest in the change (like we are for e.g. the hg->git transition).

My own workflow is super browser based. I have two browsers open on GMail (Firefox for "personal", which includes all Python work, Chrome for work -- Dropbox) and I check these all the time. I also have tabs open on Slack and Google Calendar (for work) and Twitter (personal). Slack and GCal sometimes pop notifications on my screen (I've configured Slack to do this only when people call my name or say "python 3" :-).

Many, many workflows that I use are integrated with these, and by far the strongest integration is with email. When Slack sees I've been called while I was online, it sends me an email. When someone comments on an issue or code review I am subscribed to I get an email. Calendar invites come in email (and can be accepted right there).

All in all I can handle a very large amount of email efficiently. But what's hard is discussions on python-dev and python-ideas, and I believe part of the problem is due to the variety in email tools that people use (and in workflows, and in experience and maturity). The net effect is that discussions quickly go back and forth between needless repetition, off-topic diatribes, on-topic rebuttals, multiple discussions going on in the same topic, the same discussion going on in many topics, and so on.

Note the focus on topics here. I am wishing for a UI that keeps the discussions more organized. I think that as long as people's model is a mailing list with a smart UI, it's not going to satisfy me. I think that what I'm looking for must be modeled in people's minds as a database for discussions with a high-quality web UI, and personalized email integration. Google groups, terrible as it is, actually gets that part right. You can configure it so that every email has a permalink to the same message in the web UI. This is of course also what issue trackers do. But in other areas Google groups has no imagination compared to what GitHub's tracker can do.

One last thing. Replies to digest emails should not be allowed to start a new "topic". Ever.

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Overload-sig mailing list Overload-sig@python.org https://mail.python.org/mailman/listinfo/overload-sig

I'm sold. Let's start by moving this very sig to Discourse, or at least by setting up a parallel Discourse instance where we can discuss this and experiment. If anyone has a different system they want to promote let's do that too. E.g. maybe we should migrate to MM3 as another experiment. I would also be happy to set up a GitHub tracker named python/overload-sig, but I'm not sure I'd personally learn anything new from that (though others may, and I might find it less useful for the kind of discussions we're having here than for discussing software features and bugs). On Thu, Jun 23, 2016 at 10:09 AM, Donald Stufft <donald@stufft.io> wrote:

On Jun 23, 2016, at 12:31 PM, Guido van Rossum <guido@python.org> wrote:

Note the focus on topics here. I am wishing for a UI that keeps the discussions more organized. I think that as long as people's model is a mailing list with a smart UI, it's not going to satisfy me. I think that what I'm looking for must be modeled in people's minds as a database for discussions with a high-quality web UI, and personalized email integration.

From my experience thus far with discourse, this is basically what it is. Originally they didn’t even allow starting new topics via email only replying to existing topics (although I think they have since changed this so it’s optional based on configuration). Thinking of it like a more discussion focused Github Issue tracker is probably a reasonable mental model for how it functions in practice.

I think it has a number of features and (for lack of a better word) “patterns" that will help reduce the trend for endless cycling and the “deluge” of email, such as:

* 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. * Move topics to the correct category (e.g. move from python-dev to python-list) instead of having 12 people reply “wrong list!”. * The ability to automatically allow long term, good users to move up in “level” to gain additional privileges to help moderate the community (similar to StackOverflow).

* Features to reduce the need for new messages and reduce repetition . * Notification *while* you’re writing that new posts have been added so you can scroll down and read them to see if someone else already said what you were going to say. * Ability to multi quote in a single response in a structured way, and compose those multi quotes as you read (adding a reply is done inline as you read down the thread, and you can click a button to quote another post as you read down further). * Mentioned above, but writing a response is done inline as you read the post (it floats on the bottom of the UI) so you can compose while you read, and keep composing until you read the entire thread, instead of firing off multiple email responses to multiple people. * “Likes” on posts to remove mindless +1’s (I thought this was silly when Github introduced it, but I now quite like it). * A suggestion of possible duplicated topics when posting a new topic to try and guide people towards previous or ongoing discussions instead of rehashing the same thing over and over again. * A “Summarize” topic button that filters the topic down to the "most interesting posts as determined by the community” (I don’t know how well this actually works in practice).

* Features to make inter-related discussions work better. * Ability to split a topic into two different topics. * Interlinking between posts in different topics as well as quotes and the like.

——

Now, all of the above is theoretically achievable with a traditional mailing list, but I think that discourse offers a better medium for achieving those things. Largely for one main reason: Mailing lists push the burden of achieving all of that onto each and every individual participating in the discussion whereas discourse (and other “forum”-esque software) tends to push the burden of that onto the software itself. This is made even more difficult with the disparate workflows and clients that people are actually using which ends up causing strife as different tools interpret things differently.

For instance, if you want to split a discussion out into a different thread, you have to change the subject of the new thread and make a post, possibly quoting the old post in that. However you’re relying on social convention that people aren’t going to keep responding to that split discussion in the original thread. This sort of works but it also sort of doesn’t, particularly when dealing with mail clients that will render the new thread as part of the sub thread causing people to not realize that it was ever split out to begin with.

Another example is say you want to redirect someone who errantly posts to python-dev instead of python-list. Currently the typical workflow for this is they post incorrectly, and they get somewhere between 1 and 10 people responding with the same message that they need to take that to python-list. Only one reply was needed but because email doesn’t offer a way to mark a topic as closed, there’s no way to prevent additional email, versus something like discourse where you can actually physically move the topic along with a message saying that it was posted in the wrong location.

Now, historically forums have worked by having a finite set of moderators whose job it is to do this sort of janitorial work, however discourse functions more like StackOverflow [1] where the community itself moderates the forums and people gain moderation power over time as they demonstrate a positive interaction with the community at large. I think this could work very well for us since it’s basically the model we use for bugs.python.org (except there we don’t even require people to build up reputation, if you get an account you can munge the state of issues however you want). The exact specifics how fast someone gains reputations and what powers they gain are of course, configurable. I think this is a powerful way to deal with a lot of these problems though, and it allows centralizing these actions (like moving a topic) instead of relying on all users to sort of agree in a sort of hive mind for how to deal with particular threads.

[1] Which shouldn’t be surprising, given Jeff Atwood is involved in both.

— Donald Stufft

-- --Guido van Rossum (python.org/~guido)

The free-for-OSS details can be found at http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community... . If we want to start the experiment without a custom domain I think that's fine since I assume we can add it later. Might as well go for the easiest solution for now while we play with an installation before we worry about whether we want their free offer, paid-by-PSF hosting, or self-run hosting. On Thu, 23 Jun 2016 at 10:25 Donald Stufft <donald@stufft.io> wrote:

On Jun 23, 2016, at 1:19 PM, Guido van Rossum <guido@python.org> wrote:

I'm sold. Let's start by moving this very sig to Discourse, or at least by setting up a parallel Discourse instance where we can discuss this and experiment.

Ok. I guess I can take on doing that. Let me investigate the options for hosting. I know that discourse the company offers paid hosting of discourse the software and I think they give it free to OSS projects, even at their own domain, provided they make the URL something like `` discourse.python.org``. If that’s acceptable I can reach out to them and try to set that up. If we’d rather have a name that isn’t tied to a specific piece of software (like ``discuss.python.org``) or we’d rather not host this externally then i can see about setting that up on our own infrastructure.

Either way, Discourse provides a way to suck up all of the data out of it into a backup and “take it with you” which you can import into a running instance elsewhere so the downside of using hosted is pretty low I think.

—

Donald Stufft _______________________________________________ Overload-sig mailing list Overload-sig@python.org https://mail.python.org/mailman/listinfo/overload-sig

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. Anyway, in development channels, you often do want to be able to reopen old topics (when they regress or when new technology becomes available that obsoletes the old solution). This operation shouldn't be limited to a 100-hit-point BDFL with a +32 magic sword, any J. Random User should be able to do so.

* Move topics to the correct category (e.g. move from python-dev to python-list) instead of having 12 people reply “wrong list!”.

True, but a fairly minor example. I think the thread-splitting case is where this is a killer feature. Assuming people will actually split threads more effectively than they do in email. I think that's quite possible (likely, if you like), because of the synchronous nature of posting, and because it will be cheap for people who accept the responsibility to curate the threads.

* The ability to automatically allow long term, good users to move up in “level” to gain additional privileges to help moderate the community (similar to StackOverflow).

This doesn't actually work very well in some contexts (eg, Wikipedia). On SO, I've noticed that I frequently disagree pretty strongly with the relative ratings of posts.

* Features to reduce the need for new messages and reduce repetition . * Notification *while* you’re writing that new posts have been added so you can scroll down and read them to see if someone else already said what you were going to say.

+1

* Ability to multi quote in a single response in a structured way, and compose those multi quotes as you read

+1 But then I already have that, because I use XEmacs. There rest of the world doesn't, because they use GMail. Granted, that battle is long since lost. Mail clients are by and large going to suck for the rest of eternity, because they're the low-denominated commoners. :-(

(adding a reply is done inline as you read down the thread, and you can click a button to quote another post as you read down further).

And this works well on a smartphone in your experience? Smartphones are the bane of email IMO.

* “Likes” on posts to remove mindless +1’s

Excuse me, but they're not mindless. Most people who +1 do trim, which is more than most people who write longer replies seem capable of these days. Agreed, having the UI track this as a count rather than as separate messages is a very good thing.

* A suggestion of possible duplicated topics when posting a new topic to try and guide people towards previous or ongoing discussions instead of rehashing the same thing over and over again.

I suspect that the AI isn't good enough for a dev channel. Fine distinctions matter more than for blog comments or user support where 90% of the queries refer to FAQs.

* A “Summarize” topic button that filters the topic down to the "most interesting posts as determined by the community” (I don’t know how well this actually works in practice).

This is bad IMHO, whether it works well or not. Guido is going to get lots of likes no matter what. The problem is people who are coming out of lurking for the first time will get ignored unless the bar is so low that little gets excluded. People who write English as a second language are not going to get as many "likes". Etc.

* Features to make inter-related discussions work better. * Ability to split a topic into two different topics.

This is easy enough to do in email; people just fail. Perhaps Guido is right on this one, the technology may make it easy enough that people will do it. Specifically, the ability to move inadvertant posts to the old topic to the new one as appropriate -- email threading won't permit that.

Now, all of the above is theoretically achievable with a traditional mailing list, but I think that discourse offers a better medium for achieving those things. Largely for one main reason: Mailing lists push the burden of achieving all of that onto each and every individual participating in the discussion whereas discourse (and other “forum”-esque software) tends to push the burden of that onto the software itself.

Wishful thinking. What makes discourse civilized in Jeff Atwood's forums is Jeff Atwood, mostly. He does not hesitate to come down hard on barbarians. The software may facilitate this, but the work has to be done by people. We have people who have the social standing and interpersonal skills to do this well; it remains to be seen if they also have the time. Also remember, StackExchange is a discussion/user support forum, not a development channel (at least as far as I've seen). Coding Horror is a blog. The stakes are small and the cost of booting a French soldier for farting in your general direction is small. Compare that to os.urandom() or %-formatting for bytes or even making type annotations the standard use for function annotations -- where the first is what inspired this whole channel because people were so wound up in the discussion that they unsubscribed.

For instance, if you want to split a discussion out into a different thread, you have to change the subject of the new thread and make a post, possibly quoting the old post in that. However you’ re relying on social convention that people aren’t going to keep responding to that split discussion in the original thread. This sort of works but it also sort of doesn’t, particularly when dealing with mail clients that will render the new thread as part of the sub thread causing people to not realize that it was ever split out to begin with.

This will be just as true in Discourse, I think -- except that (1) you can provide a link to parallel threads and (2) moderators can move posts. (1) is a burden on the software, but if people by and large can't distinguish HTTP connections from HTTPS connections in their browser nor phishing from a real Christmas e-card from Grandma, I wonder if they'll actually notice the split thread. (2) is work for people. Bottom line: I'm not as enthusiastic as Guido about the theory, but I agree Discourse has a lot of interesting features and is well worth trying. Just be careful to configure it so that newbies (who may actually be long-term lurkers or even Uncle Timmy who hasn't posted in two years! -- well, it seemed like that long) are visible to the Cabal (even though there is no Cabal).

Kevin Ollivier writes:

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.

You have plenty of company, but the people who disgree with you are precisely those who have devoted many hours to getting up to speed on security issues, and to responding to them when they are reported in Python. Guido was unwilling to make the call without advice from prominent OS-level security experts including the maintainer of the Linux CSPRNG functionality, which I think is indicative that there really was something to discuss.

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

Ah, but it *did* start on the tracker! But the actual history was rather different from your thought experiment. There was heated discussion of the issue over a 48- or 72-hour period, there was an impasse in the discussion, the Release Manager who technically has the authority to make the call decided it was above his pay grade, and brought in the BDFL -- and it was that decision that *started* the thread on python-dev. I hope that our discussion in this SIG can contribute to more orderly discussion of security issues, too. But they bring special problems (the passion that people feel about both security and backward compatibility), and they are outliers in terms of the intensity of the thread and their relative infrequency. Sometimes it's useful to use them as examples, but I do not think they should be considered typical. Steve

Kevin Ollivier writes:

Yes, but all of that served no purpose if they were debating a fix to a problem that we haven't even proved exists, much less is being experienced in the wild.

None of the protagonists questioned that both problems (a security problem and a performance problem, depending on whether the 3.4 behavior or the 3.5.1 behavior is adopted) exist. The entire discussion revolved around which problem should be fixed in 3.5.2. So as far as I can see, your analysis that there was no problem has no bearing on the social dynamics, even if you are correct -- everybody else believed otherwise throughout the thread. Steve

Are you guys intentionally repeating this pointless debate? Proving that the discussion was misguided doesn't change the problem, which is that it nevertheless happened. I don't think Stephen is claiming that the debate *should* have happened. He is just pointing out *that* it happened. This merely illustrates that people don't always behave rationally.

You couldn't have changed the trajectory that way, because the discussion was about people's feelings. It only *appeared* to be about a code change. Anyway, indeed let's stop.

Let me summarize what I think you're saying: "instead of having emotions flare we should have redirected the discussion to the issue tracker requesting a reproducible bug, use case and fix". If that's not what you're saying then (in this very long and emotional thread) please summarize what you *are* proposing. My response to what I think you said is: whatever, it happened that time (despite having started in the tracker), and it will happen again, no matter what policies we institute; we need a way to guide future discussions once they have derailed, not a set of rules to prevent it from happening (because if everyone behaved rationally we would never have such derailments).

Kevin Ollivier writes:

Well, we disagree here, I think most of it in fact can be prevented.

But how? You have made no argument except that "people don't 'need' to do it, and so they shouldn't do it." If you don't have a concrete proposal that doesn't amount to "we should require people to have better self-control", we're done here. People are what they are; requiring them to change is a recipe for failure and intense frustration -- because they won't unless encouraged to by procedural changes. The only procedural suggestion so far ("provide a concrete case") is already in place, and worked effectively, in the case of os.urandom. As far as Python-Dev is concerned, there is no question of the validity of the bug. I can say that because it is being addressed in 3.6. It's just that the RM and the PSRT had very different opinions about the importance of the case presented, and the consequences of different policies for dealing with it in 3.5.2. I also see a big practical problem with what I understand you to be suggesting in the case of the security brouhaha. That is, it's the PSRT members who are frustrated to the point of disengaging from the community. According to your analysis, we should impose an even greater burden on exactly the folks who were most stressed by the outcome. Developer retention is an important goal of our work here, so I think that's counterproductive. Note that the opposite allocation of burden applies to the case of inexperienced developers, who did not help develop the patch being discussed, pontificating aggressively on issues they have (as yet) only shallow understanding. The core developers get frustrated, the new folks find it addicting -- cooling the latter down is a good idea all around. Regards, Steve

On Jun 23, 2016, at 09:31 AM, Guido van Rossum wrote:

My own workflow is super browser based.

I think that's a very important observation, and it may expose the fracture lines in any tool adoption. My own workflow is heavily email based because I don't use gmail and literally everything that I have to care about on a daily basis for work comes to me through email. As an extension of that, I can respond to email with my regular editor, which is also my interface to IRC. So my environment is integrated and efficient, but not browser based. That's why I find Launchpad code reviews so much more pleasant than GH/GL. The former can be done via email (or the web of course) but the latter is only web based. I can see why if your workflow was browser based, more browser tabs/windows wouldn't be a big deal. For me, it would very much be a pain if I had to bring my browser to the forefront of my attention. I do use a browser of course (in fact, two different ones, with 4 total windows and countless plus changing number of tabs), but it's always a break in my workflow to go deal with them. Cheers, -Barry

One of the reasons I do it this way is that I see most people around me do it. I imagine I want to experience how most people's setup works, not some super awesome wizard way that most people would have a hard time emulating. --Guido (mobile)

Guido van Rossum writes:

I know that Stephen believes that we have a social problem and hence shouldn't try to solve it by technical means.

That's not exactly my position. I don't deprecate technical improvements -- simply allowing people to dispose of conversations more quickly will reduce the burden, for example. But we should be entirely unsurprised if the social problems aren't resolved.

That's a common meme, but I'm not sure it is necessarily correct. Technical solutions can very seriously alter social behavior (e.g. chat apps on smartphones).

Alter, yes, but rarely is that alteration something we can tune to our needs. It may be a close match if we're lucky. The main thing I see in web fora that would help is "collision avoidance" by using a synchronous system. Email is asynchronous, so it's very frequent that you see multiple posts saying nearly identical things (that's especially annoying when it's a chorus of "off-topic, try c.l.p"), or beating a deceased parrot because they missed the vet's declaration of death, etc.

And my sense is that the social problem we have *can* be addressed by a change in technology, if we are willing to invest in the change (like we are for e.g. the hg->git transition).

Not a good analogy to support the "solution to social problems" claim, though.

All in all I can handle a very large amount of email efficiently. But what's hard is discussions on python-dev and python-ideas, and I believe part of the problem is due to the variety in email tools that people use (and in workflows, and in experience and maturity).

Er, are you sure you want to mention social problems? ;-)

Note the focus on topics here. I am wishing for a UI that keeps the discussions more organized.

That's dlists, coming more-or-less-soon to a Mailman 3 near you. (OK, it's not the only one, and definitely trackers and maybe Discourse already satisfy that requirement.)

I think that as long as people's model is a mailing list with a smart UI, it's not going to satisfy me.

That's not dlists. Dlists really do create issue-like threads, essentially multiple lists based on participation. But it's still email; dlists do not help synchronize a thread where posts arrive at 5-minute intervals.

You can configure it so that every email has a permalink to the same message in the web UI.

Mailman 3 has that. You should take the Mailman 3 advocacy with a grain of salt, especially since dlists aren't available yet (not even as a patch). However, I think the direction Mailman 3 is going certainly validates your analysis (and vice-versa).