fineract'ers

[James Dailey <ja...@gmail.com>]

Hi All -

For the good of this project, I'd like to share some ideas gathered and
shared in a side meeting at OSCON18 with Apache President Ross Gardler who
was one of the champions of this project.  You can read the official PMC
reports that go to the Apache Board here -->
https://cwiki.apache.org/confluence/display/FINERACT/Board+Reports

I am not a member of the PMC, nor a committer, but I have been involved
from the beginnings of this in 2002. So, I am hoping to share both the
short term and the long term view.  As most of you know, the Mifos
Initiative contributed the code to Apache and remains - as an external
entity - highly interested in ensuring the continuation and growth of the
project.  In the Apache worldview, Mifos offers a kind of "productization"
of the *project*, and the hope is that many more such entities - for profit
companies in particular - will productize, and contribute back via the
community of developers, requirements and ideas.  In other projects we know
within Apache, contributors can be paid by companies to make sure that
their priorities get attention. Those companies and entities provide a kind
of "wrapper" around the project and can provide things like dashboards,
add-ons, and deployment scripts.  Thus a virtuous cycle is born and
supported.

What we do not want, and must try to avoid, are hard forks by the users
(entities that take the code and deploy in the real world), where they have
long standing unmerged changes, and worst that these changes are
incompatible with the upstream changes that are on the main fineract dev
branch. This then leads to harder to maintain code at the users and more
costly duplicative development for all. This is the opposite of the
virtuous cycle.

If there are large unmerged changes that can be proposed for either
Fineract1.x or for Fineract-CN, I believe a key way forward would be to
make those branches visible. Fortunately, and tongue firmly in cheek, there
is a mechanism available in git conveniently called a "branch".  I think
the PMC should consider this approach to bring into the fold those outside
entities that are on forks (via the individual contributors) and then to
have a clear process by which a serious attempt to evaluate and accept such
changes into the main branch are undertaken. It is probably naive of me to
think that the point of forking is that clear based on a defined release,
but one can hope. In any case, the project would be much assisted if code
that is written for real world situations is made visible for merit-based
evaluation and inclusion. That can, and probably should, exclude
productizations (plug-ins, deployment scripts, UIs, report infrastructure)
that give companies a differentiation in market. However, underlying code
changes that make those things work better need to be contributed back so
that the “wrappers” can be a kind of patch that is easily maintained on top
of the fineract release. If you are part of one of those companies, please
now do comment on what is holding you back, and make an attempt to move all
of your infrastructure to the latest stable fineract release (identifying
issues as they arise).

The other thing that we should strive to avoid are PRs that sit around and
remain un-merged. (as noted by PMC) This is an obvious problem made worse,
I believe, by having some number of contributions that may not have
anything to do with the needs of the broadest set of actual users.  If the
community is out of sync with the users, which is possible in a project
that is NOT involved in a direct "scratching the itch" kind of thing.
(referring to the axiom that most opensource projects are developers
scratching the itch for software that works for their needs). To solve this
problem, the Apache board recently heard about a cool innovation that seems
obvious in retrospect: allow non-committers to review and comment on
proposed Pull Requests, thereby determining their priority and earning the
non-committer points and merit towards committership. Also, we should have
a cultural project norm here where a few things can change around PRs:

   1.

   Committers should be free to merge if no objection is heard (a time
   frame of 72 hrs is probably ok, to be set as “community norm”)
   2.

   Merge and review - rather than review and merge should be adopted by the
   PMC
   3.

   Releases must be scrutinized but the “tip” or “head” of dev can be
   merges that may be subject to review and revert-backs
   4.

   If you break it, you unmerge it  (tests coverage is your friend!!)


For more information on project maturity at Apache, please read

https://community.apache.org/apache-way/apache-project-maturity-model.html

By the way, and now speaking with my non-profit Mifos hat on, a key intent
of moving the code over from Mifos to Apache was to broaden the community
and broaden the appeal.  When I say "Mifos contributed" I also mean to say
all of the contributors to the Mifos project, who worked on it as an open
source project from 2005 to present, are part of that. It is accurate to
say that the Mifos community was already an active one and a key
accomplishment over the past two years is bringing over the code and the
community to Apache.  But more needs to be done to clarify.

Mifos community code (also released under apache 2.0) is now a wrapper on
top of fineract. Fineract can include binary releases for convenience but
the code is the thing, not the productization. Mifos is also continuing to
play an important role in organizing the community of financial inclusion
around fineract - I submit that that is not inconsistent with the PMC
trying to market fineract to both the financial inclusion community and the
private sector interested in payments, banking, etc.  As a non-profit,
Mifos has much of the same operating imperatives as Apache, but with a
narrower focus on financial inclusion. We probably need advice from our
apache friends how to address this dual role.

Finally, I am inspired by what so many have accomplished on the mifosX →
now fineract 1.x codebase and what is promised by the fineract-CN code.  I
continue to envision fineract in the broadest and more inspiring terms.
Opensource will eat the world and the financial world is only beginning to
be heard from us.


Please do comment on this post and suggest ways to operationalize or object
and say why. THANK YOU!!

James Dailey

Fineract’r

Board Chair, Mifos

Re: lower the barriers to contribution, branching

[James Dailey <ja...@gmail.com>]

Kevin - mostly right - reference to natural world including seasons...so
revised, and a little darker:

fineract autumn
Pull Requests should drop like leaves
But if not, winter
Comes like RR Martin writes

