On Fri, Jun 10, 2016 at 8:22 AM, Jason R. Coombs <jaraco@jaraco.com> wrote:
> In #pypa-dev, I raised the possibility of moving our PyPA support channels from IRC to another hosted solution that enables persistence. Although IRC has served us well, there are systems now with clear feature advantages, which are crucial to my continuous participation:
I'm choosing not to read this as a threat.
I don't think it was a threat to begin with. For it to be a threat it would somehow need to affect you personally. I think all Jason was trying to do was to point out this is not some idle conversation to him, but in fact impacts how he participates in communications regarding setuptools and PyPA.
> - always-on experience; even if one’s device is suspended or otherwise offline.
> - mobile support — the in-cloud experience is essential for low power and intermittently connected devices.
> - push notifications allow a project leader to remain largely inactive in a channel, but attention raised promptly when users make a relevant mention.
> - continuous, integrated logging for catching up on the conversation.
So here's a question: Why are these crucial to you? You've explained
potential benefits but not why they're crucial to you and should be
crucial to anyone else.
Why do you need an "always-on experience"? Why do you feel required to
always be on? Do other people tell you that you need to always be on
chat?
Push notifications allow for prompt attention to mentions, but are all
mentions push notification worthy? Do we all need to be herded to
platforms that will spam us because someone mentioned us by nick or
name? I personally see this as a net negative. I don't need an email
or push notification to my phone because someone said my name in a
channel. That's a distraction. It prevents me from working on things
because it creates a false sense of alarm.
I think there's a difference between getting a push notification that rings your phone and one that simply sits in your notification bar. For the former that could get annoying if abused, but for the latter it could be handy if e.g. you are working on a bug and you happen to know that Jason could help speed things up for you by answering a question if he happens to be available. To me there's three levels of engagement: (1) I'm willing to be interrupted, (2) if I'm available I'll notice, else I will ignore it, and (3) just collect all the messages and I will check the next time I explicitly log in. You solve (1) by simply being logged into IRC all the time, but I don't know how to get (2) or (3) to work in IRC w/o setting up something like a reflector or something fancy (#3 can be covered by email, and maybe #2 with the right setup).
Continuous logging is on for #pypa and #pypa-dev as I understand it.
Surely it's not "integrated" into your chat client, but it's not as if
the logging doesn't exist.
For me the constant connection allows for collecting mentions into a single notification area (#3 in the engagement level list I mentioned above). I personally have 4 devices I connect to the internet with and none of them short of my phone is on constantly. With some kind of constant connection I could then have all of the mentions I have not seen collected into a single place so I could address them no matter what device I choose to check in with. Otherwise I have to restrict myself to only using a device which has an IRC client that can reconcile where I left off and pick up on all the messages that mentioned me since I last logged in.
And as for mobile access, that's just a matter of occasional convenience. I don't think that messaging all the time from my mobile phone is the best option, but it is one that I can do while e.g. sitting on the bus on the way to work so that I can spend my time at home doing other things potentially.
> Both Gitter and Slack offer the experience I’m after, with Gitter feeling like a better fit for open-source projects (or groups of them).
I've tried using Gitter several times in the past. Unless they've
fixed their bugs related to sending me emails every day about activity
in a channel I spoke in once and left, I think they should be
eliminated.
Slack has also had several outages lately that should also disqualify
it (besides the fact that it's incredibly closed source and will be
expensive to maintain logs in).
> I’ve tried using IRCCloud, and it provides a similar, suitable experience on the same IRC infrastructure, with one big difference. While Gitter and Slack offer the above features for free, IRCCloud requires a $5/user/month subscription (otherwise, connections are dropped after two hours). I did reach out to them to see if they could offer some professional consideration for contributors, but I haven’t heard from them. Furthermore, IRCCloud requires an additional account on top of the account required for Freenode.
>
> In addition to the critical features above, Gitter and Slack offer other advantages:
>
> - For Gitter, single-sign on using the same Github account for authentication and authorization means no extra accounts. Slack requires one new account.
IRC requires one new account.
> - An elegant web-based interface as a first-class feature, a lower barrier of entry for users.
webchat.freenode.net may not be elegant, but it is first-class.
Does it track where you left off since you last logged in? I just tried it and it didn't look sophisticated enough to.
> - Zero-install or config.
Slack pesters you to install their desktop client and if you don't
want constant channel notifications you do have to configure it.
webchat.freenode.net offers no config.
> - Integration with source code and other systems.
Do you mean things like GitHub? GitHub already integrates with IRC.
What special kind of integration are do you think Gitter and Slack
have that GitHub's IRC integration doesn't?
> It’s because of the limitations of these systems that I find myself rarely in IRC, only joining when I have a specific issue, even though I’d like to be permanently present.
>
> Donald has offered to run an IRC bouncer for me, but such a bouncer is only a half-solution, not providing the push notifications, mobile apps (IRC apps exist, but just get disconnected, and often fail to connect on mobile provider networks), or integrated logging.
>
> I note that both Gitter and Slack offer IRC interfaces, so those users who prefer their IRC workflow can continue to use that if they so choose.
They're very poor IRC interfaces, making people who want to use a
simple, free, standard second class citizens (which is par for the
course as far as open source projects go).
> I know there are other alternatives, like self-hosted solutions, but I’d like to avoid adding the burden of administering such a system. If someone wanted to take on that role, I’d be open to that alternative.
>
> I’d like to propose we move #pypa-dev to /pypa/dev and #pypa to /pypa/support in gitter.
>
> Personally, the downsides to moving to Gitter (other than enacting the move itself) seem negligible. What do you think? What downsides am I missing?
With IRC we can run our own logging solution. Gitter used to have a
similar model to Slack where you had to pay to access all of the logs.
Further, to allow anyone to use Slack, we have to set up and maintain
a separate webapp (which can be deployed to Heroku, but for the kind
of traffic we would expect, would actively cost us money to run
there).
I think the key point in that paragraph is "your own". At least in my case (and probably in Jason's), I don't want to run my own logging solution that I have to keep up and running. I too considered irccloud but also balked at having to spend $5/month in order to be more engaged with IRC.
I'm afraid that for real-time chat there's no good solution. For random tech support, just popping into #pypa is good enough if you happen to think about it. But for real-time discussion w/ fellow developers when you need to hash something out, it will simply require scheduling ahead of time when to either be on IRC or use something like Hangouts like various other chats spawning from distutils-sig discussions have done (or use WebRTC solutions).
Personally I would rather give Discourse a try.