Hi James, Abhishek, Sujan, and everyone, Thank you, James, for laying out the current state of the community so clearly.
The growth numbers Adam shared are encouraging and the challenges you describe, open PRs waiting for review, the need for more active committers and mentoring and the risk of accumulating technical debt, are real and important to address thoughtfully. I particularly appreciate the emphasis on not backsliding on the discipline the project has built around the FSIPs. Keeping the codebase moving toward the newer patterns while still supporting the large amount of legacy code is a delicate balance. Abhishek’s two concrete suggestions feel like useful and low-risk starting points: 1. A Checkstyle rule that prevents new uses of the legacy command imports inside the packages already migrated under FSIP-5. 2. Expanding the core AGENTS.md (as Paul suggested) so that both human contributors and AI tools are directed to the current reference documentation and the intended patterns. These steps would give clearer signals to contributors and to any AI-assisted workflows without requiring a large new infrastructure effort up front. If the community agrees about the starting point... they should move forward and of course Aleksandar’s input on the rules would be valuable. On the broader points about mentoring and reviewer capacity: finding sustainable ways to ladder new contributors up and making the expected design and process guidelines more discoverable, seems essential if we want the recent influx of interest to translate into long-term committers rather than having stalled PRs. Looking forward to the discussion and to seeing how we can keep the project healthy as it grows. Best regards, Victor Romero El mar, 13 oct 2026 a las 0:48, James Dailey (<[email protected]>) escribió: > Yes exactly what I mean Abhishek > > > Sent from Gmail Mobile > > On Tue, Oct 13, 2026 at 12:08 AM Abhishek Chaudhary < > [email protected]> wrote: > >> Hi James, Victor, all, >> >> Victor I think James meant the IDE point literally. In the old command >> code, a request is linked to its handler only by text labels like "CLIENT" >> and "CREATE", matched while the app is running. So neither the IDE nor an >> AI agent can follow that link by reading the code and since 400+ handlers >> still use the old style vs 40ish on the new fineract-command one, the old >> style is what agents copy. >> >> Given Aleksandar's point in September [1] that AI reviewing AI code >> compounds errors and the rules need agreeing first, I'd like to start with >> two small things: >> >> 1. A Checkstyle rule that blocks legacy command imports in packages >> FSIP-5 has already migrated (11 packages would already pass), like the REST >> Assured baseline. >> >> 2. Grow the core AGENTS.md, as Paul suggested [2], to point agents at >> fineract-command/REFACTORING.md and the migrated reference features. >> >> Happy to open Jira tickets and PRs for both if there are no objections, >> with Aleksandar signing off on the rules. I can also help with first-pass >> reviews. >> >> Thanks, >> Abhishek >> >> [1] https://lists.apache.org/thread/lznsp9yr84g7c2sbmqks28jc12vynxs3 >> [2] https://lists.apache.org/thread/o3wp081gntybvp3cdvp47co6fk1fvfho >> >> On Tue, 13 Oct, 2026, 12:33 am Sujan, <[email protected]> wrote: >> >>> Hi James and everyone, >>> >>> I agree that maintaining code quality, meaningful reviews, and effective >>> mentoring is essential as the Fineract community grows. >>> >>> I am currently focused on completing the LOS work, particularly >>> security, authorization, and workflow correctness, while ensuring alignment >>> with Fineract's architectural direction and avoiding technical debt. >>> >>> I would also be happy to contribute to Back Office and consumer-facing >>> modules, where I have been more involved, while continuing to deepen my >>> understanding of the core Fineract codebase. I believe module-specific AI >>> skills and review guidelines could help contributors follow intended >>> patterns and avoid perpetuating legacy approaches. >>> >>> I look forward to contributing more broadly through code reviews, >>> documentation, and knowledge sharing as I continue learning the project. >>> >>> Thanks, >>> Sujan >>> >>> On Mon, 12 Oct, 2026, 23:25 James Dailey, <[email protected]> wrote: >>> >>>> All - >>>> >>>> By many measures our community is growing. As Adam Saghy showed in his >>>> presentation yesterday at the ASF Community Over Code conference (videos to >>>> come later we hope), we have accepted over 1300 pull requests from 134 >>>> unique humans in the core Fineract project over the past 21 months. >>>> >>>> We are seeing more people show up! >>>> >>>> A) **Need for reviewers*.* We currently have 195 open PRs lacking >>>> sufficient review. Without reviews, these PRs will remain open. We urge >>>> people with some experience to provide code reviews. This doesn't mean you >>>> do the commit, but you could earn some karma by doing reviews. >>>> >>>> B) **Poorly considered PRs*.* We see PRs that haven't been discussed >>>> on the list, aren't well described in Jira tickets, or miss the mark >>>> entirely on design or implementation. >>>> >>>> B1) These PRs might deserve outright rejection. If a PR hasn't >>>> followed our processes or isn't following guidelines and advice, any >>>> reviewer should push it back to the contributor to refactor and do it >>>> properly. Especially if they are auto-generated, we need a way to detect >>>> and reject. >>>> >>>> B2) We need more tooling to help these PRs become compatible and >>>> improve the project. >>>> >>>> C) **Not enough Committers*. *Fundamentally, we don't have enough >>>> *active* Committers who are reviewing the PRs. >>>> >>>> C1) From speaking to folks who are Fineract Committers, many won't >>>> be working on the project unless someone is paying their way. This is not >>>> a new dynamic in open source projects at the ASF, but it is a critical >>>> problem for us - new developers cannot become Committers without the >>>> laddering up and mentoring by Committers. PRs go stale and we lose new >>>> potential future Committers. >>>> >>>> C2) We really need a better mentoring approach. There is a real >>>> value in the mentoring concept for new devs - the merit involved in an open >>>> source project is valued by employers. >>>> >>>> D) **Avoiding increased code debt**. We have become far more >>>> disciplined over the past few years to NOT add code debt. We don't want to >>>> backslide. >>>> >>>> We have a structure around Financial Significant Improvement Projects >>>> (FSIP) for the core Fineract codebase: >>>> >>>> >>>> https://cwiki.apache.org/confluence/spaces/FINERACT/pages/340036085/FSIP-5+New+Command+Processing+Infrastructure >>>> >>>> <https://cwiki.apache.org/confluence/spaces/FINERACT/pages/340036085/FSIP-5+New+Command+Processing+Infrastructure> >>>> and >>>> >>>> https://cwiki.apache.org/confluence/spaces/FINERACT/pages/406621305/FSIP-6+Type+Safe+Native+SQL+Queries >>>> >>>> And advice/instructions buried in places in the code - e.g. >>>> https://github.com/apache/fineract/tree/develop/fineract-command >>>> <https://github.com/apache/fineract/tree/develop/fineract-command> >>>> >>>> ---- >>>> ***AI angle*** >>>> Using AI responsibly could involve creating a fineract-skills >>>> development concept that any contribution must pass through. This would be >>>> a type of review skill that allows us to judge PRs. If we can build that >>>> based on the patterns we want in the code, and the patterns we want to >>>> avoid, then that could help enormously in clearing up some of the code >>>> issues. >>>> >>>> Essentially, if we are getting many AI-generated PRs, then we need to >>>> use AI to review them. This is pretty common now in other projects FWIW. >>>> This also applies to security reports as well BTW. >>>> >>>> For example, the two FSIPs mentioned above are working toward paying >>>> down code debt - yet, if you point your LLM at the code, it will find the >>>> WRONG patterns - because we haven't finished cleaning that up yet. So we >>>> need a way to instruct and guide the developers using the LLMs. In LLM >>>> speak they need to be told that no, the old way is wrong. >>>> >>>> And this brings me to the importance of Tooling. One of the things that >>>> we need is for the tools to understand the Fineract code. The problem with >>>> the current structure of the code, is that the IDEs cannot fully understand >>>> our old patterns - this isn't my expertise but it does seem to resonate. >>>> See above. More on this ... but please discuss. >>>> >>>> Thanks, >>>> James >>>> >>>
