IRC vs Slack vs Discord vs Gitter
Hi, Nowadays, joining to IRC is a hurdle for new contributors. There are some alternative, modern web applications: * Slack -- Most used for tech communities. * Discord -- Similar to slack. It is focusing game, but support OSS too. [1] * Gitter -- Most integrated with Github. typing, mypy, pip use it already. [1] https://discordapp.com/open-source I know adding communication channel is not good always. (We couldn't keep https://discuss.python.org/) But I think IRC is really high hurdle for young people. How about trying one of them? (maybe, gitter?) Regards, -- INADA Naoki <songofacandy@gmail.com>
On 30 March 2018 at 20:27, INADA Naoki <songofacandy@gmail.com> wrote:
While pip does have a room on Gitter, I'm not sure how active it actually is. Another option well worth considering here is Zulip: https://zulipchat.com/for/open-source/ While the original startup got acquihired by Dropbox back in 2014, a new supporting startup was formed in mid-2016 (https://zulipchat.com/team/) after some successful community engagement efforts at the PyCon US sprints (https://zulipchat.com/history/) One challenge to be overcome is that these rooms are really only useful to newcomers if they can find existing contributors there, and for existing contributors, the newer services don't tend to offer any especially compelling advantages over IRC, which makes it hard to successfully convince folks to change how they make themselves available for real time discussions. IRC gateways tend not be an especially compelling feature from a commercial perspective (e.g. Slack are shutting their IRC bridge down [1]), but Zulip do offer scripts that support bidirectional mirroring of messages, and are interested in improving that capability: https://github.com/zulip/python-zulip-api/issues/106 Independently of the idea of a more modern real-time chat service, I'll note that IRC web gateways do provide some potential for near term mitigation, and we do link to https://webchat.freenode.net/ from https://devguide.python.org/communication/#irc. However, the link is pretty terse, and the login form presents an IRC-centric view of the world which is quite different from what most folks will have come to expect from a web service. The sign-up process for IRCCloud might be a bit more familiar to folks, and offers the advantage that we could link directly to the python-dev channel with an ordinary HTTPS URL: https://www.irccloud.com/irc/freenode/channel/python-dev (I haven't checked the full sign-up flow with the direct link, so that may still be a bit convoluted, but once you do have an account, the link takes you directly to the channel after you log in). Cheers, Nick. [1] https://pythondev.slack.com/account/gateways -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 03/30, Nick Coghlan wrote:
Pros: * We can easily create BOTs for #python-dev * We can share links/images, snippets of codes * We can send invitations (private channels) * Available in a Web Interface, Electron, Android, iOS, Linux, Windows and OSX * You can search for a message from one person * You can see the list of the attachments (images, etc...) Cons: * We can't have a history over 10000 messages excepted if we pay. * When you have a lot of history and you load the application, this one will consume a lot of memory. * Consumer of memory (not benchmarked by myself, and I have no checks about that)
* Discord -- Similar to slack. It is focusing game, but support OSS too. [1] Never used it, maybe it's a good candidate.
But for my part, I use IRC for 20 years and I like it, because it's just simple, I need a console and weechat or irssi, just that. I have my history in a text file by channel, I can discuss with a group or just with one person. The interface is just simple (ncurses) and don't load a lot of memory just for some messages. and I can search in my history for a link... I know it's just a very basic tool but for me, it's enough. Maybe a web interface could me more useful for the newcomers. Cheers, Stéphane
-- Stéphane Wirtel - http://wirtel.be - @matrixise
On Fri, Mar 30, 2018 at 6:01 AM, Stephane Wirtel <stephane@wirtel.be> wrote:
But for my part, I use IRC for 20 years and I like it, because it's just simple, I need a console and weechat or irssi, just that.
Stephane, Nick, and Guido, There is a sample instance of Zulip running at https://chat.zulip.org You can log into that with your Google credentials, GitHub credentials, or you can sign up for an account on that site. That site is what the Zulip project uses for their own communication. If you log into that and test drive it a bit, do you think you would be able to live with it? I realize that everyone has their preferences and tools that they are used to over the years, but it is important to get some basic, "I could live with it" feedback from experienced Python devs. -- Craig
I would, at least initially, advise against Slack. I constantly hear people decry its growing use in open source communities for a mix of two reasons. The first seems to come from strong IRC proponents, with the general complaint of "it's not open," and getting into the whole "your data is not your data" idea, especially with recent changes to Slack with regards to privacy. The second seems to come from the inability to really get away from Slack. Their notification system is pretty rudimentary, in that there's not much fine tuning to be done and most people I've talked with are either overloaded with things to care about or mute everything and only manually check channels. There's an additional problem in that you can never fully be away from Slack. Their "Do Not Disturb" settings can't stretch for more than 24 hours (something they do not appear eager to change as they're asked about this quite often), so you need to go out of your way to do something about the weekend to get some time away from work. However, I'm not really familiar with the initial problem of people joining IRC. Rather, one I'm familiar with regards to IRC is the problem of replicating things like Slack—or at least the ability to receive messages while offline—such as using/buying/hosting an IRC bouncer. Can you speak more about what brought you to propose a change here? I wonder if this is something we can just solve while continuing to use IRC? On Fri, Mar 30, 2018 at 6:27 AM, INADA Naoki <songofacandy@gmail.com> wrote:
Speaking to my own experience, I have never gotten involved in IRC because I don't want to have pay for a reflector to know who mentioned me, I don't want to maintain a server just to have a reflector for free, and I don't want or have a PC to leave on 24/7 to simply stay connected. I personally wouldn't want to switch to Slack because I don't think it handles large communities that well. The Dropbox-led projects are on gitter I think because they lack mailing lists -- on purpose -- and some things don't call for a GitHub issue (which is their preferred way to communicate). The last time I looked into this idea the conclusion I reached was Zulip or Discourse. I do worry about the accessibility of IRC for new people, but I also have the same worry about email as more of people's personal communication move away from it and thus people just aren't set up handle any sort of volume of email. Consider the fact that a standard answer to a lack of email threading on any of the major email providers is to use gmane's NNTP gateway. I don't think people realize that anyone who post-dates the '90s has no clue what that acronym represents and thus poses the same barriers as setting up IRC. And then asking folks to install a desktop app like Thunderbird just for their open source email is also an odd request to be making when there are web-based options. So for me, the first question is are we just considering alternatives to the "IRC problem" or are we trying to solve the "new contributors who were born in the 2000s problem" (for which the latter subsumes the former)? My guess is the former as tackling the latter is a major undertaking due to people who will only let go of email when they are dead. And in that instance my vote is for Zulip if we can get them to donate free hosting. On Fri, Mar 30, 2018, 06:36 Brian Curtin, <brian@python.org> wrote:
On Fri, Mar 30, 2018 at 9:25 AM, Brett Cannon <brett@python.org> wrote:
It seems that Zulip offers free hosting: "Do you have special plans for open source projects, non-profits, groups of friends, and other non-commercial entities? Yes! Zulip Cloud Premium is free for open source projects and a wide variety of non-commercial entities. We also often offer steep discounts to educational institutions, and in other scenarios where users are not being paid a salary. Just contact sales@zulipchat.com and we'd be happy to discuss your situation! You may also be interested in Zulip for open source projects or Zulip for working groups and other part-time communities." [1] [1] https://zulipchat.com/plans/
I've also got confirmation from Tim Abbott (ZulipChat cofounder) that they'd be happy to host us and would even prioritize features they want. Who's interested in making this happen?We should start with an experiment, and it would be good to create a plan for evaluating success. If you want to help out, please volunteer to write up such a plan -- implementation will be easy. On Fri, Mar 30, 2018 at 11:44 AM, Aaron Ang <awz.ang@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Why don't you try to write a short document with a proposal -- hopefully it'll be pretty straightforward. You can email Tim Abbott ( tabbott@zulipchat.com) if you're stuck on details. On Fri, Mar 30, 2018 at 1:37 PM, Aaron Ang <awz.ang@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On Fri, Mar 30, 2018 at 1:23 PM, Guido van Rossum <guido@python.org> wrote:
Here are some points I jotted down. If someone is interested in this, maybe these points can be incorporated into a full fledge plan: PREDEPLOYMENT QUESTIONS AND RESEARCH ==================================== 1. SETUP ======== - talk to Tim Abbot <tabbott@zulipchat.com> and confirm the details about what Zulip can offer the Python project in terms of a hosted Zulip chat service - decide on the type of logins/auth that will be allowed for this service -> GitHub oauth? -> Google oauth? -> chat service specific account? -> other? - should there be a DNS name for this for easy eaccess: chat.python.org ? 2. ADMIN ======== -> identify points of contact for Zulip, i.e. who gets contacted if something goes wrong? -> should the existing Python Software Foundation infrastructure team be involved in the admin of this system? -> does Code of Conduct apply to users of chat system? Should this be advertised somehow when users -> what types of channels/rooms should be created? who is responsible for creating these channels? 3. INTEGRATIONS ================ - read up on Zulip Integrations ( https://zulipchat.com/integrations/ ) and Bots ( https://zulipchat.com/api/running-bots ) - identify systems that can be integrated with Zulip: -> GitHub (out of the box integration is available) -> Roundup (not available, needs to be written) -> Buildbot (not available, needs to be written) -> other ? 4. WEBSITE ========== - where on the Python.org website should information be made available for logging into the chat system? DEPLOYMENT PLAN =============== 0. EVALUATION ============= 1. Have key stakeholders test drive https://chat.zulip.org , and make sure they are OK with it, before proceeding to rollout. 1. PHASE 1 - initial rollout ============================ 1. Decide on the auth/login policy for the chat system 2. Get Zulip to set up the system and make it available 3. Have a few people in the core-workflow team test drive the system for 1 week 4. If it is people in 3. are happy with it, proceed to next steps, otherwise stop. 5. Write up some information on the website which points people to the chat system. 6. Send out announcements (e-mail, website, blog, twitter, etc.) about availability of chat site 2. PHASE 2 - post rollout ========================= 1. Look at what out of the box integrations can be set up quickly (GitHub) and set them up 2. Write any additional integrations for things that are not available (Roundup, Buildbot)
Thanks for the writeup Craig! My comments:
I'll be happy as long as these two auths are supported. - should there be a DNS name for this for easy eaccess: chat.python.org
?
Maybe in the second phase (after the trial phase) -> identify points of contact for Zulip, i.e. who gets contacted if
something goes wrong?
I'd like at least several core devs to get involved as admins. -> should the existing Python Software Foundation infrastructure team be involved in the admin of this system? I think they should be involved, with setting up zulip and as admins. -> does Code of Conduct apply to users of chat system? Should this be
advertised somehow
The PSF's CoC will apply. If it's up to me, I'll have a bot set up that greets every new members with explicit reminder that the CoC applies there. -> what types of channels/rooms should be created? who is responsible
for creating these channels?
To start just a python-dev room? admins can create new channels. - identify systems that can be integrated with Zulip: -> GitHub (out of the box integration is available) That's perhaps the important one right now (IMO). The next I'll probably use myself is Zapier integration :) Future integrations can be proposed at later time. Related question: - can anyone add/enable their own integration between zulip and something else? or only the admins? - where on the Python.org website should information be made available
for logging into the chat system?
Start with the devguide. We might want to update https://www.python.org/community/irc/. It can be requested by opening an issue at https://github.com/python/pythondotorg. But let's not do that yet until after the trial phase. Mariatta ᐧ
On Sat, 31 Mar 2018 at 12:51 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Since I assume we will be going with zulipchat.com hosting, there shouldn't be much set up beyond choosing initial settings, but someone from the infrastructure team should have admin rights to make sure there are enough people with admin access should something arise.
Yep, the CoC will automatically apply as it does to all infrastructure involving Python. And I vaguely remember there being a setting to specify what shows up when people sign up so this should be doable.
Using Zulip parlance, we would set up streams for what we have mailing lists for. To start, I would say we set up a stream for core-workflow and go from there as desired/requested. (And if this is successful we could potentially hand https://github.com/python/core-workflow/issues over to the actual tools for core development instead of being a catch-all place for ideas that others don't use heavily).
There's also a Travis integration.
You might be able to add your own. If you play with chat.zulip.org it seems to suggest you can set up your own bot if you want. Instructions on writing new integrations can be found at https://zulipchat.com/api/integration-guide
Yes, we haven't even agreed to doing a trial phase, so worrying about full-fledge roll-out isn't quite necessary yet. :) At this point we just need to figure out if we want to do this, why we want to do this, then we can worry about the how of flipping this on to test it out (i.e. the proposal doc). -Brett
Brett Cannon wrote:
Yep, that's right. We use this on chat.zulip.org to link to our own Code of Conduct, so you can check out what this looks like there.
That sounds like a good plan to me. Anyone in a Zulip org can create a stream; that's an option the org admins can change, but it's what I'd recommend for Python. So it's easy to let this evolve organically from there. For ideas on what a fully-fledged state might look like, there's some good discussion about streams here: https://zulipchat.com/help/getting-your-organization-started-with-zulip and in a couple of articles it links to. Craig Rodrigues wrote:
-> GitHub (out of the box integration is available)
Mariatta Wijaya wrote:
The next I'll probably use myself is Zapier integration :)
Brett Cannon wrote:
There's also a Travis integration.
Yep! Brett Cannon wrote:
Instructions on writing new integrations can be found at https://zulipchat.com/api/integration-guide
Yep! I'd add that we've put a fair bit of work and thought into making a great API for writing new integrations. I think we've been pretty successful at making it easy to do so, and the 90+ integrations we have built-in demonstrate that. Greg
Hello! Speaking as another member of the Zulip core team, I can answer right here some questions from this thread. First off, I'll say that I'm very happy to see this discussion, and repeat that we would be very happy to provide hosting. :)
The hosted service we'd offer out of the box is what we call Zulip Cloud Premium, as described here (except we'd provide it for free): https://zulipchat.com/plans/ For more about how Zulip works and why we like it, you can read these: https://zulipchat.com/why-zulip/ https://zulipchat.com/for/open-source/ To set up a Zulip community, someone can follow any of the "sign up" buttons to go to https://zulipchat.com/new/ and create a Zulip organization at a URL like python.zulipchat.com. Then let us know and we'll mark that organization to get Zulip Cloud Premium for free permanently. (We can also give it a custom domain like chat.python.org later.)
Out of the box, we support all three of the ideas above on zulipchat.com: GitHub OAuth, Google OAuth, and users can sign up with an email and password.
- should there be a DNS name for this for easy eaccess: chat.python.org ?
We're happy to do this while hosting on the zulipchat.com cloud service; we've done it for others before. No rush; we can move it to such a name later.
The usual point of contact is support@zulipchat.com; several of us monitor that and we're quite responsive there. For most things that's best. Folks can also contact me personally or, as mentioned upthread, Tim Abbott. We're in the Zulip organization for Zulip's own development community, at https://chat.zulip.org/ (which is of course open for anyone to join); once an open Zulip org for the Python project is set up, I'll certainly be present there too.
This part is easy :) -- whoever wants to do this can just go to https://zulipchat.com/new and create a new org. It's self-serve.
3. Have a few people in the core-workflow team test drive the system for 1 week
I'd suggest one addition to this: have at least one experienced Zulip user (probably me and/or Tim) participate in this step as well. Like many forms of online communication, there's a lot of habits and norms of usage for making everything smooth that you pick up naturally when you join an established community, but aren't as obvious when everyone is new to the system at the same time. Happy to answer other questions! Greg
On Sun, 1 Apr 2018 at 01:09 Greg Price <greg@zulipchat.com> wrote:
To prevent anyone from squatting on the name I just tried to register for python.zulipchat.com but was told that subdomain is not available (although python.zulipchat.com says there's no organization). :( -Brett
On Sun, 1 Apr 2018 at 10:28 Brett Cannon <brett@python.org> wrote:
I have gone ahead and registered python-lang.zulipchat.com (although nothing is set up yet since April Fools is my annual "stay off the internet" day plus I try to do no open source on Sundays and I would like to try and adhere to that :) . I will start configuring things probably tomorrow and will open things up to the community once I have gone through and tweaked all the settings (although it sounds like Greg is promoting leaving everything very open and going with the defaults, from stream creation to bot integration? Is that right, Greg?). IOW don't bother trying to use this yet as it's not publicly accessible ATM. Now if someone here actually registered python.zulipchat.com and simply didn't mention that then I'm happy to switch to that name and delete the organization I just created (although if we eventually put this behind a *. python.org subdomain I guess it doesn't really matter too much). Those that want to be admins can email me privately and I will add you to the organization (I will be restricting this to folks I know I can personally trust since admins can delete and ban people, so apologies in advance if I don't know you but you wanted to get involved at the admin-level).
Taking a look, it turns out we've had "python" in a list of subdomains that are reserved so nobody can register them through the signup form. The comment in the source suggests the idea was that we might put a blog at that URL someday. This seems like a still better use of the name, though. :-) I've just gone and renamed the org that was at python-lang.zulipchat.com to be at python.zulipchat.com. Brett, would you confirm you can log in there now and everything seems in order? Greg On Mon, Apr 2, 2018 at 9:51 AM, Brett Cannon <brett@python.org> wrote:
Just a quick update: I have https://github.com/python/cpython/pull/6379 to add a webhook for Travis failures, but after that I think all of the key things for an initial opening of this for Python development is ready (I am currently not scoping this for the whole Python community, so no general help stream). My hope is to announce the opening up of the instance here on Friday. If this experiment goes well we can then discuss announcing this on python-dev and making this a permanent thing. I'm also still looking for more volunteer admins (there are currently only two of us). On Mon, 2 Apr 2018 at 11:20 Greg Price <greg@zulipchat.com> wrote:
Yep! One reference you might find handy is the settings we have on the Zulip community's own Zulip org at chat.zulip.org, just because that's a pretty busy open-source community that we've kept running well for a couple of years. In general the organization settings are visible to any user (just read-only), so if you make an account there you can consult them through the same interface as you'll use to set them on python.zulipchat.com. Both those settings we've kept quite open. Greg On Sun, Apr 1, 2018 at 11:08 AM, Brett Cannon <brett@python.org> wrote:
On 31 March 2018 at 06:23, Guido van Rossum <guido@python.org> wrote:
I've also got confirmation from Tim Abbott (ZulipChat cofounder) that 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
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 <ncoghlan@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
Zulip really does seem like a great option, so I'm all for giving it a go. I just downloaded the macOS client and tried to connect, but apparently the Python channel requires approval to join. Maybe I'm just jumping the gun, but please let python-dev and/or -committers know when it's read for play! -Barry
On Thu, Apr 5, 2018 at 6:56 PM, Brett Cannon <brett@python.org> wrote:
Brett, Thanks for setting up python.zulipchat.com. While signing up for Zulipchat, I read through the terms of service at: https://zulipchat.com/terms/ I just wanted to confirm, are those terms of service compatible with PSF policies in terms of: - privacy of data, https://zulipchat.com/privacy/ , vs. Python.org's policy at: https://www.python.org/privacy/ - age restriction (zulipchat can only be used by age >= 13) - export compliance with respect to residents of Cuba, Iran, North Korea, or Syria - anything else Personally, I am not affected by these policies, since I am a U.S. citizen, resident in the U.S., and over 13 years old. I am not an expert in these topics, but just wanted to confirm that this is compatible with Python.org's policy, since Python is an open project with contributors who live in different countries around the world, and have different backgrounds, ages, etc. Thanks. -- Craig
On Fri, 6 Apr 2018 at 20:59 Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Since this is an experiment I'm fine with the current situation (the admins are also not planning on actively policing users over any of that either), but if someone feels strongly about this and wants to start a dialogue with the PSF board right now they can. And if it does become a problem and we want to keep using Zulip we can then stand up our own instance without those restrictions (assuming we even can; IANAL so I don't know how many of those requirements are required for any and all services hosted in the US or by a US organization).
On Fri, 30 Mar 2018 16:25:34 +0000 Brett Cannon <brett@python.org> wrote:
Consider the fact that a standard answer to a lack of email threading on any of the major email providers is to use gmane's NNTP gateway.
The main problem with gmane is that it isn't really maintained anymore. In particular you can't register new mailing-lists to the gateway :-(
I don't think people realize that anyone who post-dates the '90s has no clue what that acronym represents and thus poses the same barriers as setting up IRC.
I'm curious about "barriers". You just have to set up a piece of software... Python requires some kind of text editor or IDE to become productive. Is it a barrier to have to set up a text editor?
Well... I think the main question is whether IRC is important at all. I'd be willing to guess that most of our contributors don't use IRC on a regular basis, and they're not missing on anything. Which isn't a reason not to improve things, but makes it quite low-priority IMHO. Regards Antoine.
On Sat, Mar 31, 2018, 02:42 Antoine Pitrou, <solipsis@pitrou.net> wrote:
I don't want to dwell on this too much since I think we've collectively agreed to focus on the real-time collaboration case. But to answer the question, any piece of software we basically ask people to set up to be productive is a barrier. In North America there's is the phrase "death by a thousand paper cuts" and asking people to install yet more software and do more to get set up does have a cost where people have a personal limit how how many little things they are willing to put up with. As for this specific case, as a developer there is a much greater chance I will install an editor for all of my development needs while installing an email client has a higher chance tonne just for this specific case if people in school these days aren't heavy email users. -Brett
Missing out? No. Would like to occasionally have real-time collaboration? Yes, at least for me (I mean I could give every core dev my number toessage me on Signal or WhatsApp, but I don't think that scales 😉). Which isn't a
reason not to improve things, but makes it quite low-priority IMHO.
Yes, this isn't critical, hence why I don't think anyone has tried to do anything beyond discussing it so far. We will have to wait and see if anyone writes up a proposal as to why we should consider the overhead of asking people to sign up for Zulip and give it a try. -Brett
On 2 April 2018 at 18:55, francismb <francismb@email.de> wrote:
That's certainly the way corporate development environments are heading with projects like Eclipse Che (the tech behind codenvy.com), and AWS Cloud9. This post from Zapier engineering covers those two, as well as one I hadn't heard of before, CodeAnywhere: https://zapier.com/engineering/best-cloud-ides/ The main challenge with covering an approach like that in the dev guide is that none of the current core developers work that way, so we'd have a hard time providing good support to any newcomers that decided to take it up. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On March 30, 2018 5:35:13 AM INADA Naoki <songofacandy@gmail.com> wrote: Hi, Nowadays, joining to IRC is a hurdle for new contributors. There are some alternative, modern web applications: * Slack -- Most used for tech communities. One con other than the 10k limit is the weird fact that you essentially need a different account for each room you join. * Discord -- Similar to slack. It is focusing game, but support OSS too. [1] Discord is genuinely awesome. You can do pretty much everything for free, and it handles huge servers quite well. * Gitter -- Most integrated with Github. typing, mypy, pip use it already. AFAIK there are two main negatives to Gitter: - Only one "channel" per GitHub repo. Compare that to Slack or Gitter, where you can have multiple channels on one server. - Sorry, but the mobile app is largely garbage. It doesn't even handle links correctly, and it's particularly bad compared to the amazing Discord app. [1] https://discordapp.com/open-source I know adding communication channel is not good always. (We couldn't keep https://discuss.python.org/) But I think IRC is really high hurdle for young people. How about trying one of them? (maybe, gitter?) Regards, -- INADA Naoki <songofacandy@gmail.com> _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ Sent with AquaMail for Android https://www.mobisystems.com/aqua-mail
On 30 March 2018 at 20:27, INADA Naoki <songofacandy@gmail.com> wrote:
While pip does have a room on Gitter, I'm not sure how active it actually is. Another option well worth considering here is Zulip: https://zulipchat.com/for/open-source/ While the original startup got acquihired by Dropbox back in 2014, a new supporting startup was formed in mid-2016 (https://zulipchat.com/team/) after some successful community engagement efforts at the PyCon US sprints (https://zulipchat.com/history/) One challenge to be overcome is that these rooms are really only useful to newcomers if they can find existing contributors there, and for existing contributors, the newer services don't tend to offer any especially compelling advantages over IRC, which makes it hard to successfully convince folks to change how they make themselves available for real time discussions. IRC gateways tend not be an especially compelling feature from a commercial perspective (e.g. Slack are shutting their IRC bridge down [1]), but Zulip do offer scripts that support bidirectional mirroring of messages, and are interested in improving that capability: https://github.com/zulip/python-zulip-api/issues/106 Independently of the idea of a more modern real-time chat service, I'll note that IRC web gateways do provide some potential for near term mitigation, and we do link to https://webchat.freenode.net/ from https://devguide.python.org/communication/#irc. However, the link is pretty terse, and the login form presents an IRC-centric view of the world which is quite different from what most folks will have come to expect from a web service. The sign-up process for IRCCloud might be a bit more familiar to folks, and offers the advantage that we could link directly to the python-dev channel with an ordinary HTTPS URL: https://www.irccloud.com/irc/freenode/channel/python-dev (I haven't checked the full sign-up flow with the direct link, so that may still be a bit convoluted, but once you do have an account, the link takes you directly to the channel after you log in). Cheers, Nick. [1] https://pythondev.slack.com/account/gateways -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 03/30, Nick Coghlan wrote:
Pros: * We can easily create BOTs for #python-dev * We can share links/images, snippets of codes * We can send invitations (private channels) * Available in a Web Interface, Electron, Android, iOS, Linux, Windows and OSX * You can search for a message from one person * You can see the list of the attachments (images, etc...) Cons: * We can't have a history over 10000 messages excepted if we pay. * When you have a lot of history and you load the application, this one will consume a lot of memory. * Consumer of memory (not benchmarked by myself, and I have no checks about that)
* Discord -- Similar to slack. It is focusing game, but support OSS too. [1] Never used it, maybe it's a good candidate.
But for my part, I use IRC for 20 years and I like it, because it's just simple, I need a console and weechat or irssi, just that. I have my history in a text file by channel, I can discuss with a group or just with one person. The interface is just simple (ncurses) and don't load a lot of memory just for some messages. and I can search in my history for a link... I know it's just a very basic tool but for me, it's enough. Maybe a web interface could me more useful for the newcomers. Cheers, Stéphane
-- Stéphane Wirtel - http://wirtel.be - @matrixise
On Fri, Mar 30, 2018 at 6:01 AM, Stephane Wirtel <stephane@wirtel.be> wrote:
But for my part, I use IRC for 20 years and I like it, because it's just simple, I need a console and weechat or irssi, just that.
Stephane, Nick, and Guido, There is a sample instance of Zulip running at https://chat.zulip.org You can log into that with your Google credentials, GitHub credentials, or you can sign up for an account on that site. That site is what the Zulip project uses for their own communication. If you log into that and test drive it a bit, do you think you would be able to live with it? I realize that everyone has their preferences and tools that they are used to over the years, but it is important to get some basic, "I could live with it" feedback from experienced Python devs. -- Craig
I would, at least initially, advise against Slack. I constantly hear people decry its growing use in open source communities for a mix of two reasons. The first seems to come from strong IRC proponents, with the general complaint of "it's not open," and getting into the whole "your data is not your data" idea, especially with recent changes to Slack with regards to privacy. The second seems to come from the inability to really get away from Slack. Their notification system is pretty rudimentary, in that there's not much fine tuning to be done and most people I've talked with are either overloaded with things to care about or mute everything and only manually check channels. There's an additional problem in that you can never fully be away from Slack. Their "Do Not Disturb" settings can't stretch for more than 24 hours (something they do not appear eager to change as they're asked about this quite often), so you need to go out of your way to do something about the weekend to get some time away from work. However, I'm not really familiar with the initial problem of people joining IRC. Rather, one I'm familiar with regards to IRC is the problem of replicating things like Slack—or at least the ability to receive messages while offline—such as using/buying/hosting an IRC bouncer. Can you speak more about what brought you to propose a change here? I wonder if this is something we can just solve while continuing to use IRC? On Fri, Mar 30, 2018 at 6:27 AM, INADA Naoki <songofacandy@gmail.com> wrote:
Speaking to my own experience, I have never gotten involved in IRC because I don't want to have pay for a reflector to know who mentioned me, I don't want to maintain a server just to have a reflector for free, and I don't want or have a PC to leave on 24/7 to simply stay connected. I personally wouldn't want to switch to Slack because I don't think it handles large communities that well. The Dropbox-led projects are on gitter I think because they lack mailing lists -- on purpose -- and some things don't call for a GitHub issue (which is their preferred way to communicate). The last time I looked into this idea the conclusion I reached was Zulip or Discourse. I do worry about the accessibility of IRC for new people, but I also have the same worry about email as more of people's personal communication move away from it and thus people just aren't set up handle any sort of volume of email. Consider the fact that a standard answer to a lack of email threading on any of the major email providers is to use gmane's NNTP gateway. I don't think people realize that anyone who post-dates the '90s has no clue what that acronym represents and thus poses the same barriers as setting up IRC. And then asking folks to install a desktop app like Thunderbird just for their open source email is also an odd request to be making when there are web-based options. So for me, the first question is are we just considering alternatives to the "IRC problem" or are we trying to solve the "new contributors who were born in the 2000s problem" (for which the latter subsumes the former)? My guess is the former as tackling the latter is a major undertaking due to people who will only let go of email when they are dead. And in that instance my vote is for Zulip if we can get them to donate free hosting. On Fri, Mar 30, 2018, 06:36 Brian Curtin, <brian@python.org> wrote:
On Fri, Mar 30, 2018 at 9:25 AM, Brett Cannon <brett@python.org> wrote:
It seems that Zulip offers free hosting: "Do you have special plans for open source projects, non-profits, groups of friends, and other non-commercial entities? Yes! Zulip Cloud Premium is free for open source projects and a wide variety of non-commercial entities. We also often offer steep discounts to educational institutions, and in other scenarios where users are not being paid a salary. Just contact sales@zulipchat.com and we'd be happy to discuss your situation! You may also be interested in Zulip for open source projects or Zulip for working groups and other part-time communities." [1] [1] https://zulipchat.com/plans/
I've also got confirmation from Tim Abbott (ZulipChat cofounder) that they'd be happy to host us and would even prioritize features they want. Who's interested in making this happen?We should start with an experiment, and it would be good to create a plan for evaluating success. If you want to help out, please volunteer to write up such a plan -- implementation will be easy. On Fri, Mar 30, 2018 at 11:44 AM, Aaron Ang <awz.ang@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Why don't you try to write a short document with a proposal -- hopefully it'll be pretty straightforward. You can email Tim Abbott ( tabbott@zulipchat.com) if you're stuck on details. On Fri, Mar 30, 2018 at 1:37 PM, Aaron Ang <awz.ang@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On Fri, Mar 30, 2018 at 1:23 PM, Guido van Rossum <guido@python.org> wrote:
Here are some points I jotted down. If someone is interested in this, maybe these points can be incorporated into a full fledge plan: PREDEPLOYMENT QUESTIONS AND RESEARCH ==================================== 1. SETUP ======== - talk to Tim Abbot <tabbott@zulipchat.com> and confirm the details about what Zulip can offer the Python project in terms of a hosted Zulip chat service - decide on the type of logins/auth that will be allowed for this service -> GitHub oauth? -> Google oauth? -> chat service specific account? -> other? - should there be a DNS name for this for easy eaccess: chat.python.org ? 2. ADMIN ======== -> identify points of contact for Zulip, i.e. who gets contacted if something goes wrong? -> should the existing Python Software Foundation infrastructure team be involved in the admin of this system? -> does Code of Conduct apply to users of chat system? Should this be advertised somehow when users -> what types of channels/rooms should be created? who is responsible for creating these channels? 3. INTEGRATIONS ================ - read up on Zulip Integrations ( https://zulipchat.com/integrations/ ) and Bots ( https://zulipchat.com/api/running-bots ) - identify systems that can be integrated with Zulip: -> GitHub (out of the box integration is available) -> Roundup (not available, needs to be written) -> Buildbot (not available, needs to be written) -> other ? 4. WEBSITE ========== - where on the Python.org website should information be made available for logging into the chat system? DEPLOYMENT PLAN =============== 0. EVALUATION ============= 1. Have key stakeholders test drive https://chat.zulip.org , and make sure they are OK with it, before proceeding to rollout. 1. PHASE 1 - initial rollout ============================ 1. Decide on the auth/login policy for the chat system 2. Get Zulip to set up the system and make it available 3. Have a few people in the core-workflow team test drive the system for 1 week 4. If it is people in 3. are happy with it, proceed to next steps, otherwise stop. 5. Write up some information on the website which points people to the chat system. 6. Send out announcements (e-mail, website, blog, twitter, etc.) about availability of chat site 2. PHASE 2 - post rollout ========================= 1. Look at what out of the box integrations can be set up quickly (GitHub) and set them up 2. Write any additional integrations for things that are not available (Roundup, Buildbot)
Thanks for the writeup Craig! My comments:
I'll be happy as long as these two auths are supported. - should there be a DNS name for this for easy eaccess: chat.python.org
?
Maybe in the second phase (after the trial phase) -> identify points of contact for Zulip, i.e. who gets contacted if
something goes wrong?
I'd like at least several core devs to get involved as admins. -> should the existing Python Software Foundation infrastructure team be involved in the admin of this system? I think they should be involved, with setting up zulip and as admins. -> does Code of Conduct apply to users of chat system? Should this be
advertised somehow
The PSF's CoC will apply. If it's up to me, I'll have a bot set up that greets every new members with explicit reminder that the CoC applies there. -> what types of channels/rooms should be created? who is responsible
for creating these channels?
To start just a python-dev room? admins can create new channels. - identify systems that can be integrated with Zulip: -> GitHub (out of the box integration is available) That's perhaps the important one right now (IMO). The next I'll probably use myself is Zapier integration :) Future integrations can be proposed at later time. Related question: - can anyone add/enable their own integration between zulip and something else? or only the admins? - where on the Python.org website should information be made available
for logging into the chat system?
Start with the devguide. We might want to update https://www.python.org/community/irc/. It can be requested by opening an issue at https://github.com/python/pythondotorg. But let's not do that yet until after the trial phase. Mariatta ᐧ
On Sat, 31 Mar 2018 at 12:51 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Since I assume we will be going with zulipchat.com hosting, there shouldn't be much set up beyond choosing initial settings, but someone from the infrastructure team should have admin rights to make sure there are enough people with admin access should something arise.
Yep, the CoC will automatically apply as it does to all infrastructure involving Python. And I vaguely remember there being a setting to specify what shows up when people sign up so this should be doable.
Using Zulip parlance, we would set up streams for what we have mailing lists for. To start, I would say we set up a stream for core-workflow and go from there as desired/requested. (And if this is successful we could potentially hand https://github.com/python/core-workflow/issues over to the actual tools for core development instead of being a catch-all place for ideas that others don't use heavily).
There's also a Travis integration.
You might be able to add your own. If you play with chat.zulip.org it seems to suggest you can set up your own bot if you want. Instructions on writing new integrations can be found at https://zulipchat.com/api/integration-guide
Yes, we haven't even agreed to doing a trial phase, so worrying about full-fledge roll-out isn't quite necessary yet. :) At this point we just need to figure out if we want to do this, why we want to do this, then we can worry about the how of flipping this on to test it out (i.e. the proposal doc). -Brett
Brett Cannon wrote:
Yep, that's right. We use this on chat.zulip.org to link to our own Code of Conduct, so you can check out what this looks like there.
That sounds like a good plan to me. Anyone in a Zulip org can create a stream; that's an option the org admins can change, but it's what I'd recommend for Python. So it's easy to let this evolve organically from there. For ideas on what a fully-fledged state might look like, there's some good discussion about streams here: https://zulipchat.com/help/getting-your-organization-started-with-zulip and in a couple of articles it links to. Craig Rodrigues wrote:
-> GitHub (out of the box integration is available)
Mariatta Wijaya wrote:
The next I'll probably use myself is Zapier integration :)
Brett Cannon wrote:
There's also a Travis integration.
Yep! Brett Cannon wrote:
Instructions on writing new integrations can be found at https://zulipchat.com/api/integration-guide
Yep! I'd add that we've put a fair bit of work and thought into making a great API for writing new integrations. I think we've been pretty successful at making it easy to do so, and the 90+ integrations we have built-in demonstrate that. Greg
Hello! Speaking as another member of the Zulip core team, I can answer right here some questions from this thread. First off, I'll say that I'm very happy to see this discussion, and repeat that we would be very happy to provide hosting. :)
The hosted service we'd offer out of the box is what we call Zulip Cloud Premium, as described here (except we'd provide it for free): https://zulipchat.com/plans/ For more about how Zulip works and why we like it, you can read these: https://zulipchat.com/why-zulip/ https://zulipchat.com/for/open-source/ To set up a Zulip community, someone can follow any of the "sign up" buttons to go to https://zulipchat.com/new/ and create a Zulip organization at a URL like python.zulipchat.com. Then let us know and we'll mark that organization to get Zulip Cloud Premium for free permanently. (We can also give it a custom domain like chat.python.org later.)
Out of the box, we support all three of the ideas above on zulipchat.com: GitHub OAuth, Google OAuth, and users can sign up with an email and password.
- should there be a DNS name for this for easy eaccess: chat.python.org ?
We're happy to do this while hosting on the zulipchat.com cloud service; we've done it for others before. No rush; we can move it to such a name later.
The usual point of contact is support@zulipchat.com; several of us monitor that and we're quite responsive there. For most things that's best. Folks can also contact me personally or, as mentioned upthread, Tim Abbott. We're in the Zulip organization for Zulip's own development community, at https://chat.zulip.org/ (which is of course open for anyone to join); once an open Zulip org for the Python project is set up, I'll certainly be present there too.
This part is easy :) -- whoever wants to do this can just go to https://zulipchat.com/new and create a new org. It's self-serve.
3. Have a few people in the core-workflow team test drive the system for 1 week
I'd suggest one addition to this: have at least one experienced Zulip user (probably me and/or Tim) participate in this step as well. Like many forms of online communication, there's a lot of habits and norms of usage for making everything smooth that you pick up naturally when you join an established community, but aren't as obvious when everyone is new to the system at the same time. Happy to answer other questions! Greg
On Sun, 1 Apr 2018 at 01:09 Greg Price <greg@zulipchat.com> wrote:
To prevent anyone from squatting on the name I just tried to register for python.zulipchat.com but was told that subdomain is not available (although python.zulipchat.com says there's no organization). :( -Brett
On Sun, 1 Apr 2018 at 10:28 Brett Cannon <brett@python.org> wrote:
I have gone ahead and registered python-lang.zulipchat.com (although nothing is set up yet since April Fools is my annual "stay off the internet" day plus I try to do no open source on Sundays and I would like to try and adhere to that :) . I will start configuring things probably tomorrow and will open things up to the community once I have gone through and tweaked all the settings (although it sounds like Greg is promoting leaving everything very open and going with the defaults, from stream creation to bot integration? Is that right, Greg?). IOW don't bother trying to use this yet as it's not publicly accessible ATM. Now if someone here actually registered python.zulipchat.com and simply didn't mention that then I'm happy to switch to that name and delete the organization I just created (although if we eventually put this behind a *. python.org subdomain I guess it doesn't really matter too much). Those that want to be admins can email me privately and I will add you to the organization (I will be restricting this to folks I know I can personally trust since admins can delete and ban people, so apologies in advance if I don't know you but you wanted to get involved at the admin-level).
Taking a look, it turns out we've had "python" in a list of subdomains that are reserved so nobody can register them through the signup form. The comment in the source suggests the idea was that we might put a blog at that URL someday. This seems like a still better use of the name, though. :-) I've just gone and renamed the org that was at python-lang.zulipchat.com to be at python.zulipchat.com. Brett, would you confirm you can log in there now and everything seems in order? Greg On Mon, Apr 2, 2018 at 9:51 AM, Brett Cannon <brett@python.org> wrote:
Just a quick update: I have https://github.com/python/cpython/pull/6379 to add a webhook for Travis failures, but after that I think all of the key things for an initial opening of this for Python development is ready (I am currently not scoping this for the whole Python community, so no general help stream). My hope is to announce the opening up of the instance here on Friday. If this experiment goes well we can then discuss announcing this on python-dev and making this a permanent thing. I'm also still looking for more volunteer admins (there are currently only two of us). On Mon, 2 Apr 2018 at 11:20 Greg Price <greg@zulipchat.com> wrote:
Yep! One reference you might find handy is the settings we have on the Zulip community's own Zulip org at chat.zulip.org, just because that's a pretty busy open-source community that we've kept running well for a couple of years. In general the organization settings are visible to any user (just read-only), so if you make an account there you can consult them through the same interface as you'll use to set them on python.zulipchat.com. Both those settings we've kept quite open. Greg On Sun, Apr 1, 2018 at 11:08 AM, Brett Cannon <brett@python.org> wrote:
On 31 March 2018 at 06:23, Guido van Rossum <guido@python.org> wrote:
I've also got confirmation from Tim Abbott (ZulipChat cofounder) that 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
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 <ncoghlan@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
Zulip really does seem like a great option, so I'm all for giving it a go. I just downloaded the macOS client and tried to connect, but apparently the Python channel requires approval to join. Maybe I'm just jumping the gun, but please let python-dev and/or -committers know when it's read for play! -Barry
On Thu, Apr 5, 2018 at 6:56 PM, Brett Cannon <brett@python.org> wrote:
Brett, Thanks for setting up python.zulipchat.com. While signing up for Zulipchat, I read through the terms of service at: https://zulipchat.com/terms/ I just wanted to confirm, are those terms of service compatible with PSF policies in terms of: - privacy of data, https://zulipchat.com/privacy/ , vs. Python.org's policy at: https://www.python.org/privacy/ - age restriction (zulipchat can only be used by age >= 13) - export compliance with respect to residents of Cuba, Iran, North Korea, or Syria - anything else Personally, I am not affected by these policies, since I am a U.S. citizen, resident in the U.S., and over 13 years old. I am not an expert in these topics, but just wanted to confirm that this is compatible with Python.org's policy, since Python is an open project with contributors who live in different countries around the world, and have different backgrounds, ages, etc. Thanks. -- Craig
On Fri, 6 Apr 2018 at 20:59 Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Since this is an experiment I'm fine with the current situation (the admins are also not planning on actively policing users over any of that either), but if someone feels strongly about this and wants to start a dialogue with the PSF board right now they can. And if it does become a problem and we want to keep using Zulip we can then stand up our own instance without those restrictions (assuming we even can; IANAL so I don't know how many of those requirements are required for any and all services hosted in the US or by a US organization).
On Fri, 30 Mar 2018 16:25:34 +0000 Brett Cannon <brett@python.org> wrote:
Consider the fact that a standard answer to a lack of email threading on any of the major email providers is to use gmane's NNTP gateway.
The main problem with gmane is that it isn't really maintained anymore. In particular you can't register new mailing-lists to the gateway :-(
I don't think people realize that anyone who post-dates the '90s has no clue what that acronym represents and thus poses the same barriers as setting up IRC.
I'm curious about "barriers". You just have to set up a piece of software... Python requires some kind of text editor or IDE to become productive. Is it a barrier to have to set up a text editor?
Well... I think the main question is whether IRC is important at all. I'd be willing to guess that most of our contributors don't use IRC on a regular basis, and they're not missing on anything. Which isn't a reason not to improve things, but makes it quite low-priority IMHO. Regards Antoine.
On Sat, Mar 31, 2018, 02:42 Antoine Pitrou, <solipsis@pitrou.net> wrote:
I don't want to dwell on this too much since I think we've collectively agreed to focus on the real-time collaboration case. But to answer the question, any piece of software we basically ask people to set up to be productive is a barrier. In North America there's is the phrase "death by a thousand paper cuts" and asking people to install yet more software and do more to get set up does have a cost where people have a personal limit how how many little things they are willing to put up with. As for this specific case, as a developer there is a much greater chance I will install an editor for all of my development needs while installing an email client has a higher chance tonne just for this specific case if people in school these days aren't heavy email users. -Brett
Missing out? No. Would like to occasionally have real-time collaboration? Yes, at least for me (I mean I could give every core dev my number toessage me on Signal or WhatsApp, but I don't think that scales 😉). Which isn't a
reason not to improve things, but makes it quite low-priority IMHO.
Yes, this isn't critical, hence why I don't think anyone has tried to do anything beyond discussing it so far. We will have to wait and see if anyone writes up a proposal as to why we should consider the overhead of asking people to sign up for Zulip and give it a try. -Brett
On 2 April 2018 at 18:55, francismb <francismb@email.de> wrote:
That's certainly the way corporate development environments are heading with projects like Eclipse Che (the tech behind codenvy.com), and AWS Cloud9. This post from Zapier engineering covers those two, as well as one I hadn't heard of before, CodeAnywhere: https://zapier.com/engineering/best-cloud-ides/ The main challenge with covering an approach like that in the dev guide is that none of the current core developers work that way, so we'd have a hard time providing good support to any newcomers that decided to take it up. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On March 30, 2018 5:35:13 AM INADA Naoki <songofacandy@gmail.com> wrote: Hi, Nowadays, joining to IRC is a hurdle for new contributors. There are some alternative, modern web applications: * Slack -- Most used for tech communities. One con other than the 10k limit is the weird fact that you essentially need a different account for each room you join. * Discord -- Similar to slack. It is focusing game, but support OSS too. [1] Discord is genuinely awesome. You can do pretty much everything for free, and it handles huge servers quite well. * Gitter -- Most integrated with Github. typing, mypy, pip use it already. AFAIK there are two main negatives to Gitter: - Only one "channel" per GitHub repo. Compare that to Slack or Gitter, where you can have multiple channels on one server. - Sorry, but the mobile app is largely garbage. It doesn't even handle links correctly, and it's particularly bad compared to the amazing Discord app. [1] https://discordapp.com/open-source I know adding communication channel is not good always. (We couldn't keep https://discuss.python.org/) But I think IRC is really high hurdle for young people. How about trying one of them? (maybe, gitter?) Regards, -- INADA Naoki <songofacandy@gmail.com> _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ Sent with AquaMail for Android https://www.mobisystems.com/aqua-mail
participants (15)
-
Aaron Ang -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Brian Curtin -
Craig Rodrigues -
francismb -
Greg Price -
Guido van Rossum -
INADA Naoki -
Mariatta Wijaya -
Ned Deily -
Nick Coghlan -
Ryan Gonzalez -
Stephane Wirtel