+1 from my side for this proposal. i see no benefit in trying to migrate all JIRA issues to github issues, even if we find a way to match each of those issues to the github repo it belongs.
in JIRA, we may want to find a way to communicate why there is no "create" button any more - although most people will probably just naturally go for github issues, once we make this option available in github (currently, it's disabled there). stefan > -----Original Message----- > From: Carsten Ziegeler <[email protected]> > Sent: Thursday, October 1, 2026 4:42 PM > To: [email protected] > Subject: [RT] Switch to github issues > > At the Sling community roundtable I brought up the topic of cleaning up > our jira components (a thread I started before here) and this quickly > turned into a discussion on switching to github issues instead (which > would solve my concern as well). Reference notest at [1]. > > Other projects like Apache Maven have moved from Jira to GH issues as > well. So we could do the same. > > The immediate benefit is that the issues are close to code. > > While enabling GH issues is easy, it comes with some questions. The goal > here is to introduce this change with minimal effort, increasing the > burden to contribute must be avoided. > > a) Migration of issues from Jira? > > Do we need / want to migrate open or even all issues from jira to GH. > There is most likely no real benefit of doing so. Most open issues are > open for a long time and there are only a few which are really worked > on. So a on demand migration or copying over seems to be more appropriate. > > Instead, we can lock down Jira to prevent new issues to be created, but > still allowing to comment on existing issues. (Actually, we are > currently using a default permission scheme in Jira that does not allow > this, but we can ask Infra if that can be switched) > That way, we don't have to migrate tons of issues from the last decades, > a lot of them probably outdated or not easily matchable. > > b) Release Notes > > Right now, the release notes are based on jira issues. While we could do > the same with GH issues, the better approach is to base this on PRs > merged into it since the laste release. GH provides this out of the box. > > c) Require PRs > > With basing the release notes on PRs, the question is whether we require > a PR for every change? This does not seem necessary and simple changes > do not need to clutter the release notes. This is no change to what we > do today with Jira issues. > > d) Require Issues > > Similar, we will not enforce an GitHub issue to be created for every PR > - if the PR is simple and self-contained > > e) Issues spanning multiple repos > > If there is an issue that spans multiple repos, you have to create > multiple issues and link them. This is actually a cleaner way, > especially as releases of these modules are independently done. > > Thoughts? > > Regards > Carsten > > [1] > https://cwiki.apache.org/confluence/spaces/SLING/pages/451979035/Committer > +round+table+at+adaptTo+2026 > -- > Carsten Ziegeler > Adobe > [email protected]
