Hm: what a quandary. I dont hate Slack since the only option I have dealt with is Teams. The question is one surface for all communications in a new platform or a split communication surface. The one platform means that a non committer has one place to see how the sausuage is made.
What do all think Walter > On Jul 2, 2026, at 11:10 AM, James Fredley <[email protected]> wrote: > > 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. >>
