Hey Aman, James, Fineract crew, Chipping in because I actually went through kinda similar headache "once upon a time" when migrating from a 3rd party customer support ticket system and TFS *TO* GitHub. James is right—the last thing we want is to drag dead tickets into a new GitHub setup and clutter the active backlog. At the same time, Aman's dump shows that moving is doable mechanically. We could satisfy both worlds if we choose. To memory, GitHub doesn't have a literal "Archive" folder for open stuff, but here is how we handled: *ONLY* migrate tickets that have actually seen a pulse (activity) in the last 12(?) months. The rest leave behind in Jira / mass-close. On import, import with a legacy tag and mark as closed. This way, there SHOULD BE no need of referencing back to JIRA. When / IF (there will be time someone will want to look at the archive), the archive is needded, it will be on GitHub. Support setting a strict activity cutoff date so minimize the clutter, create a "closed GitHub archive", then let the really old stuff RIP. Paul Christison
On Wed, Nov 4, 2026 at 9:20 AM James Dailey <[email protected]> wrote: > Aman - What Wait?! I'm against migration to GitHub issues. I think by > comments most PMC members are against this as unnecessary. > > I'm trying to understand what you're doing by readying an export. > > Also even if we migrated we wouldn't want to carry the old useless tickets > with us. > > > > > Sent from Gmail Mobile > > On Wed, Nov 4, 2026 at 1:23 AM Aman Mittal <[email protected]> > wrote: > >> Sharing a dump of all fineract open issues, >> >> >> https://docs.google.com/spreadsheets/d/1ltCORaSdRae1pDJgkuBojWT84RRJQRpk/edit?usp=sharing&ouid=117155276075421962367&rtpof=true&sd=true >> >> 425 open tickets are there, (I will ignore the recently created ones and >> created by pmc members). I can see some old tickets and tags like >> "RoadMap2022" old GSOC ticket (before 2026 ones). I think migration is >> feasible. >> >> PS. this should be public link(pls reply if cannot access). Given that >> there are not much open issues. Just need to confirm their use case. >> >> >> Regards, >> Aman >> >> On Tue, Nov 3, 2026 at 10:09 PM Adam Monsen <[email protected]> wrote: >> >>> 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 >>>> ). >>>> >>> -- -- Paul
