Ok. Sounds good. We *COULD* migrate via an export /import mechanism. Ok I am very reluctant to go this direction
Sent from Gmail Mobile On Wed, Nov 4, 2026 at 7:36 AM Aman Mittal <[email protected]> wrote: > Hi James, > > Just shared data in terms of transparency. Based on what results in the > end. (Weather we stick to it or not). > > I missed the adam monsens comment here about not need to migrate. > > Nothing be done here just answering the migration question. (If we were to > migrate.),again missed before posting. > > May seem unnecessary but tried answer all based on actual data. > > > > > > On Wed, Nov 4, 2026, 8:50 PM 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 >>>>> ). >>>>> >>>>
