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