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