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