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