If it’s up to me, I’m definitely in favor of switching to GitHub Issues.
KP On Thu, Feb 19, 2026 at 10:27 PM Vilius Šumskas via dev < [email protected]> wrote: > Nice! > > Will all old Jira issues be migrated to GitHub too? > > Also, I'm wondering, how "stale" issues will be managed? I would hate to > see those bots automatically closing issues if they are "inactive". I > understand that sometimes there is a need to manage a backlog, but this > doesn't allow "voting" on issues with likes or other means of activity > other than "me too, please reopen" comments. > > -- > Best Regards, > Vilius > > -----Original Message----- > From: Jean-Baptiste Onofré <[email protected]> > Sent: Thursday, February 19, 2026 6:42 PM > To: [email protected]; [email protected] > Subject: GitHub Issues & Discussions enabled > > Hi folks, > > We are pleased to announce that GitHub Issues & Discussions. > > 1. GitHub Issues (https://github.com/apache/activemq/issues) > Jira is now read-only and we should now all use GitHub Issues. > > We have the following labels available: > - bug: for bug reports > - dependencies: for dependencies updates > - enhancement: for improvements on existing code > - feature: for a complete new features > - proposal: for a design proposal, big features > - stale: when the issue is "inactive" for more than 60 days > > Please use these labels to classify the issues. > > When you create a PR, you can associate it with an issue either in the > GitHub UI or using "This closes #xxxx" in the comments. > I also suggest using conventional commit messages in PR with the format > <type>(<scope>): <subject> where scope is optional. The type can be: > - feat: (a new feature is introduced with the changes) > - fix: (bug fix has occurred, not a fix to a build script) > - docs: (changes to the documentation) > - style: (formatting, missing semicolons, etc; no production code change) > - refactor: (refactoring production code, eg. renaming a variable) > - test: (adding missing tests, refactoring tests; no production code > change) > - chore: (changes that do not relate to a fix or feature and don't modify > src or test files (for example updating dependencies or change in > production code)) > - perf – (performance improvements) > - ci – (continuous integration related) > - build – (changes that affect the build system or external dependencies) > - revert – (reverts a previous commit) > That's a nice practice because GitHub can use that to create nice Release > Notes. > Thanks to that, it's not necessary to create GH issues for all changes. > > For versions, we are using GitHub Projects ( > https://github.com/apache/activemq/projects?query=is%3Aopen). > You can assign several projects/versions per issue, and track the status > of the versions. > > 2. GitHub Discussions > We also enabled GitHub Discussions where we can have technical discussions. > The GH Discussions are automatically going to the dev@ mailing list. > > Let us know if you have any questions. > > Regards > JB >