Code contributed
lives on, makes a difference
share a branch, git-style
practical beats purity*

monitor beauty
just gate-keep for quality
coding wise DRY KISS!
community over code

-jamesD

On Fri, Sep 28, 2018, 5:43 PM Kevin A. McGrail <km...@apache.org> wrote:

> The pedantic innerchild in me must point out that a Haiku by definition
> must reference a seasonal element. -KAM
> On Fri, Sep 28, 2018 at 8:41 AM James Dailey <ja...@gmail.com>
> wrote:
>
> > I'd like to promote discussion on this topic again with a little haiku:
> >
> > code contributed
> > lives on, makes a difference
> > share a branch, git-style
> > practical beats purity*
> >
> > monitor beauty
> > just gate-keep for quality
> > coding wise DRY KISS!
> > community over code
> >
> > -jamesD
> > *derivative attribution to line 9 of Zen of Python
> >
> > --- to quote myself, as poets may do:
> > > What we do not want, and must try to avoid, are hard forks by the users
> > > (entities that take the code and deploy in the real world), where they
> > have
> > > long standing unmerged changes, and worst that these changes are
> > > incompatible with the upstream changes that are on the main fineract
> dev
> > > branch. This then leads to harder to maintain code at the users and
> more
> > > costly duplicative development for all. This is the opposite of the
> > > virtuous cycle.
> >
> >
> >
> >
> > On Fri, Aug 24, 2018 at 2:03 PM Myrle Krantz <my...@apache.org> wrote:
> >
> > > Hey all,
> > >
> > > Just FYI, I forwarded James Dailey's mail to Ross, and here was his
> > > response.  (There's a little plug in there for ApacheCon as well.
> > > Anyone who hasn't registered yet: there's still time. : o)
> > >
> > > "Thanks Myrle,
> > >
> > > You are correct I do not actively follow the Fineract dev list
> > > anymore. Feel free to share this back to the broader community list if
> > > it helps.
> > >
> > > The below email from James is a good summary of our conversation at
> > > OSCON. This conversation was a general one about “The Apache Way” and
> > > how Apache projects deal with growing pains as their code matures. I
> > > cannot comment on how well James has applied those general lessons to
> > > Fineract today, but I certainly see plenty of good content within this
> > > mail.
> > >
> > > If I were to summarize that general guidance in a few sentences it
> > > would be to remove as much friction from the contribution process
> > > (code reviews, merit recognition, community alignment) as possible.
> > > Generally speaking the lower the barriers to contribution the faster
> > > the community will grow. This does depend on people actively
> > > monitoring the project, but monitoring is less work than gate-keeping.
> > >
> > > Adopting things like Lazy Consensus can be key
> > > http://community.apache.org/committers/lazyConsensus.html.
> > >
> > > In the days of SVN we were forced by the tooling to operate with a
> > > branching model. This works really well. All changes are visible in
> > > one place. Work in progress can be easily discovered and reviewed. It
> > > means those monitoring the project have the opportunity to review work
> > > as it happens, thus enabling them to raise concerns about a design
> > > decision or implementation weakness early in the process. This in turn
> > > meant that when it was time to consider a merge most of the rough
> > > edges had ben talked about *before* they had become deeply imbedded in
> > > finished code. It was easier to fix and people would work together to
> > > design a fix that worked for everyone.
> > >
> > > As James indicates Git does not force this way of working. It has
> > > excellent support for the SVN concept of branching, unfortunately
> > > GitHub has driven most people to click “fork” (mostly invisible to the
> > > community) rather than branch. GitHub, therefore, has encouraged us to
> > > work privately then issue a pull request for review when the work is
> > > “finished”. This often means people are not keen to redo their
> > > implementation to satisfy the broader needs of the community. They
> > > will blame the community for “blocking” their improvements.
> > >
> > > I am a strong believer in doing as much as possible in the open at all
> > > times and reducing barriers to collaboration.
> > >
> > > Interestingly, I have a talk on this topic at ApacheCon this year, if
> > > only I’d written it already
> > >
> > > Ross"
> > > On Wed, Jul 25, 2018 at 7:00 PM James Dailey <ja...@gmail.com>
> > > wrote:
> > > >
> > > > Hi All -
> > > >
> > > > For the good of this project, I'd like to share some ideas gathered
> and
> > > > shared in a side meeting at OSCON18 with Apache President Ross
> Gardler
> > > who
> > > > was one of the champions of this project.  You can read the official
> > PMC
> > > > reports that go to the Apache Board here -->
> > > > https://cwiki.apache.org/confluence/display/FINERACT/Board+Reports
> > > >
> > > > I am not a member of the PMC, nor a committer, but I have been
> involved
> > > > from the beginnings of this in 2002. So, I am hoping to share both
> the
> > > > short term and the long term view.  As most of you know, the Mifos
> > > > Initiative contributed the code to Apache and remains - as an
> external
> > > > entity - highly interested in ensuring the continuation and growth of
> > the
> > > > project.  In the Apache worldview, Mifos offers a kind of
> > > "productization"
> > > > of the *project*, and the hope is that many more such entities - for
> > > profit
> > > > companies in particular - will productize, and contribute back via
> the
> > > > community of developers, requirements and ideas.  In other projects
> we
> > > know
> > > > within Apache, contributors can be paid by companies to make sure
> that
> > > > their priorities get attention. Those companies and entities provide
> a
> > > kind
> > > > of "wrapper" around the project and can provide things like
> dashboards,
> > > > add-ons, and deployment scripts.  Thus a virtuous cycle is born and
> > > > supported.
> > > >
> > > > What we do not want, and must try to avoid, are hard forks by the
> users
> > > > (entities that take the code and deploy in the real world), where
> they
> > > have
> > > > long standing unmerged changes, and worst that these changes are
> > > > incompatible with the upstream changes that are on the main fineract
> > dev
> > > > branch. This then leads to harder to maintain code at the users and
> > more
> > > > costly duplicative development for all. This is the opposite of the
> > > > virtuous cycle.
> > > >
> > > > If there are large unmerged changes that can be proposed for either
> > > > Fineract1.x or for Fineract-CN, I believe a key way forward would be
> to
> > > > make those branches visible. Fortunately, and tongue firmly in cheek,
> > > there
> > > > is a mechanism available in git conveniently called a "branch".  I
> > think
> > > > the PMC should consider this approach to bring into the fold those
> > > outside
> > > > entities that are on forks (via the individual contributors) and then
> > to
> > > > have a clear process by which a serious attempt to evaluate and
> accept
> > > such
> > > > changes into the main branch are undertaken. It is probably naive of
> me
> > > to
> > > > think that the point of forking is that clear based on a defined
> > release,
> > > > but one can hope. In any case, the project would be much assisted if
> > code
> > > > that is written for real world situations is made visible for
> > merit-based
> > > > evaluation and inclusion. That can, and probably should, exclude
> > > > productizations (plug-ins, deployment scripts, UIs, report
> > > infrastructure)
> > > > that give companies a differentiation in market. However, underlying
> > code
> > > > changes that make those things work better need to be contributed
> back
> > so
> > > > that the “wrappers” can be a kind of patch that is easily maintained
> on
> > > top
> > > > of the fineract release. If you are part of one of those companies,
> > > please
> > > > now do comment on what is holding you back, and make an attempt to
> move
> > > all
> > > > of your infrastructure to the latest stable fineract release
> > (identifying
> > > > issues as they arise).
> > > >
> > > > The other thing that we should strive to avoid are PRs that sit
> around
> > > and
> > > > remain un-merged. (as noted by PMC) This is an obvious problem made
> > > worse,
> > > > I believe, by having some number of contributions that may not have
> > > > anything to do with the needs of the broadest set of actual users.
> If
> > > the
> > > > community is out of sync with the users, which is possible in a
> project
> > > > that is NOT involved in a direct "scratching the itch" kind of thing.
> > > > (referring to the axiom that most opensource projects are developers
> > > > scratching the itch for software that works for their needs). To
> solve
> > > this
> > > > problem, the Apache board recently heard about a cool innovation that
> > > seems
> > > > obvious in retrospect: allow non-committers to review and comment on
> > > > proposed Pull Requests, thereby determining their priority and
> earning
> > > the
> > > > non-committer points and merit towards committership. Also, we should
> > > have
> > > > a cultural project norm here where a few things can change around
> PRs:
> > > >
> > > >    1.
> > > >
> > > >    Committers should be free to merge if no objection is heard (a
> time
> > > >    frame of 72 hrs is probably ok, to be set as “community norm”)
> > > >    2.
> > > >
> > > >    Merge and review - rather than review and merge should be adopted
> by
> > > the
> > > >    PMC
> > > >    3.
> > > >
> > > >    Releases must be scrutinized but the “tip” or “head” of dev can be
> > > >    merges that may be subject to review and revert-backs
> > > >    4.
> > > >
> > > >    If you break it, you unmerge it  (tests coverage is your friend!!)
> > > >
> > > >
> > > > For more information on project maturity at Apache, please read
> > > >
> > > >
> > >
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> > > >
> > > > By the way, and now speaking with my non-profit Mifos hat on, a key
> > > intent
> > > > of moving the code over from Mifos to Apache was to broaden the
> > community
> > > > and broaden the appeal.  When I say "Mifos contributed" I also mean
> to
> > > say
> > > > all of the contributors to the Mifos project, who worked on it as an
> > open
> > > > source project from 2005 to present, are part of that. It is accurate
> > to
> > > > say that the Mifos community was already an active one and a key
> > > > accomplishment over the past two years is bringing over the code and
> > the
> > > > community to Apache.  But more needs to be done to clarify.
> > > >
> > > > Mifos community code (also released under apache 2.0) is now a
> wrapper
> > on
> > > > top of fineract. Fineract can include binary releases for convenience
> > but
> > > > the code is the thing, not the productization. Mifos is also
> continuing
> > > to
> > > > play an important role in organizing the community of financial
> > inclusion
> > > > around fineract - I submit that that is not inconsistent with the PMC
> > > > trying to market fineract to both the financial inclusion community
> and
> > > the
> > > > private sector interested in payments, banking, etc.  As a
> non-profit,
> > > > Mifos has much of the same operating imperatives as Apache, but with
> a
> > > > narrower focus on financial inclusion. We probably need advice from
> our
> > > > apache friends how to address this dual role.
> > > >
> > > > Finally, I am inspired by what so many have accomplished on the
> mifosX
> > →
> > > > now fineract 1.x codebase and what is promised by the fineract-CN
> code.
> > > I
> > > > continue to envision fineract in the broadest and more inspiring
> terms.
> > > > Opensource will eat the world and the financial world is only
> beginning
> > > to
> > > > be heard from us.
> > > >
> > > >
> > > > Please do comment on this post and suggest ways to operationalize or
> > > object
> > > > and say why. THANK YOU!!
> > > >
> > > > James Dailey
> > > >
> > > > Fineract’r
> > > >
> > > > Board Chair, Mifos
> > >
> >
>

