Discord #345
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,170 @@ | ||
| - Start Date: 07/11/2018 | ||
| - RFC PR: (leave this empty) | ||
| - Ember Issue: (leave this empty) | ||
|
|
||
| # RFC to move the Ember community chat to Discord | ||
|
|
||
| ## Summary | ||
|
|
||
| Encourage the Ember community to adopt Discord for real-time chat. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Real-time chat is essential to the function of online communities, particularly in open source. Chat fosters an informal, interactive style of communication that is important for building relationships, sharing community norms, coordinating on projects, and brainstorming ideas. | ||
|
|
||
| The Ember community predominantly uses [a Slack instance](https://ember-community-slackin.herokuapp.com/) as the gathering place of choice. While we have benefited enormously from Slack, there are significant downsides as well. | ||
|
|
||
| ### Loss of History | ||
|
|
||
| Because we use Slack's free plan, the entire instance is limited to 10,000 messages in history at any time. Because of this hard cap, the amount of time messages persist continues to shrink as the community grows. | ||
|
|
||
| It's hard to quantify exactly how painful this limitation is, as it means that new community members can't search for the answer to a question that was likely answered in the past. We can never go back to reference how or when a decision was made, which can mean decision-making feels less transparent that it should be. | ||
|
|
||
| This limit applies not just to chat messages, but direct messages between community members as well. This leads to annoyance, as people have to ask for the same information over again if they forgot to save it, or data loss, as useful things like code snippets vanish into the ether. | ||
|
|
||
| ### Performance | ||
|
|
||
| The architecture of the Slack native application relies on running a separate web application per Slack instance the user is signed into. For users who need to be in multiple Slack instances, this can add up to a significant tax on computer resources, particularly as the application starts up. | ||
|
There was a problem hiding this comment. I personally don't think this is a good point to make up a decision. Slack has become very frequently used on OSS projects. For instance I only use 1 slack instance, which has multiple workspaces for different OSS projects. If now one OSS projects decides to no longer use slack, this puts a burden on everyone who is contributing to multiple OSS projects, as they now need to use multiple clients. There will inevitably always be a group of people who will have a performance gain from the decision made here and people who will have a disadvantage. There was a problem hiding this comment. I think there needs to be clarification of the word “instance”. Slack workspaces or orgs are implemented as completely separate processes meaning the more slack orgs you belong to the less performant it becomes. Anecdotally I find that discord takes much fewer resources than slack while in the background and about the same resources as one workspace when in the foreground. There was a problem hiding this comment. I personally think this section should be removed or reworded, it specifically states that performance isn't different enough to be a factor in the decision but at the same time the sections presence (in an RFC motivating a move) clearly indicates that it is... There was a problem hiding this comment. I am in like 10 discord servers and never have performance issues, some of them quite big. But with slack it just takes 1 tab to start creeping up resource usage. More than 1 slack and it is noticeable and why I can't idle in places I want to. I refuse to use so many resources for a damn chat application. |
||
|
|
||
| Once Slack is up and running, most people generally find the performance reasonable, but a solution that offers better startup and runtime performance would be ideal. | ||
|
|
||
| ### Privacy Concerns | ||
|
|
||
| Slack is very clear that their target audience is companies, who often have strict compliance rules that they must follow. Unfortunately, those needs are often at odds with concerns about privacy in an open source community. | ||
|
|
||
| In particular, Slack recently added a feature called Corporate Export that theoretically allows administrators to export all messages, including private messages, without notifying users. | ||
|
|
||
| Now, the odds of this feature being abused are extremely low. It is only available on Slack's Plus plan, which means a malicious actor would need to be granted administrator priveleges, pony up at least $150,000 to upgrade our Slack plan for that month, apply for the the Corporate Export feature, have it granted by Slack, and then perform an export without anyone noticing. | ||
|
|
||
| Because the difficulty of exploiting this feature for evil is so remote, it's not a primary concern driving this change. But all things being equal, we prefer a solution that doesn't offer export of private messages at all, so it's never a concern at the back of someone's mind. | ||
|
|
||
| ### Better Communication & Transparency | ||
|
|
||
| Out of frustration with Slack's disappearing messages, the Ember.js core team set up a Discord server to evaluate if it might be a better fit for open source communities. | ||
|
|
||
| While this was a public Discord server that anyone could sign up for, its existence was not widely publicized because we were unsure if Discord was the right solution. | ||
|
|
||
| Over time, the core team and many contributors gravitated towards the Discord, finding that it served our needs better. Because of how valuable the Slack instance is, no one wanted to propose a move to Discord until a plan (like, say, this RFC) could be put in place. | ||
|
|
||
| Unfortunately, this state of affairs has had several undesirable outcomes. | ||
|
|
||
| First, it has caused many of the most prolific contributors to be less active in Slack. This may give the appearance of stagnation or disinterest, when momentum on Ember has never been higher. It robs lurkers of the ability to become contributors if a good opportunity to help pops up. And it prevents some of the most experienced members of the community from being around to help answer questions they might have an off-hand answer to. | ||
|
|
||
| Second, and perhaps worst of all, it undermines the transparency and open governance that we have worked hard to create. Our bar is higher than just making it possible to contribute—we go out of our way to actively welcome and encourage everyone to participate, learn and contribute. | ||
|
|
||
| ## Detailed design | ||
|
|
||
| ### Transition Plan | ||
|
|
||
| We will need these things to transition the community smoothly: | ||
|
|
||
| - a period of time when we use both chat platforms during the transition, put the equivalent Discord channel information in the Slack channel topic | ||
| - a clear guide (with illustrations) | ||
|
|
||
| #### Initial Setup | ||
|
|
||
| Because Discord has fine-grained controls, we will be able to implement categories for chats. | ||
|
|
||
| We intend to have the "welcome" channel as the initial channel for everyone who joins the Discord server. This channel will be read-only and will list the rules for the Discord server. | ||
|
|
||
| **Verification Level** | ||
| Initially, we will be implementing the "low" verification level, which means users will need to have a verified email on their Discord account. If this proves to be too easy of a target for spammers, we will implement a higher level of verification (levels include amount of time a user has to be a verified member of the server before they can post). | ||
|
|
||
| **Explicit Content Filter** | ||
| Since this is a public Discord server, we will be setting an explicit content filter- it will scan messages from all members without a role. | ||
|
|
||
| **Categories and Channels** | ||
| Community members will then have the option of visiting the "setup" channel and learning more about fine-grained controls, such as: | ||
|
|
||
| - notifications | ||
| - muting a channel | ||
| - muting a category | ||
|
|
||
| Because our goal is transparency, all channels will be visible. A lock icon will display if the user does not have the role necessary to join that channel. | ||
|
There was a problem hiding this comment. Can visibility be defined here for those folks unfamiliar with discord? Will the content of the channels be visible regardless of the user role? There was a problem hiding this comment. Does not being able to join in this context mean you are able to read, but not write? If not, what is the point in telling people "hey, there is a channel which sounds interesting, but you will not be able to join it or read what is going on!"? There was a problem hiding this comment. Or further, if the goal is transparency, why lock anything in the first place? If the goal is only partial transparency except for safe spaces, we should be honest with ourselves about that... There was a problem hiding this comment.
No, "visible" in this context refers to knowing the channel exists (by seeing it listed in the channel listing), not seeing its contents.
Agree, I think that just means we need to tweak the verbiage to make that clearer. From my perspective, there is very real reason to have some safe space where the various core teams can have private internal discussions, but the majority of discussions would not (and IMHO should not) happen in those private channels. |
||
|
|
||
| The following proposed initial category and channel list was chosen based on the current channel needs and evaluation of the channels with the most members on Slack. _Additional channels may be requested in the Admin/community-feedback channel._ | ||
|
|
||
| **Category/Channel List:** | ||
| - (No Category) | ||
| - welcome (community guidelines are posted here) | ||
| - setup-profile (how to setup your profile) | ||
| - Admin | ||
| - community-feedback (questions, comments, concerns, requests) | ||
| - security | ||
| - steering-committee 🔒 (locked to role “steering-committee”) | ||
| - news & announcements | ||
| - ember-jobs | ||
| - bots | ||
| - Core Teams | ||
| - ember-js 🔒 (locked to role “core-js”) | ||
| - ember-data 🔒 (locked to role “core-data”) | ||
| - ember-cli 🔒 (locked to role “core-cli”) | ||
| - ember-learning 🔒 (locked to role “core-learning”) | ||
| - Working on Ember | ||
|
There was a problem hiding this comment. Need testing channel both under 'Working on Ember' and 'Using Ember' There was a problem hiding this comment. Also a 'Release' channel under 'Working on Ember' There was a problem hiding this comment. @kategengler should we use the dev- prefix that is currently being used in Slack? There was a problem hiding this comment. I think the category headings are enough, but maybe we see how it feels? I was just pointing out the missing channels that are heavily used. There was a problem hiding this comment. A problem with that is it kind of breaks the autocomplete, which would be useful for things like "you should ask that question on #ember-cli". I can see autocompleting to the wrong channel becoming a pretty common problem:
There was a problem hiding this comment. @chancancode this is a good point, thank you for bringing that up. There was a problem hiding this comment. @chancancode I can see still putting them in categories for mute/notification purposes, but then have per-category channels get prefixed for autocomplete simplicity. |
||
| - ember-cli | ||
| - ember-data | ||
| - ember-engines | ||
| - ember-js | ||
| - glimmer-vm | ||
| - triage | ||
| - st-* (as needed) | ||
| - Using Ember | ||
| - general-help | ||
| - learning-ember | ||
| - a11y | ||
| - backend | ||
| - internationalization | ||
| - jsonapi | ||
| - mobile | ||
| - ember-js | ||
| - ember-data | ||
| - ember-cli | ||
| - ember-engines | ||
| - fastboot | ||
| - ember-twiddle | ||
| - e-* | ||
| - Supporting Ember | ||
| - documentation | ||
| - website | ||
| - marketing-and-advocacy | ||
| - infrastructure | ||
| - Event-Chat | ||
| - EmberConf | ||
| - EmberCamp | ||
| - EmberFest | ||
| - Talks | ||
| - Other Conferences | ||
| - Meetup organizers | ||
| - Social | ||
| - Water-cooler (random) | ||
| - Local-* | ||
| - Media (livestreams, videos, podcasts) | ||
| - Pets | ||
| - Women in Ember 🔒 | ||
|
|
||
| ## How do we teach this? | ||
|
|
||
| In addition to having a setup channel available upon login (with illustrated instructions), here are some links where community members can read more: | ||
|
|
||
| - [Discord Loves Open Source](https://discordapp.com/open-source) | ||
| - [Discord Community Guidelines](https://discordapp.com/guidelines) | ||
| - [How to use Discord](http://www.businessinsider.com/how-to-use-discord-the-messaging-app-for-gamers-2018-5) | ||
|
|
||
| ## Drawbacks | ||
|
|
||
| ### Supporting Learning vs Supporting Development | ||
|
|
||
| There is some concern that there is already some confusion on Slack about where to get help learning/using Ember, and where to coordinate working on Ember. We need to have a clear delineation so that the folks who are spending their volunteer time to ship Ember features can continue to concentrate and do that. | ||
|
|
||
| ### Losing Community Members | ||
|
|
||
| There is some concern that we may lose some community members due to this move. | ||
|
|
||
|
There was a problem hiding this comment. A drawback that I find to Discord is moderation of DMs for CoC violations. As a Discord group admin a user can be banned from the group but this does not stop them from DMing members of that group. I'm not aware of any tools or privileges that Discord has to prevent something like this. I would hope that this is covered by their TOS but then I think it would probably fall to Discord to moderate that and not the Ember community which may be hard to moderate? There was a problem hiding this comment. I think that their guidelines (linked in the RFC) explicitly address this: https://discordapp.com/guidelines Additionally, you can block the user. There was a problem hiding this comment.
That would require each user in the Ember discord to block the user individually? There was a problem hiding this comment.
We genuinely don't anticipate a high level of harassment on Discord, and Discord has well-documented instances of handling harassment appropriately (see https://blog.discordapp.com/parents-guide-to-discord-c77d91793e9c). There was a problem hiding this comment.
If you have the I know discord has a good track record of handling harassment, but just noting that the end moderation lies in Discord's hand vs Slack where that user no longer has access to DM individuals once removed from the group since users are tied to groups in slack. There was a problem hiding this comment. You can choose who can DM you, as well: |
||
| ## Alternatives | ||
|
There was a problem hiding this comment. An open source alternative such as https://www.mattermost.org/ should at least be considered. I did this analysis ~3 years ago for a community and it wasn't there yet, but it might be today. There was a problem hiding this comment. Mattermost is an interesting project, but I don't think it's feasible for a volunteer-run open source project to get into the business of self-hosting critical infrastructure. Not only does it take away time and resources from other important work, I would be extremely uncomfortable running a production service without a full-time ops team taking care of security patches, performance optimization, backups, etc. Outsourcing this to a third party is the only option that makes sense for a project of our size, IMO. There was a problem hiding this comment. That's fine, I just think it should be in this section at least. There was a problem hiding this comment. As an open source alternative, there is also https://rocket.chat/. However, that means you need to maintain your infra to support the chat and as Tom said, that would remove the focus from other important tasks of the team. There was a problem hiding this comment. I think anything that requires infrastructure management is out of the question. Community chat should be simple |
||
|
|
||
| The alternative to this would be to temporarily remain on Slack until we are able to evaluate and choose another viable option. However, we believe that staying on Slack is not desirable. | ||
|
|
||
| ## Unresolved questions | ||
|
|
||
| * When will there be conversation threads? | ||
|
There was a problem hiding this comment. Another unresolved question is linking to previous conversations. While discord has seemingly unlimited history it is not currently possible to link to a particular response or comment. To me this really limits the usefulness of history being preserved. There was a problem hiding this comment. So I did some research on this, and they've improved search to the point where I think the addition of linking to a message will be a future enhancement, but I no longer consider it a blocker to adoption. There was a problem hiding this comment. Before threading the Slack channels used comment linking a lot more than currently (it's still used a good amount each day). SO I worry about context switching without links There was a problem hiding this comment. This may not be an issue much longer, some users are reporting being able to do this (I can't however) so it seems like this may be being rolled out using some feature flagging at the moment. There was a problem hiding this comment. So it looks like links to messages are rolling out- There was a problem hiding this comment. I will add that the Discord team has been very responsive to feature requests from OSS communities in the past, and if anyone from the Ember community wants an invite to their private dev server to submit feature requests, let me know. I've been idling there since like 2015, when we mounted a campaign to support |
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think one key point is that it is quite difficult to mix real time messaging with a well sorted journal like long term storage. In my experience it gets very difficult to distil usable information from real time chats - especially by hand via a search function (this is from OSS projects hosted on free slack with message limit in place, so this might get worse the more messages are stored). But that has been brought up multiple times in the past and if we keep discussing on that level, we probably will never find a better solution.