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
