Issue tracker vs. real-time chat
(We accidentally started this discussion on private email. I assume noone has a problem with me reposting this to the sig.) I'd like to put in a vote *for* systems or paradigms that behave more or less like issue trackers (AFAIC even Reddit and StackOverflow fall in this pattern) and *against* group chat systems (IRC, HipChat, Zulip, Slack, Skype, Hangouts). To be sure, I'm fine with the existence of chat systems, but I find participating in them exhausting, and they tend to have a very high noise level. They exacerbate the problem that only those who can keep up with the traffic know what's been discussed already (scrollback features in Slack etc. notwithstanding). Usually the mute control is too course. AFAIK only Zulip supports any kind of "topic" selection (Slack is based on group membership, and groups are relatively static, even though membership is dynamic). QUOTE from Kevin: I think we should definitely be seeing what we can do to improve the mailing list experience. :) I've not worked with Mailman 3 myself yet but it sounds like 3.0 is a pretty significant improvement. I was pretty curious about Posterious particularly, although I didn't manage to find an example of it online. Is there a good example to look at? In addition to that, I think we should also be looking at improvements for our bug trackers and chat software as part of this. Playing with GitHub's bug tracker may be a good start, and maybe something like Slack or Zulip for chat would be a nice improvement. I've gotten spoiled by the ability in Slack to see the conversations that happened while I was offline. I know Zulip, like Posterious, is a Django-based app, and it would be cool to have more of our infrastructure built on top of Python so long as it doesn't become a maintenance burden. Maybe the Zulip team would even be willing to help out? -- --Guido van Rossum (python.org/~guido)
Hi all, Sorry guys, also just did a reply all, following suit here and re-posting my reply on overload-sig. From: Overload-sig <overload-sig-bounces+kevin-lists=theolliviers.com@python.org> on behalf of Guido van Rossum <guido@python.org> Reply-To: <guido@python.org> Date: Tuesday, June 21, 2016 at 12:02 PM To: <overload-sig@python.org> Subject: [Overload-sig] Issue tracker vs. real-time chat (We accidentally started this discussion on private email. I assume noone has a problem with me reposting this to the sig.) I'd like to put in a vote *for* systems or paradigms that behave more or less like issue trackers (AFAIC even Reddit and StackOverflow fall in this pattern) and *against* group chat systems (IRC, HipChat, Zulip, Slack, Skype, Hangouts). To be sure, I'm fine with the existence of chat systems, but I find participating in them exhausting, and they tend to have a very high noise level. They exacerbate the problem that only those who can keep up with the traffic know what's been discussed already (scrollback features in Slack etc. notwithstanding). Usually the mute control is too course. AFAIK only Zulip supports any kind of "topic" selection (Slack is based on group membership, and groups are relatively static, even though membership is dynamic). I don't consider them something everyone has to use, but I do think they serve a valuable purpose. It's about community building. Sometimes developers should chit-chat, or post a gif meme, because when they're engaged in a big discussion later on they'll have a more holistic picture of the person they're debating with. A project named after a group famous for SPAM, holy hand-grenades, silly walks, and catapulting cows ought to have a forum for engaging in some degree of foolishness and levity, if you ask me. :) We unfortunately cannot regularly get together and share a beer together, but this is the next best thing for OSS projects. People tend to always be very focused and serious on mailing lists, and personally I believe it's a significant contributing factor to burnout and overload. At some point, contributing simply becomes no fun. The community can start to appear as a bunch of very picky critics who pull apart your every thought. I would wholeheartedly agree that mailing lists aren't the place for chit-chatting among devs, but I think there should be such a place, and IRC isn't really the best choice these days. (At a hotel recently they even blocked my internet because the IRC protocol resembled P2P traffic!) Anyway, that's my reasoning for it. Every community is different, so YMMV, but I will say I've seen it used somewhat heavily on the more productive and agile OSS projects I've worked with. Thanks, Kevin QUOTE from Kevin: I think we should definitely be seeing what we can do to improve the mailing list experience. :) I've not worked with Mailman 3 myself yet but it sounds like 3.0 is a pretty significant improvement. I was pretty curious about Posterious particularly, although I didn't manage to find an example of it online. Is there a good example to look at? In addition to that, I think we should also be looking at improvements for our bug trackers and chat software as part of this. Playing with GitHub's bug tracker may be a good start, and maybe something like Slack or Zulip for chat would be a nice improvement. I've gotten spoiled by the ability in Slack to see the conversations that happened while I was offline. I know Zulip, like Posterious, is a Django-based app, and it would be cool to have more of our infrastructure built on top of Python so long as it doesn't become a maintenance burden. Maybe the Zulip team would even be willing to help out? -- --Guido van Rossum (python.org/~guido) _______________________________________________ Overload-sig mailing list Overload-sig@python.org https://mail.python.org/mailman/listinfo/overload-sig
On Jun 21, 2016, at 12:20 PM, Kevin Ollivier wrote:
People tend to always be very focused and serious on mailing lists, and personally I believe it's a significant contributing factor to burnout and overload. At some point, contributing simply becomes no fun. The community can start to appear as a bunch of very picky critics who pull apart your every thought. I would wholeheartedly agree that mailing lists aren't the place for chit-chatting among devs, but I think there should be such a place, and IRC isn't really the best choice these days. (At a hotel recently they even blocked my internet because the IRC protocol resembled P2P traffic!)
I've been using Telegram lately in a couple of contexts, and I agree that it's nice to have a less formal forum for socializing. I'm not particularly advocating Telegram, but I think you're right that similar systems have a place in the universe of communication channels. We've tended to use it for keeping in touch at sprints ("Hey, meet in the lobby at 7pm if you want to join us for dinner") and sending interesting little pictures, quotes, etc. The off-line and real-time notifications are the key things that make this useful, but the multiple ways to interact with the system (smartphone apps, web sites) are really useful too. Clearly we don't want major decisions happening here, but then I'd argue that IRC isn't the right place for that either. I am mildly uncomfortable with using closed systems and source, but given that Telegram and similar systems are used primarily for socializing, I think it's fine. I prefer IRC for more real-time technical discussions because I have better ways of interfacing with it while "on the clock". E.g. I can much more easily cut-n-paste URLs, code snippets, tracebacks, etc. into an IRC client, and it's trivial for me to click on URLs to view pastebins, bug tracker issues, merge requests, etc. IRC does have the problem of overlapping discussions, so the lack of topic differentiation is real, although that can sometimes be mitigated by private chat or opening a new channel. I don't think any one forum is going to serve all our needs. Perhaps it's useful to identify the types of communications we want to encourage, and the features that promote those types of communication, then survey our options (both existing and near-term) to see what technology can best promote those types of communication. Some examples: - Socializing: off-topic; anything goes; jokes; fun Python sightings; meetups - Real-time technical discussion: remote pair programming; live debugging; hashing out alternative solutions; what does this code do?; real-time reviews - Asynchronous focused discussions: issue tracking; PEP writing; feature development - Asynchronous unfocused discussions: brainstorming; anybody else have this problem?; wild ideas; this is probably stupid but... - Asynchronous decision making: are we missing anything?; any other opinions before we decide?; wide as possible participation so no one feels left out or unheard from; pronouncements and closure. Cheers, -Barry
As I've aged, I've grown curmudgeonly, so keep that in mind. Barry> I don't think any one forum is going to serve all our needs.... I'm not sure what you're referring to when you use the word "forum". I hope it's not stuff like VBulletin or IB forum software. Those have a purpose, but as an alternative to email (or websites when preserving state is desired), they are definitely a step backward. (Not to mention that forum moderators can sometimes get a bit too dictatorial for my taste.) I trust this august group is up on more modern software tools which advance the state of the forum art. Pointers appreciated. Skip Montanaro
On Thu, 23 Jun 2016 at 08:52 Skip Montanaro <skip.montanaro@gmail.com> wrote:
As I've aged, I've grown curmudgeonly, so keep that in mind.
Barry> I don't think any one forum is going to serve all our needs....
I'm not sure what you're referring to when you use the word "forum". I hope it's not stuff like VBulletin or IB forum software.
I don't even know what those things are. :)
Those have a purpose, but as an alternative to email (or websites when preserving state is desired), they are definitely a step backward. (Not to mention that forum moderators can sometimes get a bit too dictatorial for my taste.)
I trust this august group is up on more modern software tools which advance the state of the forum art. Pointers appreciated.
Part of the point of this SIG will be when Stephen rings the bell and says, "bring out your proposals". At this point all people have talked about are Discourse, MM3/Hyperkitty, and GitHub issues (and status quo implicitly, although I don't think any of us like that idea), but when Stephen outlines the specific aims and gives people a deadline then we might get some other alternatives than those we have lightly touched on.
Hi Barry, On 6/23/16, 6:49 AM, "Overload-sig on behalf of Barry Warsaw" <overload-sig-bounces+kevin-lists=theolliviers.com@python.org on behalf of barry@python.org> wrote:
On Jun 21, 2016, at 12:20 PM, Kevin Ollivier wrote:
People tend to always be very focused and serious on mailing lists, and personally I believe it's a significant contributing factor to burnout and overload. At some point, contributing simply becomes no fun. The community can start to appear as a bunch of very picky critics who pull apart your every thought. I would wholeheartedly agree that mailing lists aren't the place for chit-chatting among devs, but I think there should be such a place, and IRC isn't really the best choice these days. (At a hotel recently they even blocked my internet because the IRC protocol resembled P2P traffic!)
I've been using Telegram lately in a couple of contexts, and I agree that it's nice to have a less formal forum for socializing. I'm not particularly advocating Telegram, but I think you're right that similar systems have a place in the universe of communication channels. We've tended to use it for keeping in touch at sprints ("Hey, meet in the lobby at 7pm if you want to join us for dinner") and sending interesting little pictures, quotes, etc. The off-line and real-time notifications are the key things that make this useful, but the multiple ways to interact with the system (smartphone apps, web sites) are really useful too.
I just downloaded Telegram and my main concern with it is that it requires a phone number to get started. I ended up not signing up. For me this would be a disqualifier, especially with solid tools like Slack already available and in wide use.
Clearly we don't want major decisions happening here, but then I'd argue that IRC isn't the right place for that either. I am mildly uncomfortable with using closed systems and source, but given that Telegram and similar systems are used primarily for socializing, I think it's fine.
I prefer IRC for more real-time technical discussions because I have better ways of interfacing with it while "on the clock". E.g. I can much more easily cut-n-paste URLs, code snippets, tracebacks, etc. into an IRC client, and it's trivial for me to click on URLs to view pastebins, bug tracker issues, merge requests, etc. IRC does have the problem of overlapping discussions, so the lack of topic differentiation is real, although that can sometimes be mitigated by private chat or opening a new channel.
I've not used Telegram, but I don't find any of these things to be an issue with Slack. I see people posting URLs, code snippets, etc. using pastebin and co. all the time. Slack for me is basically IRC + group channel browsing + ability to catch up on offline messages, basically IRC++. :)
I don't think any one forum is going to serve all our needs. Perhaps it's useful to identify the types of communications we want to encourage, and the features that promote those types of communication, then survey our options (both existing and near-term) to see what technology can best promote those types of communication.
+1 to this! :) Thanks, Kevin
Some examples:
- Socializing: off-topic; anything goes; jokes; fun Python sightings; meetups
- Real-time technical discussion: remote pair programming; live debugging; hashing out alternative solutions; what does this code do?; real-time reviews
- Asynchronous focused discussions: issue tracking; PEP writing; feature development
- Asynchronous unfocused discussions: brainstorming; anybody else have this problem?; wild ideas; this is probably stupid but...
- Asynchronous decision making: are we missing anything?; any other opinions before we decide?; wide as possible participation so no one feels left out or unheard from; pronouncements and closure.
Cheers, -Barry _______________________________________________ Overload-sig mailing list Overload-sig@python.org https://mail.python.org/mailman/listinfo/overload-sig
On Jun 21, 2016, at 12:02 PM, Guido van Rossum wrote:
I think we should definitely be seeing what we can do to improve the mailing list experience. :) I've not worked with Mailman 3 myself yet but it sounds like 3.0 is a pretty significant improvement. I was pretty curious about Posterious particularly, although I didn't manage to find an example of it online. Is there a good example to look at?
I'm too overloaded to read all of overload-sig right now, but I just wanted to quickly mention a few things re: MM3. You can see several live examples: https://lists.fedoraproject.org/archives/ https://lists.mailman3.org/archives/ The Fedora lists are probably the most extensive; they have fully ported all their old MM2 lists to the new software. We have just a few lists on the mailman3.org site (hosted on python.org infrastructure). Mark Sapiro has been working on putting some MM3 lists on python.org but there are a few Postfix issues to work out when hosting MM2 and MM3 on the same domain. Two things about MM3 that I think can significantly improve engagement with mailing lists. First, you don't have to actually be subscribed to post to a list. Hyperkitty (the archiver) has a way to post replies which show up on the list. So if you land on an interesting message via search, you can jump into the conversation right away. Second, but longer term, is porting the Systers dlist (dynamic lists) feature to MM3. At a high level, think of it as nosy-for-mailing-lists. One of the things I love about Roundup is the ability to easily nosy myself in to any issue I care about and ignore everything else. dlists allow you to do the same thing and Systers has been using an MM2 implementation of it for many years. This is farther off because we do need some resources to get the feature fully ported and landed, but this will be much much better than the topic system in MM2, which has proved too cumbersome to see widespread adoption. What I like about the combination of these two features is that you can use the medium that suits your level of interest best, which of course can be fluid. You get the best of forums and mailing lists, and can use either or both as your needs change. Cheers, -Barry
Barry Warsaw writes:
Second, but longer term, is porting the Systers dlist (dynamic lists) feature to MM3. [...] This is farther off because we do need some resources to get the feature fully ported and landed, but this will be much much better than the topic system in MM2, which has proved too cumbersome to see widespread adoption.
I can testify that the system has worked effectively for Systers for years. Due to their nature as a support group as much as (or more than) a development organization, in the last year a lot of the conversations have moved to Slack, and this has improved the engagement of Systers GSoC students, but as Guido has suggested, it is clearly inferior as a channel for discussing design and coding issues IME. BTW, "longer term" is much nearer than "Real Soon Now." We do have a core developer interested in the port. Steve
participants (6)
-
Barry Warsaw -
Brett Cannon -
Guido van Rossum -
Kevin Ollivier -
Skip Montanaro -
Stephen J. Turnbull