I would love to see this, and I would love it if I didn't have to do
anything about it myself except joining the service when it's ready
(preferably without having to create a new account :-).
On Sat, Mar 31, 2018 at 9:25 PM, Nick Coghlan
I've also got confirmation from Tim Abbott (ZulipChat cofounder) that
On 31 March 2018 at 06:23, Guido van Rossum
wrote: they'd be happy to host us and would even prioritize features they want.
Cool - I've mainly been exposed to the Zulip community via Sumana (who's handling project management for the Warehouse migration), and if she's any indication, I think they'd be a wonderful group for us to collaborate with :)
If we were to set up a python-dev stream, then service integrations I think we'd be interested in:
* GitHub (naturally) * Roundup (potentially based on the existing IRC bot) * BuildBot (potentially based on the existing IRC bot)
(Something worth noting is that the way that chat.zulip.org has their own commit monitoring set up is to have a dedicated top level "commits" stream, and then separate topics within that stream for different repos. I suspect that approach could also work pretty well for python.org, rather than necessarily putting everything inline in the dev discussion stream the way we do on IRC)
I expect we'd also want to eventually set up an IRC bridge with python-dev, as otherwise folks joining the Zulip python-dev stream might not find existing contributors to chat to. (While I no longer idle on IRC during the work day the way I used to when I was working for Red Hat, it's still the default real-time option I'd reach for if I was having an extended back-and-forth with someone on the issue tracker). Mentioning that also provides a chance to highlight Zulip's stream/topic links: https://chat.zulip.org/#narrow/stream/127-integrations/topic/IRC.20mirror :)
Anyway, +1 for me for running an experiment - the UX issues with IRC are non-trivial (and some of them, like the now-unusual way it manages user identities, are inherent to the platform), and Zulip avoids all of the red flags that can make me nervous about introducing new tools:
- there's a hosted service available, so it doesn't depend on volunteers managing infrastructure - the hosted service is bootstrapped rather than VC-funded, so the business model doesn't demand exponential growth - the underlying project is open source, so folks can pitch in and help out if they're so inclined - the data being managed isn't anything where we're concerned about long term preservation (the way we are for code commits, tracker issues, PEPs, and email design discussions)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- --Guido van Rossum (python.org/~guido)