Re: lower the barriers to contribution, branching

["Kevin A. McGrail" <km...@apache.org>]

The pedantic innerchild in me must point out that a Haiku by definition
must reference a seasonal element. -KAM
On Fri, Sep 28, 2018 at 8:41 AM James Dailey <ja...@gmail.com> wrote:

> I'd like to promote discussion on this topic again with a little haiku:
>
> code contributed
> lives on, makes a difference
> share a branch, git-style
> practical beats purity*
>
> monitor beauty
> just gate-keep for quality
> coding wise DRY KISS!
> community over code
>
> -jamesD
> *derivative attribution to line 9 of Zen of Python
>
> --- to quote myself, as poets may do:
> > What we do not want, and must try to avoid, are hard forks by the users
> > (entities that take the code and deploy in the real world), where they
> have
> > long standing unmerged changes, and worst that these changes are
> > incompatible with the upstream changes that are on the main fineract dev
> > branch. This then leads to harder to maintain code at the users and more
> > costly duplicative development for all. This is the opposite of the
> > virtuous cycle.
>
>
>
>
> On Fri, Aug 24, 2018 at 2:03 PM Myrle Krantz <my...@apache.org> wrote:
>
> > Hey all,
> >
> > Just FYI, I forwarded James Dailey's mail to Ross, and here was his
> > response.  (There's a little plug in there for ApacheCon as well.
> > Anyone who hasn't registered yet: there's still time. : o)
> >
> > "Thanks Myrle,
> >
> > You are correct I do not actively follow the Fineract dev list
> > anymore. Feel free to share this back to the broader community list if
> > it helps.
> >
> > The below email from James is a good summary of our conversation at
> > OSCON. This conversation was a general one about “The Apache Way” and
> > how Apache projects deal with growing pains as their code matures. I
> > cannot comment on how well James has applied those general lessons to
> > Fineract today, but I certainly see plenty of good content within this
> > mail.
> >
> > If I were to summarize that general guidance in a few sentences it
> > would be to remove as much friction from the contribution process
> > (code reviews, merit recognition, community alignment) as possible.
> > Generally speaking the lower the barriers to contribution the faster
> > the community will grow. This does depend on people actively
> > monitoring the project, but monitoring is less work than gate-keeping.
> >
> > Adopting things like Lazy Consensus can be key
> > http://community.apache.org/committers/lazyConsensus.html.
> >
> > In the days of SVN we were forced by the tooling to operate with a
> > branching model. This works really well. All changes are visible in
> > one place. Work in progress can be easily discovered and reviewed. It
> > means those monitoring the project have the opportunity to review work
> > as it happens, thus enabling them to raise concerns about a design
> > decision or implementation weakness early in the process. This in turn
> > meant that when it was time to consider a merge most of the rough
> > edges had ben talked about *before* they had become deeply imbedded in
> > finished code. It was easier to fix and people would work together to
> > design a fix that worked for everyone.
> >
> > As James indicates Git does not force this way of working. It has
> > excellent support for the SVN concept of branching, unfortunately
> > GitHub has driven most people to click “fork” (mostly invisible to the
> > community) rather than branch. GitHub, therefore, has encouraged us to
> > work privately then issue a pull request for review when the work is
> > “finished”. This often means people are not keen to redo their
> > implementation to satisfy the broader needs of the community. They
> > will blame the community for “blocking” their improvements.
> >
> > I am a strong believer in doing as much as possible in the open at all
> > times and reducing barriers to collaboration.
> >
> > Interestingly, I have a talk on this topic at ApacheCon this year, if
> > only I’d written it already
> >
> > Ross"
> > On Wed, Jul 25, 2018 at 7:00 PM James Dailey <ja...@gmail.com>
> > wrote:
> > >
> > > Hi All -
> > >
> > > For the good of this project, I'd like to share some ideas gathered and
> > > shared in a side meeting at OSCON18 with Apache President Ross Gardler
> > who
> > > was one of the champions of this project.  You can read the official
> PMC
> > > reports that go to the Apache Board here -->
> > > https://cwiki.apache.org/confluence/display/FINERACT/Board+Reports
> > >
> > > I am not a member of the PMC, nor a committer, but I have been involved
> > > from the beginnings of this in 2002. So, I am hoping to share both the
> > > short term and the long term view.  As most of you know, the Mifos
> > > Initiative contributed the code to Apache and remains - as an external
> > > entity - highly interested in ensuring the continuation and growth of
> the
> > > project.  In the Apache worldview, Mifos offers a kind of
> > "productization"
> > > of the *project*, and the hope is that many more such entities - for
> > profit
> > > companies in particular - will productize, and contribute back via the
> > > community of developers, requirements and ideas.  In other projects we
> > know
> > > within Apache, contributors can be paid by companies to make sure that
> > > their priorities get attention. Those companies and entities provide a
> > kind
> > > of "wrapper" around the project and can provide things like dashboards,
> > > add-ons, and deployment scripts.  Thus a virtuous cycle is born and
> > > supported.
> > >
> > > What we do not want, and must try to avoid, are hard forks by the users
> > > (entities that take the code and deploy in the real world), where they
> > have
> > > long standing unmerged changes, and worst that these changes are
> > > incompatible with the upstream changes that are on the main fineract
> dev
> > > branch. This then leads to harder to maintain code at the users and
> more
> > > costly duplicative development for all. This is the opposite of the
> > > virtuous cycle.
> > >
> > > If there are large unmerged changes that can be proposed for either
> > > Fineract1.x or for Fineract-CN, I believe a key way forward would be to
> > > make those branches visible. Fortunately, and tongue firmly in cheek,
> > there
> > > is a mechanism available in git conveniently called a "branch".  I
> think
> > > the PMC should consider this approach to bring into the fold those
> > outside
> > > entities that are on forks (via the individual contributors) and then
> to
> > > have a clear process by which a serious attempt to evaluate and accept
> > such
> > > changes into the main branch are undertaken. It is probably naive of me
> > to
> > > think that the point of forking is that clear based on a defined
> release,
> > > but one can hope. In any case, the project would be much assisted if
> code
> > > that is written for real world situations is made visible for
> merit-based
> > > evaluation and inclusion. That can, and probably should, exclude
> > > productizations (plug-ins, deployment scripts, UIs, report
> > infrastructure)
> > > that give companies a differentiation in market. However, underlying
> code
> > > changes that make those things work better need to be contributed back
> so
> > > that the “wrappers” can be a kind of patch that is easily maintained on
> > top
> > > of the fineract release. If you are part of one of those companies,
> > please
> > > now do comment on what is holding you back, and make an attempt to move
> > all
> > > of your infrastructure to the latest stable fineract release
> (identifying
> > > issues as they arise).
> > >
> > > The other thing that we should strive to avoid are PRs that sit around
> > and
> > > remain un-merged. (as noted by PMC) This is an obvious problem made
> > worse,
> > > I believe, by having some number of contributions that may not have
> > > anything to do with the needs of the broadest set of actual users.  If
> > the
> > > community is out of sync with the users, which is possible in a project
> > > that is NOT involved in a direct "scratching the itch" kind of thing.
> > > (referring to the axiom that most opensource projects are developers
> > > scratching the itch for software that works for their needs). To solve
> > this
> > > problem, the Apache board recently heard about a cool innovation that
> > seems
> > > obvious in retrospect: allow non-committers to review and comment on
> > > proposed Pull Requests, thereby determining their priority and earning
> > the
> > > non-committer points and merit towards committership. Also, we should
> > have
> > > a cultural project norm here where a few things can change around PRs:
> > >
> > >    1.
> > >
> > >    Committers should be free to merge if no objection is heard (a time
> > >    frame of 72 hrs is probably ok, to be set as “community norm”)
> > >    2.
> > >
> > >    Merge and review - rather than review and merge should be adopted by
> > the
> > >    PMC
> > >    3.
> > >
> > >    Releases must be scrutinized but the “tip” or “head” of dev can be
> > >    merges that may be subject to review and revert-backs
> > >    4.
> > >
> > >    If you break it, you unmerge it  (tests coverage is your friend!!)
> > >
> > >
> > > For more information on project maturity at Apache, please read
> > >
> > >
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> > >
> > > By the way, and now speaking with my non-profit Mifos hat on, a key
> > intent
> > > of moving the code over from Mifos to Apache was to broaden the
> community
> > > and broaden the appeal.  When I say "Mifos contributed" I also mean to
> > say
> > > all of the contributors to the Mifos project, who worked on it as an
> open
> > > source project from 2005 to present, are part of that. It is accurate
> to
> > > say that the Mifos community was already an active one and a key
> > > accomplishment over the past two years is bringing over the code and
> the
> > > community to Apache.  But more needs to be done to clarify.
> > >
> > > Mifos community code (also released under apache 2.0) is now a wrapper
> on
> > > top of fineract. Fineract can include binary releases for convenience
> but
> > > the code is the thing, not the productization. Mifos is also continuing
> > to
> > > play an important role in organizing the community of financial
> inclusion
> > > around fineract - I submit that that is not inconsistent with the PMC
> > > trying to market fineract to both the financial inclusion community and
> > the
> > > private sector interested in payments, banking, etc.  As a non-profit,
> > > Mifos has much of the same operating imperatives as Apache, but with a
> > > narrower focus on financial inclusion. We probably need advice from our
> > > apache friends how to address this dual role.
> > >
> > > Finally, I am inspired by what so many have accomplished on the mifosX
> →
> > > now fineract 1.x codebase and what is promised by the fineract-CN code.
> > I
> > > continue to envision fineract in the broadest and more inspiring terms.
> > > Opensource will eat the world and the financial world is only beginning
> > to
> > > be heard from us.
> > >
> > >
> > > Please do comment on this post and suggest ways to operationalize or
> > object
> > > and say why. THANK YOU!!
> > >
> > > James Dailey
> > >
> > > Fineract’r
> > >
> > > Board Chair, Mifos
> >
>

