Comments (30)
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 =).
from community.
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:
Other than message history, I don't see any reason why slack wouldn't work well!
from community.
@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. :)
from community.
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.
from community.
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".
from community.
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?
from community.
You're welcome to create as many channels on slack.cncf.io which has the pro plan included (which we recommend for CNCF projects)
from community.
@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 😃
from community.
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.
from community.
@iredelmeier I'm all for less Slacks out there :)
from community.
@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.
from community.
I'd have to dig around but I know of cloudevents off hand
#cloudevents
#cloudeventssdk
#cloudeventsdemo
from community.
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."
from community.
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)
from community.
@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.
from community.
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.
from community.
from community.
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.
from community.
@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
from community.
Is there any final decision on this topic?
from community.
Last I heard, the board was debating between creating channels on the CNCF Slack vs. using Gitter. @SergeyKanzhelev likely has the latest data.
from community.
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)
from community.
Seems reasonable!
from community.
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.
from community.
@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?
from community.
Don't know about the happy part but discord claims to host these OSS projects: https://discordapp.com/open-source
from community.
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.
from community.
@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)
from community.
Note that you onboard CNCF Slack from slack.cncf.io. And that you can limit searches to specific channels.
from community.
Closing this as we're satisfied with Gitter at the moment
from community.
Related Issues (20)
- Do not modify APPENDIX in the Apache-2 license file
- Grant write permissions for GC to all repositories
- REQUEST: New membership for sudivate HOT 5
- Change time of System Sem Conv Stability WG HOT 10
- Create GitHub admin team and populate it HOT 7
- REQUEST: New membership for grcevski HOT 6
- REQUEST: New membership for christos68k HOT 3
- REQUEST: New membership for scorpionknifes HOT 3
- REQUEST: New membership for alxbl HOT 3
- Remove @open-telemetry/end-user-wg team HOT 1
- REQUEST: New membership for jhalliday HOT 3
- REQUEST: Repository maintenance on sig-end-user HOT 5
- REQUEST: Repository maintenance on opentelemetry-lambda HOT 2
- REQUEST: Give organization access to the self-actuated Github application HOT 9
- REQUEST: New membership for AnaMMedina21 HOT 5
- REQUEST: New membership for IAMebonyhope HOT 5
- Help SIG maintainers to keep track of spec changes HOT 2
- Create missing documents for projects HOT 7
- REQUEST: Enable Renovate on opentelemetry-go and opentelemetry-go-contrib HOT 9
- Recreate the Go SIG meeting on alternate weeks HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from community.