People used to have trouble joining the ASF Slack workspace, here is a
related discussion, https://github.com/apache/iceberg/issues/1804. We'd not
go that route.

Created a new Slack workspace for Polaris (https://apache-polaris.slack.com).
Please follow this link to join,
https://join.slack.com/t/apache-polaris/shared_invite/zt-2w1fddyh3-zqCeeJwn7wNvhn3mVT5njQ
.


Yufei


On Thu, Dec 12, 2024 at 5:30 AM Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi,
>
> The ASF slack is by invitation, but a committer or PPMC member can
> invite anyone.
>
> We have a bunch of invited people on The ASF Slack (without @a.o email
> address).
>
> For me, it's weird to have another Slack workspace (my Slack client
> already has too much ;) ), we are a ASF project after all :)
>
> As said in a previous message, everything is fine to me as long as it
> helps the community. If you think it's better to have a dedicated
> Slack workspace that's OK.
>
> Regards
> JB
>
> On Thu, Dec 12, 2024 at 11:27 AM Ajantha Bhat <ajanthab...@gmail.com>
> wrote:
> >
> > Hi JB,
> >
> > Based on my experience, ASF slack is good only if you have an apache
> email
> > address.
> > If the users are not having apache email addresses, we have to add them
> > individually by their email address.
> > There is no invite link concept for users to join (
> > https://infra.apache.org/slack.html) to avoid spamming.
> > Also, it will be just a single channel per project, there can't be
> multiple
> > channels.
> >
> > I prefer separate slack workspace. Maybe a paid version as I observed
> that
> > users ask the same questions, keeping history discussions will definitely
> > be useful.
> >
> > - Ajantha
> >
> >
> >
> > On Thu, Dec 12, 2024 at 3:16 PM Jean-Baptiste Onofré <j...@nanthrax.net>
> > wrote:
> >
> > > Hi Yufei,
> > >
> > > I don't think we should create a new Slack workspace. I would rather
> > > prefer to have a channel on The ASF Slack.
> > >
> > > Regards
> > > JB
> > >
> > > On Thu, Dec 12, 2024 at 2:02 AM Yufei Gu <flyrain...@gmail.com> wrote:
> > > >
> > > > Hi Folks,
> > > >
> > > > Thanks a lot for all the feedback. The majority seems to favor Slack.
> > > > Some prefer Zulip. I feel like it’s worth giving Slack a try as an
> > > > alternative to Zulip. If everything works well, we can continue with
> > > Slack,
> > > > and even promote it to be the only one in the future. If it turns
> out not
> > > > working well, we can deprecate it. We can always ask people in the
> > > Iceberg
> > > > Slack channel to switch to Polaris workspace. The migration cost for
> them
> > > > would be minimal.
> > > >
> > > >
> > > > I will create a Slack workspace if you think it's worthwhile.
> > > >
> > > > Yufei
> > > >
> > > >
> > > > On Mon, Dec 9, 2024 at 12:03 PM Eric Maynard <
> eric.w.mayn...@gmail.com>
> > > > wrote:
> > > >
> > > > > While it's true that there is substantial activity on Zulip, I
> think
> > > the
> > > > > fact that we have a decent amount of community engagement on Slack
> in
> > > spite
> > > > > of the fact that Zulip is currently the official platform linked
> to on
> > > the
> > > > > site means that people probably do prefer Slack.
> > > > >
> > > > > Personally I do not have a preference between Zulip and Slack, but
> my
> > > > > suspicion is that Slack is more end-user friendly as the typical
> > > > > developer is more likely to already have Slack set up than Zulip.
> > > > >
> > > > > --EM
> > > > >
> > > > > On Sun, Dec 8, 2024 at 10:31 PM Jean-Baptiste Onofré <
> j...@nanthrax.net>
> > > > > wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > I don’t have a strong opinion. I’m mixing Zulip (for camel and
> > > Polaris)
> > > > > > with slack (for other project). I have a preference to Slack if
> we
> > > use
> > > > > the
> > > > > > ASF slack server (not a dedicated server like Iceberg or
> cloudstack).
> > > > > >
> > > > > > My preference doesn’t matter: the most important is what’s the
> best
> > > for
> > > > > the
> > > > > > community (for both communication and growth).
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > Le dim. 8 déc. 2024 à 00:18, Russell Spitzer <
> > > russell.spit...@gmail.com>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > I really dislike Zulip. I find it hard to use and for me all my
> > > other
> > > > > > chats
> > > > > > > I have to belong to are Slack for example ASF Slack and most
> > > > > importantly
> > > > > > > for Polaris, the Iceberg slack. I originally didn’t have strong
> > > > > > objections
> > > > > > > because I hadn’t used Zulip and I was willing to try it out,
> but I
> > > > > > probably
> > > > > > > should have objected since I really didn’t understand how
> > > different it
> > > > > > was
> > > > > > > from slack. If we had another vote now I would be a strong -1
> for
> > > > > > anything
> > > > > > > but Slack given that a majority of our users are going to also
> be a
> > > > > > members
> > > > > > > of the Iceberg community so we probably shouldn’t force two
> chat
> > > apps.
> > > > > I
> > > > > > > think Polaris channel within the iceberg slack is a nice
> stopgap
> > > (which
> > > > > > for
> > > > > > > reference already has 155 members) but it would be better have
> a
> > > full
> > > > > > > fledged Slack instance.
> > > > > > >
> > > > > > > On Sat, Dec 7, 2024 at 12:32 PM Robert Stupp <sn...@snazy.de>
> > > wrote:
> > > > > > >
> > > > > > > > If monitoring the Polaris channel in Iceberg slack is too
> much
> > > work
> > > > > (I
> > > > > > > > personally don’t monitor it), then we should direct users to
> the
> > > > > > official
> > > > > > > > Apache Polaris Zulip chat.
> > > > > > > >
> > > > > > > > There were no strong objections against Zulip particularly
> strong
> > > > > > > > arguments for Slack voiced during the initial discussion [1]
> nor
> > > in a
> > > > > > > > related discussion & vote [2]. I don’t think that it’s a good
> > > idea to
> > > > > > > > change the project’s official chat after just a couple of
> weeks,
> > > > > > > especially
> > > > > > > > not after a few hundred users joined.
> > > > > > > >
> > > > > > > > I personally prefer Zulip over Slack, because of it’s clear
> view
> > > even
> > > > > > on
> > > > > > > a
> > > > > > > > lot of parallel conversations (topics) that works fine for a
> lot
> > > of
> > > > > > other
> > > > > > > > really big OSS projects (Rust, Asciidoctor, Quarkus, Wildfly
> and
> > > a
> > > > > > couple
> > > > > > > > Apache projects as well). For new users it’s very easy to
> join,
> > > as it
> > > > > > > does
> > > > > > > > not require an invitation (hello Slack). Another chat systems
> > > just
> > > > > adds
> > > > > > > > (IMHO mostly unneeded) feature over feature. Zulip is stable
> on
> > > Linux
> > > > > > and
> > > > > > > > macOS and offers a web interface for those that don’t want to
> > > install
> > > > > > an
> > > > > > > > application. Hosted Zulip itself has been very supportive of
> open
> > > > > > source
> > > > > > > > projects in the past years. They’re also very communicative
> in
> > > their
> > > > > > own
> > > > > > > > OSS Zulip chat - not sure how that works with another
> service.
> > > > > > > >
> > > > > > > > Retention is important in an Apache project - *especially*
> when
> > > it
> > > > > > > > potentially becomes eligible to decision making. This is
> another
> > > > > point
> > > > > > > > where Zulip excels over Slack.
> > > > > > > >
> > > > > > > > Robert
> > > > > > > >
> > > > > > > >
> > > > > > > > [1] https://github.com/apache/polaris/discussions/14
> > > > > > > > [2]
> > > https://lists.apache.org/thread/hz7g7t01hxvd9kgdjo81qy5hd9y1zols
> > > > > > > >
> > > > > > > > > On 7. Dec 2024, at 05:37, Michael Collado <
> > > collado.m...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > I imagine we’d replace the Iceberg Polaris channel with a
> > > Polaris
> > > > > > Slack
> > > > > > > > > workspace. Then we’d be down one channel and all the chat
> > > > > > notifications
> > > > > > > > > would be integrated with the other Slack notifications we
> get.
> > > In
> > > > > > > > addition
> > > > > > > > > to Iceberg, I also have a couple of other open source
> project
> > > > > > > workspaces
> > > > > > > > > open and it makes keeping up with comms a bit simpler since
> > > all the
> > > > > > > > > notifications are batched together.
> > > > > > > > >
> > > > > > > > > Mine
> > > > > > > > >
> > > > > > > > > On Fri, Dec 6, 2024 at 4:28 PM Dmitri Bourlatchkov
> > > > > > > > > <dmitri.bourlatch...@dremio.com.invalid> wrote:
> > > > > > > > >
> > > > > > > > >> Hi Michael,
> > > > > > > > >>
> > > > > > > > >> I guess replacing Zulip with an Apache Polaris slack
> channel
> > > is
> > > > > not
> > > > > > > > going
> > > > > > > > >> to reduce the number of communication channels :)
> > > > > > > > >>
> > > > > > > > >> Are you suggesting to drop Zulip and use the polaris
> channel
> > > in
> > > > > the
> > > > > > > > Iceberg
> > > > > > > > >> slack workspace?
> > > > > > > > >>
> > > > > > > > >> Thanks,
> > > > > > > > >> Dmitri.
> > > > > > > > >>
> > > > > > > > >> On Fri, Dec 6, 2024 at 3:42 PM Michael Collado <
> > > > > > > collado.m...@gmail.com>
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >>> Currently, the communication channels for Polaris include
> > > > > > > > >>>
> > > > > > > > >>> Mailing list
> > > > > > > > >>> Iceberg Slack
> > > > > > > > >>> GitHub
> > > > > > > > >>> Zulip
> > > > > > > > >>>
> > > > > > > > >>> These are in addition to the regular comm channels I
> have to
> > > keep
> > > > > > up
> > > > > > > > with
> > > > > > > > >>> in a given day. I think something’s gotta give.
> > > > > > > > >>>
> > > > > > > > >>> We can’t get rid of the mailing list or GitHub and I’m
> > > already in
> > > > > > > slack
> > > > > > > > >> all
> > > > > > > > >>> day every day anyway and given that Zulip is _only_ ever
> > > used for
> > > > > > > > >>> occasional user questions…
> > > > > > > > >>>
> > > > > > > > >>> I like open source projects, but… I can’t do it all.
> > > > > > > > >>>
> > > > > > > > >>> Mike
> > > > > > > > >>>
> > > > > > > > >>> On Fri, Dec 6, 2024 at 11:56 AM Dmitri Bourlatchkov
> > > > > > > > >>> <dmitri.bourlatch...@dremio.com.invalid> wrote:
> > > > > > > > >>>
> > > > > > > > >>>>> 2. *Performance and Stability*:
> > > > > > > > >>>>
> > > > > > > > >>>> I personally use Zulip Desktop on Linux and the Zulip
> App
> > > on my
> > > > > > > phone
> > > > > > > > >> and
> > > > > > > > >>>> do not recall any serious performance and stability
> > > problems.
> > > > > > > > >>>>
> > > > > > > > >>>> There was one event a long time ago, when a new desktop
> > > client
> > > > > > > version
> > > > > > > > >>>> became unusable, but it was solved quickly with a patch
> > > > > > version....
> > > > > > > > >> IIRC.
> > > > > > > > >>>>
> > > > > > > > >>>> Cheers,
> > > > > > > > >>>> Dmitri.
> > > > > > > > >>>>
> > > > > > > > >>>> On Fri, Dec 6, 2024 at 1:26 PM Yufei Gu <
> > > flyrain...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >>>>
> > > > > > > > >>>>> Hi Folks,
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> I’d like to propose transitioning our chat platform
> from
> > > Zulip
> > > > > to
> > > > > > > > >>> Slack.
> > > > > > > > >>>>> While both platforms have their strengths, I believe
> Slack
> > > > > > offers a
> > > > > > > > >>> more
> > > > > > > > >>>>> robust and widely adopted solution for our needs.
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> *Why Consider Slack?*
> > > > > > > > >>>>>
> > > > > > > > >>>>>   1. *Broader Adoption*: Slack is widely used across
> > > > > > organizations,
> > > > > > > > >>>> making
> > > > > > > > >>>>>   it easier for new members or collaborators to join
> and
> > > chat
> > > > > > > > >>>> seamlessly.
> > > > > > > > >>>>>   2. *Performance and Stability*: Slack consistently
> > > > > outperforms
> > > > > > > > >> Zulip
> > > > > > > > >>>> in
> > > > > > > > >>>>>   terms of reliability. I’ve experienced occasional
> crashes
> > > > > with
> > > > > > > > >> Zulip
> > > > > > > > >>>> on
> > > > > > > > >>>>> my
> > > > > > > > >>>>>   laptop, which can disrupt productivity.
> > > > > > > > >>>>>   3. *Retention Period*: Slack provides a shorter
> retention
> > > > > > period
> > > > > > > > >> for
> > > > > > > > >>>>>   chat history. However, this should suffice as chat
> tools
> > > are
> > > > > > > > >>> primarily
> > > > > > > > >>>>> used
> > > > > > > > >>>>>   for quick responses. For more formal communication,
> such
> > > as
> > > > > > > > >>> proposals,
> > > > > > > > >>>>>   release votes, or other critical discussions, we will
> > > > > continue
> > > > > > to
> > > > > > > > >>>>>   prioritize the use of email lists.
> > > > > > > > >>>>>
> > > > > > > > >>>>> *Proposed Transition Plan*
> > > > > > > > >>>>>
> > > > > > > > >>>>>   - *Gradual Rollout*: We can implement Slack alongside
> > > Zulip
> > > > > > for a
> > > > > > > > >>>>>   transition period of 3 months. This allows team
> members
> > > to
> > > > > > adapt
> > > > > > > > >> and
> > > > > > > > >>>>>   provide feedback before fully committing.
> > > > > > > > >>>>>   - *Historical Access*: We don’t need to shut down the
> > > Polaris
> > > > > > > > >> Zulip
> > > > > > > > >>>>>   instance. Keeping it active ensures historical chat
> data
> > > > > > remains
> > > > > > > > >>>>> accessible
> > > > > > > > >>>>>   for future reference.
> > > > > > > > >>>>>
> > > > > > > > >>>>> I’d love to hear your thoughts on this proposal. If
> there’s
> > > > > > > > >> interest, I
> > > > > > > > >>>> can
> > > > > > > > >>>>> take the lead on outlining next steps, including
> setting up
> > > > > Slack
> > > > > > > and
> > > > > > > > >>>>> ensuring a smooth transition for the team.
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> Looking forward to your feedback!
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> Yufei
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
>

Reply via email to