lower the barriers to contribution, branching

[James Dailey <ja...@gmail.com>]

I'd like to promote discussion on this topic again with a little haiku:

code contributed
lives on, makes a difference
share a branch, git-style
practical beats purity*

monitor beauty
just gate-keep for quality
coding wise DRY KISS!
community over code

-jamesD
*derivative attribution to line 9 of Zen of Python

--- to quote myself, as poets may do:
> What we do not want, and must try to avoid, are hard forks by the users
> (entities that take the code and deploy in the real world), where they
have
> long standing unmerged changes, and worst that these changes are
> incompatible with the upstream changes that are on the main fineract dev
> branch. This then leads to harder to maintain code at the users and more
> costly duplicative development for all. This is the opposite of the
> virtuous cycle.




On Fri, Aug 24, 2018 at 2:03 PM Myrle Krantz <my...@apache.org> wrote:

> Hey all,
>
> Just FYI, I forwarded James Dailey's mail to Ross, and here was his
> response.  (There's a little plug in there for ApacheCon as well.
> Anyone who hasn't registered yet: there's still time. : o)
>
> "Thanks Myrle,
>
> You are correct I do not actively follow the Fineract dev list
> anymore. Feel free to share this back to the broader community list if
> it helps.
>
> The below email from James is a good summary of our conversation at
> OSCON. This conversation was a general one about “The Apache Way” and
> how Apache projects deal with growing pains as their code matures. I
> cannot comment on how well James has applied those general lessons to
> Fineract today, but I certainly see plenty of good content within this
> mail.
>
> If I were to summarize that general guidance in a few sentences it
> would be to remove as much friction from the contribution process
> (code reviews, merit recognition, community alignment) as possible.
> Generally speaking the lower the barriers to contribution the faster
> the community will grow. This does depend on people actively
> monitoring the project, but monitoring is less work than gate-keeping.
>
> Adopting things like Lazy Consensus can be key
> http://community.apache.org/committers/lazyConsensus.html.
>
> In the days of SVN we were forced by the tooling to operate with a
> branching model. This works really well. All changes are visible in
> one place. Work in progress can be easily discovered and reviewed. It
> means those monitoring the project have the opportunity to review work
> as it happens, thus enabling them to raise concerns about a design
> decision or implementation weakness early in the process. This in turn
> meant that when it was time to consider a merge most of the rough
> edges had ben talked about *before* they had become deeply imbedded in
> finished code. It was easier to fix and people would work together to
> design a fix that worked for everyone.
>
> As James indicates Git does not force this way of working. It has
> excellent support for the SVN concept of branching, unfortunately
> GitHub has driven most people to click “fork” (mostly invisible to the
> community) rather than branch. GitHub, therefore, has encouraged us to
> work privately then issue a pull request for review when the work is
> “finished”. This often means people are not keen to redo their
> implementation to satisfy the broader needs of the community. They
> will blame the community for “blocking” their improvements.
>
> I am a strong believer in doing as much as possible in the open at all
> times and reducing barriers to collaboration.
>
> Interestingly, I have a talk on this topic at ApacheCon this year, if
> only I’d written it already
>
> Ross"
> On Wed, Jul 25, 2018 at 7:00 PM James Dailey <ja...@gmail.com>
> wrote:
> >
> > Hi All -
> >
> > For the good of this project, I'd like to share some ideas gathered and
> > shared in a side meeting at OSCON18 with Apache President Ross Gardler
> who
> > was one of the champions of this project.  You can read the official PMC
> > reports that go to the Apache Board here -->
> > https://cwiki.apache.org/confluence/display/FINERACT/Board+Reports
> >
> > I am not a member of the PMC, nor a committer, but I have been involved
> > from the beginnings of this in 2002. So, I am hoping to share both the
> > short term and the long term view.  As most of you know, the Mifos
> > Initiative contributed the code to Apache and remains - as an external
> > entity - highly interested in ensuring the continuation and growth of the
> > project.  In the Apache worldview, Mifos offers a kind of
> "productization"
> > of the *project*, and the hope is that many more such entities - for
> profit
> > companies in particular - will productize, and contribute back via the
> > community of developers, requirements and ideas.  In other projects we
> know
> > within Apache, contributors can be paid by companies to make sure that
> > their priorities get attention. Those companies and entities provide a
> kind
> > of "wrapper" around the project and can provide things like dashboards,
> > add-ons, and deployment scripts.  Thus a virtuous cycle is born and
> > supported.
> >
> > What we do not want, and must try to avoid, are hard forks by the users
> > (entities that take the code and deploy in the real world), where they
> have
> > long standing unmerged changes, and worst that these changes are
> > incompatible with the upstream changes that are on the main fineract dev
> > branch. This then leads to harder to maintain code at the users and more
> > costly duplicative development for all. This is the opposite of the
> > virtuous cycle.
> >
> > If there are large unmerged changes that can be proposed for either
> > Fineract1.x or for Fineract-CN, I believe a key way forward would be to
> > make those branches visible. Fortunately, and tongue firmly in cheek,
> there
> > is a mechanism available in git conveniently called a "branch".  I think
> > the PMC should consider this approach to bring into the fold those
> outside
> > entities that are on forks (via the individual contributors) and then to
> > have a clear process by which a serious attempt to evaluate and accept
> such
> > changes into the main branch are undertaken. It is probably naive of me
> to
> > think that the point of forking is that clear based on a defined release,
> > but one can hope. In any case, the project would be much assisted if code
> > that is written for real world situations is made visible for merit-based
> > evaluation and inclusion. That can, and probably should, exclude
> > productizations (plug-ins, deployment scripts, UIs, report
> infrastructure)
> > that give companies a differentiation in market. However, underlying code
> > changes that make those things work better need to be contributed back so
> > that the “wrappers” can be a kind of patch that is easily maintained on
> top
> > of the fineract release. If you are part of one of those companies,
> please
> > now do comment on what is holding you back, and make an attempt to move
> all
> > of your infrastructure to the latest stable fineract release (identifying
> > issues as they arise).
> >
> > The other thing that we should strive to avoid are PRs that sit around
> and
> > remain un-merged. (as noted by PMC) This is an obvious problem made
> worse,
> > I believe, by having some number of contributions that may not have
> > anything to do with the needs of the broadest set of actual users.  If
> the
> > community is out of sync with the users, which is possible in a project
> > that is NOT involved in a direct "scratching the itch" kind of thing.
> > (referring to the axiom that most opensource projects are developers
> > scratching the itch for software that works for their needs). To solve
> this
> > problem, the Apache board recently heard about a cool innovation that
> seems
> > obvious in retrospect: allow non-committers to review and comment on
> > proposed Pull Requests, thereby determining their priority and earning
> the
> > non-committer points and merit towards committership. Also, we should
> have
> > a cultural project norm here where a few things can change around PRs:
> >
> >    1.
> >
> >    Committers should be free to merge if no objection is heard (a time
> >    frame of 72 hrs is probably ok, to be set as “community norm”)
> >    2.
> >
> >    Merge and review - rather than review and merge should be adopted by
> the
> >    PMC
> >    3.
> >
> >    Releases must be scrutinized but the “tip” or “head” of dev can be
> >    merges that may be subject to review and revert-backs
> >    4.
> >
> >    If you break it, you unmerge it  (tests coverage is your friend!!)
> >
> >
> > For more information on project maturity at Apache, please read
> >
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> >
> > By the way, and now speaking with my non-profit Mifos hat on, a key
> intent
> > of moving the code over from Mifos to Apache was to broaden the community
> > and broaden the appeal.  When I say "Mifos contributed" I also mean to
> say
> > all of the contributors to the Mifos project, who worked on it as an open
> > source project from 2005 to present, are part of that. It is accurate to
> > say that the Mifos community was already an active one and a key
> > accomplishment over the past two years is bringing over the code and the
> > community to Apache.  But more needs to be done to clarify.
> >
> > Mifos community code (also released under apache 2.0) is now a wrapper on
> > top of fineract. Fineract can include binary releases for convenience but
> > the code is the thing, not the productization. Mifos is also continuing
> to
> > play an important role in organizing the community of financial inclusion
> > around fineract - I submit that that is not inconsistent with the PMC
> > trying to market fineract to both the financial inclusion community and
> the
> > private sector interested in payments, banking, etc.  As a non-profit,
> > Mifos has much of the same operating imperatives as Apache, but with a
> > narrower focus on financial inclusion. We probably need advice from our
> > apache friends how to address this dual role.
> >
> > Finally, I am inspired by what so many have accomplished on the mifosX →
> > now fineract 1.x codebase and what is promised by the fineract-CN code.
> I
> > continue to envision fineract in the broadest and more inspiring terms.
> > Opensource will eat the world and the financial world is only beginning
> to
> > be heard from us.
> >
> >
> > Please do comment on this post and suggest ways to operationalize or
> object
> > and say why. THANK YOU!!
> >
> > James Dailey
> >
> > Fineract’r
> >
> > Board Chair, Mifos
>

