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] > <mailto:[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] >> <mailto:[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] >>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> Sent from Gmail Mobile >>>> >>>> On Mon, Nov 2, 2026 at 10:01 PM VICTOR MANUEL ROMERO RODRIGUEZ >>>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 >>>>>>>>>> >>>>>>>>>>
