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