Not sure JIRA->GH migration is necessary. Could just leave JIRA active but disallow new issues, use GH for only new issues.
re: PR checklist - I think this is useless after the first couple commits. re: sub-tasks - maybe? Depends on what kind of proj mgmt / roadmap / timeline is followed (if any). re: commit conventions: +1, that sounds useful On Mon, Nov 2, 2026 at 7:29 AM Aleksandar Vidakovic < [email protected]> wrote: > ... and then we migrate all open Jira tickets to Github? Is this really > worth the effort? If (one of) the reason(s) for this the approval process > for new accounts: is the problem really how fast we approve new > contributors? I see maybe a handful of account creation requests a week... > and: there is a reason why this process exists, people are bored out of > there mind (it seems) and create tons of spam accounts... which - I think - > is nowadays even more of an issue with all these drive-by-contributors (one > contribution, some of them don't even take the time to wait for their PR to > be reviewed and/or don't bother to respond to questions when it turns out > that they didn't read instructions)... not sure if I see how's that better > on Github? Some if not all of the housekeeping you describe in your first > email will probably also be required on Github unless there are some magic > features that I'm not aware of. This is especially true, because of the way > we process tickets. The Github PR (and as a result the commit message) is > usually pretty "anemic", it contains the usual check list of rules we have > to follow (not sure if we really have to do this... people usually just > blindly tick off these things... if we want or not) and if we are lucky the > PR title (first line of the commit message) is more or less descriptive; > but even with that I see people more and more re-using the same ticket over > and over again, because they are probably working on a longer story... but > why not chop this up in smaller sub-tasks under the original parent ticket > (at least)? As a result our changelog effectively becomes a list of Jira > tickets with limited (or no) value to end-users when it comes to > understanding what is new, what got fixed, what breaks compatibility. The > end-users can't just have a look at the changelog to get an idea what got > into our releases... but instead go ticket number by ticket number and > search Jira (I doubt that anyone is doing this... or very few people). > > What really would make life easier during releases: proper commit > conventions like https://www.conventionalcommits.org/en/v1.0.0/ or > https://commitizen-tools.github.io/commitizen/ then we could use e.g. > https://git-cliff.org/ or similar tools (all examples here from memory, > no preference) and releases would be based on the git log itself, no other > system required (neither Jira nor Github issues). For that to happen we > would need to apply a bit more discipline with the commit messages (how > many times do we still remind people to author their PRs properly with > "FINERACT-1234: Lorem Ipsum..."?), maybe write-up a little summary of the > ticket and give the reader some real information; that being said, pretty > sure there are linting tools out there that could be used to remind people. > The current git log structure we have is not in shape to use these tools... > we have just too many log patterns (sometimes "FINERACT-XXXX" prefixed, > sometimes "Merge pull request #XXXX from..." prefixed). > > As for why we use Jira to begin with: it's Apache's default (required?) > issue tracker (see: > https://www.apache.org/foundation/faq#you-have-issues-bug-reports-patches-for-a-particular-project > ). >
