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]
