Move to Slack

[iredelmeier]

This was also discussed during the F2F Trace-Context meeting.

Pros

• Slack is already a more common part of most community member's workflows
• Slack is (subjectively) easier to use:
  • Slack channels vs Gitter rooms
  • Slack notifications seem to behave more consistently across apps and are much more configurable
  • Slack has search

Cons

• Unlike Gitter, Slack isn't OSS
• Slack's free plan is limited
  • The premium features are arguably limited in Gitter, so this might not actually be a delta? e.g., free Slack has history limitations, but Gitter's lack of search makes old conversations hard to use anyway 🤷‍♀️

[tedsuo]

I like slack.

"10k searchable messages" will go pretty quickly. IMHO, that is the only free tier limitation which has real ramifications. I have definitely (painfully, sometimes) dug through old DMs on gitter to find some relevant piece of information. In short: we may regret losing the chat record for OpenTelemetry.

If this turns out to be the case, I would advocate for switching to a chat system which can record the entire message history, even if it is missing other features. Some options:

• https://spectrum.chat/
• https://discordapp.com/open-source
• back to http://gitter.im/open-telemetry

Other than message history, I don't see any reason why slack wouldn't work well!

[bogdandrutu]

From the PR discussion:

Can we please run this proposal by the https://github.com/open-telemetry/community/blob/master/community-members.md#admins people?

[caniszczyk]

You're welcome to create as many channels on slack.cncf.io which has the pro plan included (which we recommend for CNCF projects)

[iredelmeier]

@caniszczyk thanks for adding that! Meant to suggest it as an alternative.

The (big!) upside is what you mentioned. The main drawback I see (also discussed last week) is that it may be confusing to keep track of amidst the other CNCF channels. Then again, that may also double as an upside, since it might encourage more cross-pollination 😃

[AloisReitbauer]

Main advantages of Slack:

• Easy to have different channels for different work stream (e.g. languages)
• Good app support for automation (e.g. push notifications on PRs etc.)
• Support for video and voice conferencing built-in
• Better usability and stability

I am not saying it is the only solution that can do this, but Gitter is really limited in functionality.

[caniszczyk]

@iredelmeier I'm all for less Slacks out there :)

[iredelmeier]

@caniszczyk I very much agree there 🤣

Do you (or anyone else) know of any other CNCF projects that use that Slack for multi-channel purposes? e.g., gRPC, K8S, and Linkerd all have community forums elsewhere.

[caniszczyk]

@iredelmeier

I'd have to dig around but I know of cloudevents off hand

#cloudevents
#cloudeventssdk
#cloudeventsdemo

[irabinovitch]

Have we considered moving decisions and discussions from chat rooms to mailing lists? Ala The Apache Way of "If it didn’t happen on the mailing list, it didn’t happen."

[spirosx]

I think Slack is strictly better than gitter for all the reasons mentioned by @AloisReitbauer and @iredelmeier but IMO the 10K messages limit for a project with as many contributors and members is a show stopper as we will lose history and the background/arguments for whatever decision we make on Slack.

I suggest we either use the cncf one (maybe with an #opentel- prefix for our channels) or we find a way to pay for it (this might be unrealistic if every member is on it)

[iredelmeier]

@irabinovitch there have been some brief, in-person discussions about mailing lists. My admittedly subjective take:

GitHub - not Slack/Gitter/mailing lists/whatever else - should be the source of truth for all decisions. It's where the code lives; there's already (I believe!) consensus around using the issue/PR workflow; etc. It seems like Apache's usage of mailing lists for consolidating decisions is juxtaposed to our use of GitHub, not our use of Slack. (Side note: I believe - and there's been some discussion affirming - that we should use a dedicated RFC process for spec and other cross-cutting decisions, rather than ad-hoc issues and PRs; see #56).

As far as the use of mailing lists vs Slack or Gitter goes, I personally think that this can be an AND, not an OR. Mailing lists are a great common denominator, in that they have such low barriers to entry. However, this comes at the cost of having fewer niceties, e.g., it's hard to use notifications and other mechanisms of following conversations or topics outside. I'm all for having a mailing list in addition to at least one app-based solution; however, I think we lose a lot by using the mailing list as our primary (let alone exclusive) place of discussion.

[iredelmeier]

re: using the CNCF Slack vs a dedicated Slack, some more questions:

• Anyone know what the CNCF Slack's pricing plan is like? Specifically, would we potentially have a significant impact on their Slack budget? (I admittedly don't know much about Slack pricing!)
• Anyone have context on the Slack plans for any of the other CNCF projects (other than K8S) with dedicated Slacks?

