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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > > 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 > > > > > >
