Hi all - A few of us took some time to participate in the Roadmapping discussion on zoom today. This was previously communicated on this dev list <https://lists.apache.org/thread/7kthv8mxq6oryz6849x6nsxjklb43vqm>.
https://cwiki.apache.org/confluence/display/FINERACT/Roadmap+conversation+2023 (see MEETING NOTES section) The result of that conversation we now bring back here. It was a good way to ground ourselves in the priorities and the reality of what we believe is achievable. 2023 ROADMAP (DRAFT) https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=231117062 There are specific areas of work broken out quarter by quarter at a very high level. Please take note and bring observations, objections, and commentary to this discussion thread. I will keep this open for comment for the next week and then, I propose, we can consider this our adopted Roadmap. Priorities (our top objectives for the project) 1. Make it easier and more maintainable for outside "users" (implementers) to extend the system rather than fork the code 1. We value both the ability to "build on top of" in an external system way and "build capabilities within" 2. For the "Build on Top Of", we need more attention to API documentation and recommended approaches 3. For the "build capabilities within" we introduced in Release 1.8 the Custom_Module concept which needs additional documentation and also improvements in the direction of Liquibase migrations (for out of bounds modules) 2. Enhance and improve Quality and Security 1. We observe that security is also a function of well-executed approaches 2. We will continue to improve on Pull Request reviews and work to ensure good contributions that meet the necessary standards 3. For security, we will fix certain design areas (to be discussed on Security List) 4. We will consider and use a Fineract Improvement Proposal (FIP) concept for process 5. We will also work on test frameworks CI/CD 3. Build for stability, maintainability, and scalability. 1. we are especially noting that the Loan Module needs refactoring to improve maintainability 2. refactoring will also be aimed at improving stability (and make it easier to find the bugs) and as a side effect will improve performance 3. the lack of consistent refactoring is also a problem and we prioritize a wider implementation of the same coding patterns across all modules to ensure stability of the project as well as maintainability 4. Make the project more approachable 1. This starts with the right sort of documentation 2. We assume that people come with either a "developer need" (need to understand how to deploy, how to do dev on top of, how to understand a specific pattern ) or a "business need" (what are the capabilities) 3. We have a number of documentation efforts including the ASCII doc (not well linked to) and the Swagger API documentation (too manual for now) and we need a high level effort here There was a short discussion about how to bring existing users up to the most recent releases, and we note that there will be a migration path as part of the ASCII documentation. Thanks, jdailey