Re: fineract'ers

[Myrle Krantz <my...@apache.org>]

Hey all,

Just FYI, I forwarded James Dailey's mail to Ross, and here was his
response.  (There's a little plug in there for ApacheCon as well.
Anyone who hasn't registered yet: there's still time. : o)

"Thanks Myrle,

You are correct I do not actively follow the Fineract dev list
anymore. Feel free to share this back to the broader community list if
it helps.

The below email from James is a good summary of our conversation at
OSCON. This conversation was a general one about “The Apache Way” and
how Apache projects deal with growing pains as their code matures. I
cannot comment on how well James has applied those general lessons to
Fineract today, but I certainly see plenty of good content within this
mail.

If I were to summarize that general guidance in a few sentences it
would be to remove as much friction from the contribution process
(code reviews, merit recognition, community alignment) as possible.
Generally speaking the lower the barriers to contribution the faster
the community will grow. This does depend on people actively
monitoring the project, but monitoring is less work than gate-keeping.

Adopting things like Lazy Consensus can be key
http://community.apache.org/committers/lazyConsensus.html.

In the days of SVN we were forced by the tooling to operate with a
branching model. This works really well. All changes are visible in
one place. Work in progress can be easily discovered and reviewed. It
means those monitoring the project have the opportunity to review work
as it happens, thus enabling them to raise concerns about a design
decision or implementation weakness early in the process. This in turn
meant that when it was time to consider a merge most of the rough
edges had ben talked about *before* they had become deeply imbedded in
finished code. It was easier to fix and people would work together to
design a fix that worked for everyone.

