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