|
|
Subscribe / Log in / New account

Rethinking python-ideas

By Jake Edge
February 3, 2016

The communication style of a project can often have an effect—for good or ill—on its ability to attract new developers. The established channels, which are often email-based, may work reasonably well for the existing developers, but frustrate new people. Finding the right balance can be difficult, which is something the Python community is currently discussing.

The specific channel under discussion is the python-ideas mailing list, which is meant for more speculative discussions of potential Python features. On that list, Michael Selik wondered if some forum other than a mailing list would help new people figure out which opinions were more valuable than others: "One defect of a mailing list is the difficulty of viewing a weighted average of opinions". He likened the situation to the US Senate, where each state has the same representation even though they may have vastly different populations.

Selik suggested that perhaps Stack Overflow might be a better tool for forums like python-ideas. That short post was a springboard for considering the tradeoffs of different communication mechanisms, with an eye toward alternatives for some Python development discussions. Nick Coghlan described the feature discussion process, which can take place in a variety of forums, including the bug tracker, mailing lists, and the Python Enhancement Proposal (PEP) process. How the right forum is determined is more of an art than a science, he said; the core developers help guide that. The mailing lists definitely play a role:

The python-dev and python-ideas communities form a very important part of that process, but the most valuable things folks bring are additional perspectives (whether that's in the form of different use cases, additional domains of expertise, knowledge of practices in other programming language communities, etc)

That's not to say that there might not be better ways to host those discussions, Coghlan said in response to a "vote" for StackExchange (which is the parent of Stack Overflow). The limiting factor is typically the ability of the Python Software Foundation (PSF) to add and manage new infrastructure.

Selik summarized some of the problems he sees with a list like python-ideas. In particular, it is hard for a new participant to recognize who are the decision makers, whose opinion is not particularly well-regarded, what the real consensus is, and so on. These are difficult to discern from a mailing list, but might be easier to pick up on using a discussion forum with a reputation system or voting.

There is some attraction to a forum like Stack Exchange, which Guido van Rossum summed up in a message supporting an experiment to augment python-ideas:

A StackExchange discussion has some advantages over a thread in a mailing list -- it's got a clear URL that everyone can easily find and reference (as opposed to the variety of archive sites that are currently used), and there is a bit more structure to the discussion (question, answers, comments). I believe there are some good examples of other communities of experts that have really benefited (e.g. mathoverflow.net).

Van Rossum noted that there is at least one downside: StackExchange is not particularly usable for those with an email-centric workflow. Some questions were raised about the fit for StackExchange's "question and answer" format and the kinds of discussions that go on in python-ideas. Brett Cannon suggested some other possibilities:

A better fit would be something like https://www.uservoice.com/ if people wanted a focused "vote on ideas" solution, or something like https://www.discourse.org/ for a more modern forum platform that has the concept of likes for a thread. And then there's https://gitlab.com/mailman/hyperkitty as Barry [Warsaw] suggested to add the equivalent of what Discourse has to Mailman 3.

It turns out that, for those who were posting in the thread, the voting is not a particularly popular feature from StackExchange. What Van Rossum is looking for is the standard URL that gets created for a discussion that can be referenced later; he also thinks the format will help new participants:

I think it will be easier for new folks to participate than the current mailing list (where if you don't sign up for it you're likely to miss most replies, while if you do sign up, you'll be inundated with traffic -- not everybody is a wizard at managing high volume mailing list traffic).

The conversation soon turned toward Discourse and, to a lesser extent, HyperKitty (which is part of the Mailman 3 suite). Those seem to have many of the features of interest without completely leaving email users behind. But some were unhappy that there was any thought of moving to some other communication mechanism. Cannon said that it is important to do so from time to time:

Keeping an open source project running is part technical, part social (which makes it part political :). That social bit means having to occasionally evaluate how we are managing our communication amongst not just long-time participants but also new ones. This means we have to sometimes look at what kids in university are using in order to entice them to participate (heck, even high school at this rate).

He noted that the tools used by longtime Python developers (NNTP, newsgroups, even IRC) may be completely unknown by those university students. But the community needs to "evaluate whether our ways of communicating are too antiquated for new participants in open source and whether they are no longer the most effective (because old does not mean bad, but it does not mean better either), while balancing it with not having constant churn or inadvertently making things worse". It is a balancing act, but the way forward is to try remove the emotional component from the discussion, he said:

It's the usual issue of having to get down to the root of the issue as to why people would want to stay with the mailing list vs. why others would want to switch to Discourse. Finding out the fundamental reasons and taking out the emotion of the discussion is usually the key to helping solve this sort of grounded discussion (at which point you can start ignoring those who can't remove the emotion).

That technique could—perhaps should—be applied more widely in open-source project discussions. However, one of the main friction points between email and web-based discussion forums soon reared its head. Marc-Andre Lemburg noted that he had needed to reformat a reply because the original was in HTML, rather than plain text. To Cannon, though, that was "an example of the OSS community trying to swim against the stream where the rest of the world has moved on and it is slowly making it harder to get new people to participate in OSS".

Lemburg sees things a bit differently, noting that archivers and text-only email readers have to do an imperfect conversion of HTML, which can lose formatting information. He also pointed out: "Email is not going to go away, but I certainly have seen a lot of other communication tools come and go - and I bet there's something to learn in that :-)".

As part of that same exchange, Cannon and Lemburg also discussed the Discourse/HyperKitty question. Cannon suggested that someone that wants to stay on the email side look into Discourse to see where it falls short; he would also like to hear something about what HyperKitty offers. Lemburg said that he hasn't "really seen a compelling argument for switching away from mailing lists completely yet". But that can only come from "an evaluation to properly show what we would gain or lose from a switch to something like Discourse or HyperKitty", Cannon said.

As Donald Stufft pointed out, though, there is a risk in only looking at what new contributors might want. He does think that the "mailing list interface is kind of crummy and relies on people hand tailoring a bunch of filters to make it in any way reasonable", but is concerned that Discourse or HyperKitty may just be "differently bad". Furthermore:

Of course, you don't want to ignore the people who are already contributing or make a decision solely focused on trying to attract new contributors (or increase contributions from small time contributors) since you run the risk of alienating the folks currently doing most of the work and then not getting any new contributions anyways.

There is also a risk of "community fracture" when changing the discussion mechanism, as Barry Warsaw described:

Any new forum will mean another login, a new work flow, another slice of the ever diminishing attention pie, and discussions that occur both on the traditional site and the new site. Some people will miss the big announcement about the new forum. There will be lots of cross-posting because people won't know for sure which ones the people who need to be involved frequent.

For a core developer, there are already multiple forums to follow to keep up with the development; adding another just makes that problem worse. "How many different channels do I have to engage with to keep track of what's happening in core Python?", Warsaw asked. He is in favor of experimentation, but feels that the project should proceed somewhat cautiously.

The split into various forums is going on now and will continue, but major decisions still need to go through python-dev, Van Rossum said. But python-ideas can be "too noisy", which has led some core developers to stop following it. Some other, less noisy discussion mechanism (or one that allows some topics to be muted more easily) might help.

Discourse appears to come the closest to having the features that would fit the bill—and Van Rossum clearly liked Discourse—though its email integration is not quite there yet for the email-only users. HyperKitty has some of those features on its radar, but has not had the time to implement them. There looks to be some momentum toward an experiment with Discourse, but that will require someone to manage the effort, perhaps to request some funding or assistance from the PSF, and so on. We shall see if that materializes.

There are some free-software projects that still communicate the same way projects have been doing so for decades: plain-text email, perhaps augmented by IRC. Some have branched out and added bug-tracker discussions and web-based forums of various sorts. Finding the right mix to keep existing contributors happy, while attracting new ones, is a delicate matter. We will likely see it play out in other communities as well. There is no "one size fits all" solution here, but seeing what works and doesn't—and why—will be beneficial to others. That is certainly one of the advantages of the free-software ecosystem.


to post comments

Discussion channels

Posted Feb 4, 2016 12:47 UTC (Thu) by ber (subscriber, #2142) [Link]

Thanks for the article summarizing the discussion. It is useful because summaries allow a faster entry in the discussion or its results. Just like permanent link are a plus. I wonder if the social coding aspects were not present in the discussion at all. Like the social network functions that microblogging would bring. Github for instance seems to be popular because some people believe that it makes observing some development and (code) discussion aspects easier.

It is my conviction that Free Software tools should be used, even if a service provider is paid to run them. Discourse and HyperKitty seem to fit this aspect well.

Rethinking python-ideas

Posted Feb 6, 2016 17:23 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (2 responses)

> What Van Rossum is looking for is the standard URL that gets created for a discussion that can be referenced later

if this is the killer feature, then what is wrong with sticking to mailing lists that get archived by Gmane [1]? This also gives infrequent posters the option of following with RSS, web interface or newsgroup.

I do think there's a niche for something a little less heavyweight than Discourse, yet with better email support. Something like a Gmane that you can also *post* to via a web interface...posts get distributed via email and the web interface, and other means. If people like pretty formatting, they can write messages in Markdown (either in their emails or using the web interface); that could then be transformed into HTML for the web interface, and either HTML or traditionally-formatted plaintext for email, at each user's option.

Not that I'm going to implement this, but I reckon lots of projects that use mailing lists would benefit from this, without annoying existing mailing list users.

[1] http://gmane.org/

Rethinking python-ideas

Posted Feb 6, 2016 20:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Gmane is not very reliable, and it also sometimes tends to lose messages.

Rethinking python-ideas

Posted Feb 8, 2016 20:47 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

There's the software that runs the D language fora. It's just a read/write web interface on top of mailing lists.

Code: https://github.com/CyberShadow/DFeed
Instance: http://forum.dlang.org/

Rethinking python-ideas

Posted Feb 6, 2016 18:14 UTC (Sat) by dlang (guest, #313) [Link]

The Baen publisher forms combine e-mail, nntp, and a web forum, using mailman for the e-mail/nntp and FUDForum for the web forum. While there are periodic complaints about not having some gee-wiz features on the web forum, overall it works pretty well with many people on the web forum being unaware that the other options exist (until the periodic discussion pops up)


Copyright © 2016, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds