Hello, The number of PRs are 137 PRs - https://github.com/apache/fineract/pulls I have reviewed/merged some of them (they were related to OpenAPI). There are other tickets that are out of my scope, that must be reviewed by the peers that are working on them, which I think it is a best practice rather delegating the effor to the people that has lack of context, or maybe the Jira ticket must include the specs more detailed.
I do not get the point about IDES being unable to fully understand the old patterns... Do you mean AI Agents or AI tools like OpenCode, Codex, Copilot? If so this is because of the lack of agents, soul, skill per module. Regards El lun, 12 oct 2026 a las 11:55, James Dailey (<[email protected]>) escribió: > 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 >
