Devs - I'd like to hold a zoom call in late January / early February to cover some current roadmap thinking and direction. We will share the outcomes of that meeting here.
Proposed call: Jan 26th , 2023 (any takers? @Aleksandar Vidakovic <al...@apache.org> can you lead part of this as release manager?). THURSDAY Jan 26, 2023 0830 PST / 1130 EST / 1730 CEST / 2200 IST Zoom Details here -->. https://cwiki.apache.org/confluence/display/FINERACT/Roadmap+conversation+2023 Can you help? We had an effort in October to trim the number of open issues by closing several hundred old issues. Despite this, we still have hundreds of open issues. Triaging these issues is difficult - no one is doing it - and so what is really happening now is people are creating new tickets and working on those. To parrot Dr Seuss: If no-one is doing it, then it doesn't get done. No-one is nobody, unless it is you. A potentially useful thing is for someone to dig into a bunch of older issues and either validate them as currently existing, or close them. And, help decide priority. On Fri, Oct 21, 2022 at 8:53 PM Aleksandar Vidakovic <al...@apache.org> wrote: > ... 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 <jamespdai...@gmail.com> > 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 <al...@apache.org> 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 >> >
