To me, the most important opportunity here is to create a better support environment for users, and I think it’s super important to allow users to join immediately on their own if we want this to succeed. A lot of users these days do prefer to join a live chat interface to get support for an open source project than to email a list. Just look at how many people joined the Slack workspaces for related open source projects — there are 8000 users in the Delta Lake one, which covers only a subset of the Spark user community, so this is already more than the user@ mailing list. So I do think we should have an official project Slack with an easy invitation process.
*Developer* discussions should still happen on email, JIRA and GitHub and be async-friendly (72-hour rule) to fit the ASF’s development model. Given the size of the overall Spark user base, I would also lean towards a standalone workspace, where we have more control over organizing the channels, have #general and #random channels that are only about Apache Spark, etc. I’m not sure that joining a Slack workspace that supports all ASF projects would work well for users seeking help, unless it’s being organized for broad user support that way. In practice, when you use the Slack UI, you can easily switch between different Slack workspaces and invite people from them into another workspace, so users should not have trouble participating in multiple Slack workspaces to cover different projects. Just my 2 cents, maybe there is another approach that would work with the ASF-wide workspace, but I do think that Slack is meant to be used as a multi-workspace thing. > On Apr 6, 2023, at 3:17 PM, Maciej <mszymkiew...@gmail.com> wrote: > > Additionally. there is no indication that the-asf.slack.com is intended for > general support. In particular it states the following > > > The Apache Software Foundation has a workspace on Slack > > <https://the-asf.slack.com/> to provide channels on which people working on > > the same ASF project, or in the same area of the Foundation, can discuss > > issues, solve problems, and build community in real-time. > > and then > > > Other contributors and interested parties (observers, former members, > > software evaluators, members of the media, those without an @apache.org > > address) who want to participate in channels in the ASF workspace can use a > > guest account. > > Extending this to inviting everyone on @user (over >4k subscribers according > to the previous thread) might be a stretch, especially without knowing the > details of the agreement between the ASF and the Slack Technologies. > > -- > Best regards, > Maciej Szymkiewicz > > Web: https://zero323.net <https://zero323.net/> > PGP: A30CEF0C31A501EC > > On 4/6/23 17:13, Denny Lee wrote: >> Thanks Dongjoon, but I don't think this is misleading insofar that this is >> not a self-service process but an invite process which admittedly I did not >> state explicitly in my previous thread. And thanks for the invite to >> the-ASF Slack - I just joined :) >> >> Saying this, I do completely agree with your two assertions: >> Shall we narrow-down our focus on comparing the ASF Slack vs another >> 3rd-party Slack because all of us agree that this is important? >> Yes, I do agree that is an important aspect, all else being equal. >> I'm wondering what ASF misses here if Apache Spark PMC invites all remaining >> subscribers of `user@spark` and `dev@spark` mailing lists. >> The key question here is that do PMC members have the bandwidth of inviting >> everyone in user@ and dev@? There is a lot of overhead of maintaining this >> so that's my key concern is if we have the number of volunteers to manage >> this. Note, I'm willing to help with this process as well it was just more >> of a matter that there are a lot of folks to approve >> A reason why we may want to consider Spark's own Slack is because we can >> potentially create different channels within Slack to more easily group >> messages (e.g. different threads for troubleshooting, RDDs, streaming, >> etc.). Again, we'd need someone to manage this so that way we don't have an >> out of control number of channels. >> WDYT? >> >> >> >> On Wed, Apr 5, 2023 at 10:50 PM Dongjoon Hyun <dongjoon.h...@gmail.com >> <mailto:dongjoon.h...@gmail.com>> wrote: >>> Thank you so much, Denny. >>> Yes, let me comment on a few things. >>> >>> > - While there is an ASF Slack <https://infra.apache.org/slack.html>, it >>> > requires an @apache.org <http://apache.org/> email address >>> >>> 1. This sounds a little misleading because we can see `guest` accounts in >>> the same link. People can be invited by "Invite people to ASF" link. I >>> invited you, Denny, and attached the screenshots. >>> >>> > using linen.dev <http://linen.dev/> as its Slack archive (so we can >>> > surpass the 90 days limit) >>> >>> 2. The official Foundation-supported Slack workspace preserves all messages. >>> (the-asf.slack.com <http://the-asf.slack.com/>) >>> >>> > Why: Allows for the community to have the option to communicate with each >>> > other using Slack; a pretty popular async communication. >>> >>> 3. ASF foundation not only allows but also provides the option to >>> communicate with each other using Slack as of today. >>> >>> Given the above (1) and (3), I don't think we asked the right questions >>> during most of the parts. >>> >>> 1. Shall we narrow-down our focus on comparing the ASF Slack vs another >>> 3rd-party Slack because all of us agree that this is important? >>> 2. I'm wondering what ASF misses here if Apache Spark PMC invites all >>> remaining subscribers of `user@spark` and `dev@spark` mailing lists. >>> >>> Thanks, >>> Dongjoon. >>> >>> <invitation.png> >>> <invited.png> >>> >>> On Wed, Apr 5, 2023 at 7:23 PM Denny Lee <denny.g....@gmail.com >>> <mailto:denny.g....@gmail.com>> wrote: >>>> There have been a number of threads discussing creating a Slack for the >>>> Spark community that I'd like to try to help reconcile. >>>> >>>> Topic: Slack for Spark >>>> >>>> Why: Allows for the community to have the option to communicate with each >>>> other using Slack; a pretty popular async communication. >>>> >>>> Discussion points: >>>> There are other ASF projects that use Slack including Druid >>>> <https://druid.apache.org/community/>, Parquet >>>> <https://parquet.apache.org/community/>, Iceberg >>>> <https://iceberg.apache.org/community/>, and Hudi >>>> <https://hudi.apache.org/community/get-involved/> >>>> Flink <https://flink.apache.org/community/> is also using Slack and using >>>> linen.dev <http://linen.dev/> as its Slack archive (so we can surpass the >>>> 90 days limit) which is also Google searchable (Delta Lake >>>> <https://www.linen.dev/s/delta-lake/> is also using this service as well) >>>> While there is an ASF Slack <https://infra.apache.org/slack.html>, it >>>> requires an @apache.org <http://apache.org/> email address to use which is >>>> quite limiting which is why these (and many other) OSS projects are using >>>> the free-tier Slack >>>> It does require managing Slack properly as Slack free edition limits you >>>> to approx 100 invites. One of the ways to resolve this is to create a >>>> bit.ly <http://bit.ly/> link so we can manage the invites without >>>> regularly updating the website with the new invite link. >>>> Are there any other points of discussion that we should add here? I'm >>>> glad to work with whomever to help manage the various aspects of Slack >>>> (code of conduct, linen.dev <http://linen.dev/> and search/archive >>>> process, invite management, etc.). >>>> >>>> HTH! >>>> Denny >>>> >>>> >
