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