... thanks James for kicking off the roadmap and the Jira cleanup. I think this will help a lot, both doing releases and managing Fineract users' expectations.
Concerning "best practices" for customizing Fineract with - hopefully - zero hassle version upgrades: we have currently one user kicking the tires of the solution we added this week (in develop) in a real world scenario and I will have a session with another one to bring a 1.5.0 fork (pre Liquibase and Postgres) with modest customizations on par with our latest release 1.8.0 (this will include rearranging the forked repo to prepare for frequent syncs with upstream Fineract and move their customizations to the "right" folders to avoid future conflicts). Will let you know how it goes (and update the docs if necessary). Cheers, Aleks On Sat, Oct 22, 2022 at 2:51 AM James Dailey <[email protected]> wrote: > Devs - > > I would like to share some thoughts on the development of a Roadmap, and > some proposals: > > 1. A roadmap is a collective activity to try to anticipate what work > can be done by the community of volunteers and to try to organize our > approach > 2. In an open source project, a good roadmap includes both what we > want to develop and what parts we do not want to develop (anti-roadmap) > 1. Anti-roadmap seeks to avoid feature-creep that muddy the > application > 2. Anti-roadmap in an open source project also provides the > "missing" components that vendors can then develop as a deeper solution. > > There are a number of companies using Fineract and running it in > production. At Apache Fineract, our goal is to allow for individuals to > make contributions. Those individuals are called "volunteers". Those > volunteers can be paid by their companies to do the development on the open > source project. But, individuals make contributions and work to ensure the > project is ideally developed. If your company is using Fineract but you are > not contributing, please consider why. > > My belief is that it is at least partly because it is far easier to hack a > solution for a near term solution than to take the better design approach. > This means that many implementations out there are on heavily customized if > not entirely forked projects. They are unable to contribute upstream > because they are hundreds of commits behind. > > This is a problem and our roadmap should be focused on this topic: How to > ensure a virtuous cycle of contribution through code approachability and > extensibility. > > In this direction, I call attention to the work around separating the > components into almost "composable" jar files as well as drop in java > classes. These probably need more development and to be highlighted for > devs. @Aleksandar Vidakovic <[email protected]> is leading much of this. > > To ensure that our development processes and priorities are understandable > we also need to limit the number of open tickets as a first step: > > - We are closing old tickets (more than 2 years old) to ensure we are > focussed on the right things and to let go of things we don't need or for > which there is no one to do the development. We may pick a few items from > that list of old tickets. > > To ensure that the project quality is enhanced continuously, I think we > need better test coverage across the board. At a minimum as mentioned in > the thread about commits. (Review then Commit), we should not > accept commits without sufficient test coverage. > > Proposed priority #1 and #2: > > 1. Fix the "build on top of" and maintainability of the project , > enabling outside vendors to stay upstream while giving them flexibility to > do custom code when needed - i.e. create the pattern for that. > 2. Fix the testing so that we have "enough" for quality and security > > In terms of features and functionality, I have some ideas as well and > suggest we move to a confluence page. > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=231117062 > . > > I offer these as a starting point for on list discussion. > > Jdailey >
