I'm ok to proceed. We can also wait until the weekly to discuss further to ensure there's no one that disagrees.
On 2026/07/02 16:32:37 Søren Berg Glasius wrote: > James, that’s a really good point about the-asf.slack.com having a paid > tier with full history. Moving our Apache Grails committer-level and PMC > channels over there makes total sense from an administrative and security > standpoint, and we should definitely consider utilizing it for internal > discussions. > > However, as you noted, the guest restrictions mean it doesn’t solve our > primary issue: *our external developer ecosystem*. End-users wouldn't have > a self-service signup link, and managing invitations for thousands of > community members as "guests" would be an administrative nightmare. > > If we split the community, putting committers on ASF Slack and the public > on another platform, we risk fracturing our communication channels even > further. If we transition to Zulip, my preference would be to keep both > public support and committer/PMC collaboration in one unified, searchable > place. > > I agree with James D and Walther, that we get the Zulip sandbox up and > running first so we can evaluate it firsthand. > > Should I go ahead and do that? > > Den tors. 2. jul. 2026 kl. 18.10 skrev James Fredley < > [email protected]>: > > > some additional details for the discussion. > > > > the-asf.slack.com is not on the free plan like, https://grails.slack.com/. > > > > We should consider moving Apache Grails Committer level channels over > > there to receive full history and other features. > > > > Also on the-asf.slack.com: > > > > Non-Apache ID / end users (guests): Yes, they can join, but only as > > Guests. An existing full Member must invite them specifically to one or > > more channels. Guests have limited access — they can only see and > > participate in the channel(s) they were invited to. They cannot freely > > browse or join other channels. No public join link or self-service signup > > for guests. > > Guests are intentionally limited to the channels they are added to. > > > > James > > > > On 2026/07/02 11:09:42 Søren Berg Glasius wrote: > > > Hi everyone, > > > > > > Several PMC members (including myself, jdaugherty, jamesfredley, and > > > walter) and membmers of the Grails Slack community recently had a > > > discussion on Slack regarding the long-term viability of our community > > chat > > > infrastructure. I want to bring that discussion here to the wider dev > > list > > > to formalize a proposal. > > > The Problem > > > > > > We are currently hitting the ceiling of what Slack’s free tier can offer > > an > > > open-source project. The 90-day message retention limit means years of > > > critical technical troubleshooting, community onboarding, and > > architectural > > > context are permanently lost. While archive tools like > > > https://www.linen.dev/s/grails help, they are a band-aid solution. > > > Upgrading Slack is financially impossible for a community of our size. > > > The Proposal: Transition to Zulip > > > > > > I are proposing that the Grails community migrate its primary chat > > > operations to *Zulip*. > > > > > > *Why Zulip?* > > > > > > - > > > > > > *Full Searchable History:* Zulip sponsors open-source communities by > > > providing their Standard Plan for free, giving us an unrestricted, > > fully > > > searchable history. > > > - > > > > > > *Asynchronous-Friendly Threading:* Zulip’s topic-based threading model > > > acts like a hybrid between real-time chat and a mailing list, which is > > > significantly better suited for deep technical work than Slack's > > > chronological noise. > > > - > > > > > > *Hosting Options:* We can utilize Zulip’s hosted OSS plan or look into > > > self-hosting options (potentially via ASF infrastructure, which we can > > > raise at the roundtable). > > > > > > Addressing PMC Concerns (Community Retention) > > > > > > A major point of discussion from James Fredley is the risk of community > > > fragmentation. The Grails Slack currently shows ~4,600 members, and a > > > migration will inevitably result in a drop in total numbers. > > > > > > However, our actual *active* core is a fraction of that size. The > > thousands > > > of inactive accounts shouldn't block us from providing a superior, > > > persistent knowledge base for the developers who are actually here and > > > contributing. A smaller, highly active, and archived community is vastly > > > more valuable than a massive, silent one with a 90-day memory. We have a > > > complete list of members, and could send everyone a one-time-mail, > > > notifying them of the change. > > > Proposed Transition Strategy > > > > > > To minimize user loss, we would not do a hard cutover. Instead, we > > propose: > > > > > > 1. > > > > > > *A Phased Migration:* Keep the Slack workspace active for a 90-day > > > transition period. > > > 2. > > > > > > *Persistent Guardrails:* Set up automated, recurring pings in all > > major > > > Slack channels directing users to the new Zulip instance. > > > 3. > > > > > > *Data Import:* Explore importing our existing Slack/Linen history into > > > Zulip so we don't lose current context. > > > > > > Next Steps > > > > > > I would like to open this up for discussion here on the dev list, with > > the > > > goal of bringing a formalized plan to the next weekly roundtable meeting. > > > > > > Please share your thoughts, concerns, or objections. > > > > > > -- > > > > > > Best regards > > > Søren Berg Glasius > > > > > > Apache Groovy™ and Apache Grails® PMC > > > --- Press ESC once to quit - twice to save the changes. > > > > > > > > -- > > Med venlig hilsen, > Søren Berg Glasius > > Hedevej 1, Gl. Rye, 8680 Ry > Mobile: +45 40 44 91 88 > --- Press ESC once to quit - twice to save the changes. >
