Hi James, Thank you for initiating this discussion, I will joining the call on Jan 26th and will try to help where ever I can. Also this discussion and task of clearing old tickets will be super useful for the Roadmap tool which we are building for Fineract which is similar to the talk we had on Apachecon 2022.
*Little Background on the Roadmap Tool* The idea of the roadmap tool is to have a single streem of input for all requirements through which we can do voting, prioritiz, a timeline and display it on the roadmap. 1. Collectively users will know which feature/bug is coming when and users can create a new request of feature(if it is not in the roadmap already) 2. Contributors will have visual display to pick and work on the priority tickets 3. This will reduce the load of duplicate ticket creations in JIRA I'll be sharing more information on the Roadmap tool soon in coming days with a demo site. Regards, Bharath Lead Implementation Analyst | Mifos Initiative Skype: live:cbharath4| Mobile: +91.7019635592 http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> On Wed, Jan 11, 2023 at 2:02 AM James Dailey <jamespdai...@gmail.com> wrote: > 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 >>> >>