I don't mind trying to track someone from CNCF or another project down this week at KubeCon, unless someone else already has answers or is in a better position to get them.

[caniszczyk]

If you use the CNCF Slack there will be no impact so you don’t have to worry about anything fiscally, that’s why we recommend it

On Mon, May 20, 2019 at 6:23 PM Isobel Redelmeier ***@***.***> wrote: re: using the CNCF Slack vs a dedicated Slack, some more questions: - Anyone know what the CNCF Slack's pricing plan is like? Specifically, would we potentially have a significant impact on their Slack budget? (I admittedly don't know much about Slack pricing!) - Anyone have context on the Slack plans for any of the other CNCF projects (other than K8S) with dedicated Slacks? I don't mind trying to track someone from CNCF or another project down this week at KubeCon, unless someone else already has answers or is in a better position to get them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53?email_source=notifications&email_token=AAAPSINYIVILN5BJC2L63NDPWLGARA5CNFSM4HOBIIP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVZLPMQ#issuecomment-494057394>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAPSIKIWN7KKOQDYNC3T4DPWLGARANCNFSM4HOBIIPQ> .

-- Cheers, Chris Aniszczyk http://aniszczyk.org +1 512 961 6719

[SergeyKanzhelev]

I like in gitter that you can view the channel without logging in. So you can check it out before joining. Also you don't need a separate registration, simply use GitHub account. Lack of search is disturbing, but actually make it use the channel appropriately - for chatter, not for announcements or serious discussions. Lack of likes, emojis and formatting serves the same purpose. Topic starter quickly realize that for serious question you will be better served by GitHub issue or e-mail. Also I definitely want to avoid the need to scroll the channel all the way up to make sure I'm up to date. So lack of search just another way to ensure nobody will use the channel for things that cannot be just missed if you were on vacation.

My understanding is that this push for Slack is coming from companies that already uses it. Plus, people who wants to work on the go more productively with Slack's apps.

Having said this, am I correct that the question is whether we move barrier of participating up for majority of people by requiring log in and join the slack channel to see discussions. Or make life of existing participants easier? Or I missing some capabilities in Slack?

As an example, I don't see this as welcoming experience:

when this immediately show whether it's worth to join:

P.S. BTW, I don't use either outside of W3C or OpenTelemery. So for me it's largely irrelevant which one to use. The same way I can advocate for teams as I'm already on it all the time =).

[owais]

Another major downside to slack (and to some extend gitter) is that it cannot be indexed. Mailing lists and good old IRC rooms can be indexed and made searchable. As a user, I've found olds discussions in mailing lists and chat rooms immensely useful both with getting to learn about a project and it's history, and with solving specific problems by learning from others' past experiences. Not sure how valuable it is for people directly involved with the project but it is immensely helpful for the wider community.

If slack is to be used, a bot that could read daily digests from specific slack channels and write out as a log to some community web page with back-links to the channel would be very helpful. Not sure if Slack ToS allows this though. Random example: https://irclogs.ubuntu.com/2008/11/10/%23ubuntu-motu.html

Another alternative could be https://spectrum.chat (owned by Github). It is open by default and very much "indexable" (https://www.google.com/search?q=react+site%3Aspectrum.chat). A downside (or upside) is that there appears to be only a single free form chat room while channels feel more like Twitter with threaded conversation per post.

[tedsuo]

@owais A bot that writes a log out sounds like a great idea. I would be satisfied with the lack of search/retention in free Slack if I could occasionally grep a file somewhere.

