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 > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
