I revised section 7 to try and make the intended split between the tactical (GitHub) and strategic (dev ML) more clear: > 7. Issue tracking, technical discussions, and code review: move to GitHub > > This CEP *formally proposes that **`cassandra-ecosystem`** use GitHub Issues, > GitHub Discussions, and GitHub Pull Requests* as its tracker, discussion > forum, and code-review surface - rather than creating a new JIRA project (the > previously-floated `CASSECO`). Discussion on github should be constrained to > tactical / technical topics (feature design, implementation, testing, etc). > For strategic topics (project governance, roadmap, architecture, releases, > etc) discussion should be kept to the dev ML. > Rationale: > • It keeps issues, technical discussions, code review, and code in one > place, lowering friction for the external contributors and downstream > consumers who already interact with these projects via GitHub. > • When we moved from code collaboration happening in JIRA comments to > happening in github PR’s years ago, our discussion around work fragmented. > The majority of that discussion already happens in github on PR’s; if we move > to using github discussions, projects, milestones, and centralize our project > management in github, we will have a more modern, feature-rich, and > interconnected platform for people to collaborate on. > • The vast majority of the industry and thus new contributors to the > cassandra ecosystem will be familiar with github; having to split their > workflows between github and JIRA presents a hurdle on both integrating with > the community and on longer-term collaboration. > • A brand-new repository is the natural, low-cost moment to adopt this > workflow; there is no legacy of in-flight JIRA process to disrupt within the > new repo. > • GitHub Discussions gives design conversations a durable, searchable home > (the `[DISCUSS]` mailing-list thread still governs the *CEP* process and is > used for the official system-of-record; Github discussions complement it for > implementation-level design). • Note: all strategic project level > discussions (architecture, roadmap, releases, etc) should happen on the dev > list. The intent is to have tactical discussions (implementation, technical > details, etc) centralized in one location > • All conversation on GitHub will be reflected to a mailing list using > notifications
On Sun, Jul 5, 2026, at 8:42 AM, Mick wrote: > > > > On 5 Jul 2026, at 14:37, Mick <[email protected]> wrote: > >> On 30 Jun 2026, at 19:38, Brandon Williams <[email protected]> wrote: > >> On Tue, Jun 30, 2026 at 12:18 PM Josh McKenzie <[email protected]> > >> wrote: > >>> > >>> So. In case this triggers anything for anyone, figured I'd raise it here. > >>> :) > >> > >> I do worry that moving discussion from ASF-controlled infrastructure > >> to Microsoft-controlled infrastructure will prove to be unwise in the > >> future. > > > > > > > > This is in a way a hard requirement from the ASF. > > All decision making must be _recorded_ on ASF-controller infrastructure. > > > > It is solved by sending all notifications to a mailing list. > > e.g. we can create a new read-only mailing list we all ecosystem > > discussions are copied to. > > > > This is why all other github activities are being sent to a ml, and which I > > believe is enforced by the .asf.yml > > > > It would also be possible, as a number of other apache projects have done, > > to migrate all our existing sidecar and analytics jira tickets to github > > issues. > > > And all binding votes need to still happen on the mailing list, like releases. > > >