BTW I played with spectrum (I made a test account here: https://spectrum.chat/opentelemetry). It's interesting, but if you play with it, you'll realize it's a bit more like issues or a mailing list than like a chat room. So it might not be the solution that fills the niche: I believe we want issues for work, mailing list for announcement, and chat just for chat. :)

[rochdev]

One thing that bothers me a lot about Gitter is that when a discussion happens about a very specific subject and goes on to hundreds of comments, it gets really difficult to figure out which message is about what, and which message you are actually interested in. There is a lot of noise in the only channel available to a room basically.

This is addressed not only by Slack but by any chat app with the ability to create channels, since then it's possible to split something like opentelemetry-node in several channels, even ad-hoc ones when needed.

[thomashchan1]

@mtwo posted this poll (thanks). Please vote if you have not done so. Thanks in advance. https://docs.google.com/forms/d/e/1FAIpQLScHcyLH4EPb0wPGGGvbvI3fnDgEYBbZypInBKrLt_v13-j1Ww/viewform?usp=sf_link

[AloisReitbauer]

Is there any final decision on this topic?

[mtwo]

Last I heard, the board was debating between creating channels on the CNCF Slack vs. using Gitter. @SergeyKanzhelev likely has the latest data.

[bhs]

As someone who really prefers Slack UX to Gitter UX, I am here with mixed emotions to report back about the "Slack vs Gitter" decision.

Our criteria for real-time chat/collaboration were as follows:

• Actual collaboration UX (slack wins handily)
• Transparency, both for "official" community members and for anyone-with-an-internet-connection. This means not just that data is literally public, but that it's discoverable/indexed/searchable/etc (slack wins for people already in the slack instance; Gitter wins for people who are "just stopping through")
• A cost structure that could scale to support "lots" of passive observers over time (slack would be ok from a $ standpoint for the die-hard community members, but the costs can get out of control when there are lots of readonly users)
• The overhead of actually joining the real-time collab platform (Gitter wins hands-down here, as you can observe via a URL and participate if you have GitHub or Twitter; slack workspace onboarding is a PITA)

Initially we were trying to go for a model where all community members in community-members.md would be in an OpenTel slack instance, and we would set up some sort of slackbot that records and indexes 100% of public channel activity, making that searchable for "outsiders". Unfortunately, none of the slackbots we found (and we looked at 6 of them) would actually work for this use case.

So, given all of the above and the fact that both OpenTracing and OpenCensus already use Gitter, we are going with ... Gitter.

We can reevaluate this decision if either (a) Slack changes their pricing model to allow for unlimited (or at least "very cheap") read-only users, or (b) it's 2020. (I.e., we are going to commit to this decision for the rest of the year but can reevaluate next year)

[mtwo]

Seems reasonable!

[rochdev]

There is a reason why Slack is paid and Gitter is free 😄Gitter is very inefficient for discussions on specific topics since everything happens in a single super noisy room. Personally I find that it's to the point that it's almost unusable, so I'd definitely try harder to make Slack work.

@bhs Did anyone contact Slack directly to try and see if they could provide some sort of deal given the nature of the project and the very low monthly message count? As you mentioned their pricing model is based on enterprise usage which is definitely different than an OSS project community.

There is also Discord that is very similar to Slack and I know it's used by OSS projects with tens of thousands of users in the workspace.

[bhs]

@rochdev

@bhs Did anyone contact Slack directly to try and see if they could provide some sort of deal given the nature of the project and the very low monthly message count? As you mentioned their pricing model is based on enterprise usage which is definitely different than an OSS project community.

We sure did! And the answer was a firm "no." 😿

Re Discord: can you point to any OSS projects that are (relatively happily) using it?

[owais]

Don't know about the happy part but discord claims to host these OSS projects: https://discordapp.com/open-source

[dankohn]

This doesn't matter to CNCF and is totally OpenTelemetry's decision. But, I didn't understand "sharing a busy Slack workspace with the rest of the CNCF didn’t appeal to anyone" from your update. CNCF's plan from Slack lets us host unlimited channels and unlimited users for no charge.

We can create however many channels OpenTelemetry wants, and your users can ignore all other channels. So, I don't get the problem "sharing".

[bai]

I'm 💯for moving to Slack, given how better the ecosystem is with desktop and mobile clients. Given most of (if not all) CNCF projects are also on Slack (whether CNCF.slack.com or Kubernetes.slack.com), it makes sense to me to consolidate and provide a consistent communication experience.

To be blatantly honest, while I see theoretical advantage of having a publicly indexable chat, in practice I don't remember when was the last time I've seen Gitter chats in Google search results. I've just tried to search explicitly using site:gitter.im and I fail to find something meaningful at all.

I feel like we might be making it harder for larger part of the community to participate in order to gain theoretical advantages with limited real world usefulness, if that makes sense.

[bhs]

@dankohn that is good to know re "unlimited channels" (and unlimited users!! Good for you / good for Slack!). Maybe that changes things a bit...

I will bring this up again at the next "governance committee" meeting since that's new info (to me, at least).

@bai:

To be blatantly honest, while I see theoretical advantage of having a publicly indexable chat, in practice I don't remember when was the last time I've seen Gitter chats in Google search results. I've just tried to search explicitly using site:gitter.im and I fail to find something meaningful at all.

The point is not to google the chat results, it's to provide transparency to people (especially people who are not yet OpenTelemetry contributors) seeking explanation or context for decisions we make. If that context exists in Gitter, at least we can link to it publicly... but for a closed Slack instance, we cannot, and that's a real problem for project transparency.

(There is also the concern about slack onboarding being annoying (vs the bare-link onboarding in Gitter), but I'm less moved by that)

[dankohn]

Note that you onboard CNCF Slack from slack.cncf.io. And that you can limit searches to specific channels.

[mtwo]

Closing this as we're satisfied with Gitter at the moment