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