You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <ja...@gmail.com> on 2022/10/22 00:50:47 UTC
Roadmap
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
Re: Roadmap
Posted by James Dailey <ja...@gmail.com>.
Hi Bharath - looking forward to having that conversation.
As a reminder, Apache projects follow a clear set of norms. Apache
Software Foundation (ASF) projects use ASF infrastructure which includes
jira tickets, confluence (wiki), Apache GitHub account, asf slack, and of
course this email listserv. If there’s an outside conversation (of any
kind ) it is brought back to ASF tools as they are the only allowable
source of truth about the project.
"Private decisions on code, policies, or project direction are disallowed;
off-list discourse and transactions must be brought on-list"
https://www.apache.org/theapacheway/index.html
So, we will have this zoom call and then bring back our understandings to
the list.
Thanks
On Wed, Jan 11, 2023 at 4:03 AM Bharath Gowda <bg...@mifos.org> wrote:
> 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 <ja...@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 <ja...@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
>>>>
>>>
Re: Roadmap
Posted by Bharath Gowda <bg...@mifos.org>.
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 <ja...@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 <ja...@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
>>>
>>
Re: Roadmap
Posted by James Dailey <ja...@gmail.com>.
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 <ja...@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
>>
>
Re: Roadmap
Posted by Aleksandar Vidakovic <al...@apache.org>.
... 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 <ja...@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
>