I would try exporting existing open issues from JIRA, we can then measure their actual impact.
Regards Aman On Tue, 3 Nov, 2026, 5:31 pm Aman Mittal, <[email protected]> wrote: > Oops, 😬 sorry about that. Will keep that in mind. > > On Tue, 3 Nov, 2026, 5:27 pm Ádám Sághy, <[email protected]> wrote: > >> Sorry for being slow to respond. >> >> Since someone who is working extensively with Fineract JIRA, i would be >> happy if we are ditching it and use github issues instead. >> >> Managing the JIRA user request, approve them, set the assignee, >> resolution, etc… its such a waste of time… and simply just a struggle… >> >> I would favor if we are moving to github issues and AI can migrate over >> open stories easily… >> >> This is my 2 cents.. >> >> Adam S >> >> P.S.: Please dont close *abandoned* stories as “fixed”! >> >> On Nov 3, 2026, at 7:09 AM, James Dailey <[email protected]> wrote: >> >> Thanks >> >> That's very useful work >> >> +1. >> >> >> Sent from Gmail Mobile >> >> On Mon, Nov 2, 2026 at 10:59 PM Aman Mittal <[email protected]> >> wrote: >> >>> Some tickets I have closed may be genuine. Or they may need reopening. >>> Just drop a message in the dev list in case of reopening. Some are at least >>> 4+ years old. >>> Regards >>> Aman >>> >>> On Tue, Nov 3, 2026 at 12:02 PM Aman Mittal < >>> [email protected]> wrote: >>> >>>> Hi James, Victor >>>> >>>> I will drop github issues for now. >>>> >>>> I am currently cleaning up the existing JIRA, another thing i am >>>> observing that People are creating Tickets based on Functional requirements >>>> without discussing them in dev list so closing any inactive tickets with >>>> message "Closing this. Please reopen after discussing requirement in dev >>>> list". >>>> >>>> It would direct many inactive tickets to discussions. >>>> >>>> Regards >>>> Aman >>>> >>>> On Tue, Nov 3, 2026 at 11:42 AM James Dailey <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> Sent from Gmail Mobile >>>>> >>>>> On Mon, Nov 2, 2026 at 10:01 PM VICTOR MANUEL ROMERO RODRIGUEZ < >>>>> [email protected]> wrote: >>>>> >>>>>> Agree with Aleks and James >>>>>> >>>>>> I think that we should stay using Jira, that is the reason that there >>>>>> is a PR title /Commit description naming convention for linking them to >>>>>> the >>>>>> Jira ticket automatically. >>>>>> Migrating to Github adds unnecessary management effort. >>>>>> Jira tickets should be marked as stalled and closed as unresolved >>>>>> after a period of time. >>>>>> >>>>>> However, nowadays it is hard to "stopping people from creating >>>>>> tickets until they've actually spent some time on the project"... Person >>>>>> can be a developer that has been working for a >>>>>> professional/weekend/security research project... or they can use a Code >>>>>> Agent. And if we add bureaucracy, people will not be motivated to >>>>>> contribute. There should be a fair balance... >>>>>> >>>>> >>>>> Oh I know. Its a key frustration. >>>>> >>>>> >>>>>> Regards >>>>>> >>>>>> Victor. >>>>>> >>>>>> >>>>>> El lun, 2 nov 2026 a las 10:36, Aman Mittal (< >>>>>> [email protected]>) escribió: >>>>>> >>>>>>> Thanks, James. >>>>>>> >>>>>>> I agree on the discipline issue here, but I have some questions >>>>>>> about this. (I read yours after sending my previous mail). >>>>>>> >>>>>>> How should we decide if a contributor is allowed to create tickets >>>>>>> on this? (I'm not asking about the GitHub issue right now). >>>>>>> >>>>>>> Also how should we enforce this? (Maybe we can create a precommit >>>>>>> check for this). If a specific ticket is not discussed with the dev >>>>>>> list, >>>>>>> should we not review it? >>>>>>> >>>>>>> I would agree to anything that can decrease one step in the release >>>>>>> process. >>>>>>> >>>>>>> Regards >>>>>>> Aman >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, 2 Nov, 2026, 9:35 pm James Dailey via dev, < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I agree w Aleks on this. It's not the tooling of Jira that's the >>>>>>>> problem. While I think we should be welcoming, there's a point where >>>>>>>> it's >>>>>>>> just a mess. >>>>>>>> >>>>>>>> I'll go further than Aleks: >>>>>>>> >>>>>>>> The problems come from a lack of adherence to expectations and >>>>>>>> norms. We've published these a checklists and wiki pages but, >>>>>>>> apparently >>>>>>>> "asking nicely" is failing. Maybe we need better enforcement >>>>>>>> mechanisms. >>>>>>>> >>>>>>>> ..., as examples: >>>>>>>> Stop creating tickets until you've actually spent some time on the >>>>>>>> project. >>>>>>>> >>>>>>>> If you're not going to stick around to answer questions about a >>>>>>>> ticket at a minimum, then don't bother - we do NOT need your "drive by" >>>>>>>> input. >>>>>>>> >>>>>>>> Ruleset - close any ticket over three months old with no comments, >>>>>>>> no action, no discussion. >>>>>>>> >>>>>>>> >>>>>>>> Checklists should be deterministic and encoded. Did you tag a >>>>>>>> "catch all ticket?" (More than x number of commits by y number of >>>>>>>> devs) >>>>>>>> then PR rejected. >>>>>>>> >>>>>>>> I'd prefer to block PRs that fail a meaningful and distinct set of >>>>>>>> conditions. >>>>>>>> >>>>>>>> Jira isn't required by ASF but it is preferred. It should remain >>>>>>>> ours and we need some controls or someone reviewing tickets - another >>>>>>>> good >>>>>>>> place to volunteer. >>>>>>>> >>>>>>>> James >>>>>>>> >>>>>>>> Sent from Gmail Mobile >>>>>>>> >>>>>>>> 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 >>>>>>>>> ). >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Aleks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 2, 2026 at 3:32 PM Aman Mittal < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am seeing the lack of replies. I propose that we should drop >>>>>>>>>> creating issues in JIRA and shift to GitHub issues. That way we can >>>>>>>>>> get red >>>>>>>>>> of creating and approving JIRA accounts of new contributors. And we >>>>>>>>>> can >>>>>>>>>> also auto close the issues as soon as it gets merged. >>>>>>>>>> >>>>>>>>>> Looking forward to your feedback. And as this directly impact the >>>>>>>>>> existing process so just waiting for community feedback on this. >>>>>>>>>> (Maybe it >>>>>>>>>> can be a FSIP) and may need voting. >>>>>>>>>> >>>>>>>>>> PS. : I forgot to ask why are we using JIRA to begin with? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Aman >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, 29 Oct, 2026, 10:34 pm Aman Mittal, < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> I want to share few concerns regarding the usage of JIRA during >>>>>>>>>>> the release process. I think a lot of things and contributions are >>>>>>>>>>> duplicated and scattered across different areas. Github for PR >>>>>>>>>>> review, jira >>>>>>>>>>> for tracking issues and then dev list for discussions. >>>>>>>>>>> >>>>>>>>>>> Currently, several aspects of JIRA usage are slowing down our >>>>>>>>>>> processes. >>>>>>>>>>> >>>>>>>>>>> 1. New Contributor Onboarding - As the project grows within the >>>>>>>>>>> community, many contributors are requesting JIRA account approval, >>>>>>>>>>> and I >>>>>>>>>>> think PMC members are currently approving those manually. >>>>>>>>>>> >>>>>>>>>>> 2. Tracking and referencing them for closure - During part of >>>>>>>>>>> release process. One of the crucial step of release process >>>>>>>>>>> documented at >>>>>>>>>>> https://fineract.apache.org/docs/develop/#_release_process is >>>>>>>>>>> to freeze JIRA and cleanup the JIRA for include issues that are >>>>>>>>>>> merged for >>>>>>>>>>> the specific release. As JIRA issues gets piled up and need to >>>>>>>>>>> manually >>>>>>>>>>> review each linked PR and close them. (This is one of the longer >>>>>>>>>>> steps) >>>>>>>>>>> >>>>>>>>>>> 3. After the release vote period, both JIRA and GitHub need >>>>>>>>>>> updating. >>>>>>>>>>> >>>>>>>>>>> I wanted to start a discussion so we can make this process more >>>>>>>>>>> efficient. I think it is the right time to discuss this as we are >>>>>>>>>>> finishing >>>>>>>>>>> up the current release vote. >>>>>>>>>>> >>>>>>>>>>> I wanted to hear what the community thinks about this before >>>>>>>>>>> proposing anything. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Aman >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>
