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