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