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