[Overload-sig] Issue tracker vs. real-time chat

Kevin Ollivier kevin-lists at theolliviers.com
Thu Jun 23 13:26:11 EDT 2016


Hi Barry,



On 6/23/16, 6:49 AM, "Overload-sig on behalf of Barry Warsaw" <overload-sig-bounces+kevin-lists=theolliviers.com at python.org on behalf of barry at 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 at python.org
>https://mail.python.org/mailman/listinfo/overload-sig



More information about the Overload-sig mailing list