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 >