As James indicates Git does not force this way of working. It has
excellent support for the SVN concept of branching, unfortunately
GitHub has driven most people to click “fork” (mostly invisible to the
community) rather than branch. GitHub, therefore, has encouraged us to
work privately then issue a pull request for review when the work is
“finished”. This often means people are not keen to redo their
implementation to satisfy the broader needs of the community. They
will blame the community for “blocking” their improvements.

I am a strong believer in doing as much as possible in the open at all
times and reducing barriers to collaboration.

Interestingly, I have a talk on this topic at ApacheCon this year, if
only I’d written it already

Ross"
On Wed, Jul 25, 2018 at 7:00 PM James Dailey <ja...@gmail.com> wrote:
>
> Hi All -
>
> For the good of this project, I'd like to share some ideas gathered and
> shared in a side meeting at OSCON18 with Apache President Ross Gardler who
> was one of the champions of this project.  You can read the official PMC
> reports that go to the Apache Board here -->
> https://cwiki.apache.org/confluence/display/FINERACT/Board+Reports
>
> I am not a member of the PMC, nor a committer, but I have been involved
> from the beginnings of this in 2002. So, I am hoping to share both the
> short term and the long term view.  As most of you know, the Mifos
> Initiative contributed the code to Apache and remains - as an external
> entity - highly interested in ensuring the continuation and growth of the
> project.  In the Apache worldview, Mifos offers a kind of "productization"
> of the *project*, and the hope is that many more such entities - for profit
> companies in particular - will productize, and contribute back via the
> community of developers, requirements and ideas.  In other projects we know
> within Apache, contributors can be paid by companies to make sure that
> their priorities get attention. Those companies and entities provide a kind
> of "wrapper" around the project and can provide things like dashboards,
> add-ons, and deployment scripts.  Thus a virtuous cycle is born and
> supported.
>
> What we do not want, and must try to avoid, are hard forks by the users
> (entities that take the code and deploy in the real world), where they have
> long standing unmerged changes, and worst that these changes are
> incompatible with the upstream changes that are on the main fineract dev
> branch. This then leads to harder to maintain code at the users and more
> costly duplicative development for all. This is the opposite of the
> virtuous cycle.
>
> If there are large unmerged changes that can be proposed for either
> Fineract1.x or for Fineract-CN, I believe a key way forward would be to
> make those branches visible. Fortunately, and tongue firmly in cheek, there
> is a mechanism available in git conveniently called a "branch".  I think
> the PMC should consider this approach to bring into the fold those outside
> entities that are on forks (via the individual contributors) and then to
> have a clear process by which a serious attempt to evaluate and accept such
> changes into the main branch are undertaken. It is probably naive of me to
> think that the point of forking is that clear based on a defined release,
> but one can hope. In any case, the project would be much assisted if code
> that is written for real world situations is made visible for merit-based
> evaluation and inclusion. That can, and probably should, exclude
> productizations (plug-ins, deployment scripts, UIs, report infrastructure)
> that give companies a differentiation in market. However, underlying code
> changes that make those things work better need to be contributed back so
> that the “wrappers” can be a kind of patch that is easily maintained on top
> of the fineract release. If you are part of one of those companies, please
> now do comment on what is holding you back, and make an attempt to move all
> of your infrastructure to the latest stable fineract release (identifying
> issues as they arise).
>
> The other thing that we should strive to avoid are PRs that sit around and
> remain un-merged. (as noted by PMC) This is an obvious problem made worse,
> I believe, by having some number of contributions that may not have
> anything to do with the needs of the broadest set of actual users.  If the
> community is out of sync with the users, which is possible in a project
> that is NOT involved in a direct "scratching the itch" kind of thing.
> (referring to the axiom that most opensource projects are developers
> scratching the itch for software that works for their needs). To solve this
> problem, the Apache board recently heard about a cool innovation that seems
> obvious in retrospect: allow non-committers to review and comment on
> proposed Pull Requests, thereby determining their priority and earning the
> non-committer points and merit towards committership. Also, we should have
> a cultural project norm here where a few things can change around PRs:
>
>    1.
>
>    Committers should be free to merge if no objection is heard (a time
>    frame of 72 hrs is probably ok, to be set as “community norm”)
>    2.
>
>    Merge and review - rather than review and merge should be adopted by the
>    PMC
>    3.
>
>    Releases must be scrutinized but the “tip” or “head” of dev can be
>    merges that may be subject to review and revert-backs
>    4.
>
>    If you break it, you unmerge it  (tests coverage is your friend!!)
>
>
> For more information on project maturity at Apache, please read
>
> https://community.apache.org/apache-way/apache-project-maturity-model.html
>
> By the way, and now speaking with my non-profit Mifos hat on, a key intent
> of moving the code over from Mifos to Apache was to broaden the community
> and broaden the appeal.  When I say "Mifos contributed" I also mean to say
> all of the contributors to the Mifos project, who worked on it as an open
> source project from 2005 to present, are part of that. It is accurate to
> say that the Mifos community was already an active one and a key
> accomplishment over the past two years is bringing over the code and the
> community to Apache.  But more needs to be done to clarify.
>
> Mifos community code (also released under apache 2.0) is now a wrapper on
> top of fineract. Fineract can include binary releases for convenience but
> the code is the thing, not the productization. Mifos is also continuing to
> play an important role in organizing the community of financial inclusion
> around fineract - I submit that that is not inconsistent with the PMC
> trying to market fineract to both the financial inclusion community and the
> private sector interested in payments, banking, etc.  As a non-profit,
> Mifos has much of the same operating imperatives as Apache, but with a
> narrower focus on financial inclusion. We probably need advice from our
> apache friends how to address this dual role.
>
> Finally, I am inspired by what so many have accomplished on the mifosX →
> now fineract 1.x codebase and what is promised by the fineract-CN code.  I
> continue to envision fineract in the broadest and more inspiring terms.
> Opensource will eat the world and the financial world is only beginning to
> be heard from us.
>
>
> Please do comment on this post and suggest ways to operationalize or object
> and say why. THANK YOU!!
>
> James Dailey
>
> Fineract’r
>
> Board Chair, Mifos