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