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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>
