All

If anyone wishes to make a comment here on the Roadmapping discussion, feel
free to do so.

I'll keep it open another few days but, I think we can assume this is
"adopted" by the community as the set of priorities.  Hopefully nothing
here is a surprise or different than expectations.

Thank you



On Thu, Jan 26, 2023 at 11:52 AM James Dailey <[email protected]>
wrote:

> 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
>
>

Reply via email to