Re: A page on confluence for who are committers etc
Hi Sendoro - In principle, this is great - it would make the project more accessible. When someone responds on list you'd have a sense of who they are and what they are expert in, and if you have a key question you could @keyPerson to bring it to their attention. However, I am worried about the overhead. We already have, in this vein: 1) https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74690173 which is quickly out of date, although we could do a review more often. 2) PMC Report - https://cwiki.apache.org/confluence/display/FINERACT/2018-07+July+Report which is a quarterly report. 3) Open Issues for both Fineract and Fineract-CN projects (currently at 378?? ) and in that list who is reporter and who is assignee. https://issues.apache.org/jira/issues/?filter=-5&jql=project%20%3D%20FINERACT%20AND%20resolution%20%3D%20Unresolved%20order%20by%20priority%20DESC%2Cupdated%20DESC 4) Inside Apache I believe that there are some analytic tools that can be used - perhaps they could be dynamically linked into one of the wiki pages (include) ...which could help see who is submitting Pull Requests and who is active on this list? Don't know if that would be useful but could try. 5) Outside of the Apache infrastructure there are tracking tools we could potentially link to that would generate automatic reports on Contributors and code changes. Prominent among them is https://www.openhub.net/p/fineract (historical aside, Mifos was a beta participant in ohloh open source project stats, which was acquired by openhub, so there is some history to using this, and it gives us favorable analysis compared to other Apache projects) So, I think we should consider what is already there and figure out if some sort of enhanced directory would be useful? I would imagine something that links automatically to the jira tickets and other resources. i.e. so in one place you have the Committer name and a link to their PRs and a quick profile perhaps pulled from linked in or otherwise to keep it fresh. We should explore what other projects do. *Any Apache experts on list to comment? * Thanks, James On Tue, Sep 11, 2018 at 10:08 AM Sendoro Juma wrote: > Hello Devs, > > Yes, we do announcement on who has become a committer etc. and we send > congratulates emails and after that all stay and left in mailing list in > form of emails. > > However, how can a new members know the committers and their roles easily > by visiting Fineract Page? > > I think a page in Fineract can help... > > Will love also if roles can be indicated e.g. We have committers who are > known to be great in Quality Assurance etc. > > So it can look like below. Sorry with no number as can be considered as > hierarchy > > Developers > > Xxx > > Xxx > > Xxx > > Quality Assurance > > xxx > > xxx > > Xxx > > Release Management > > > > > > Documentation > > xxx > > xxx > > xxx > > > Also... You can as well list module wise Etc > > What is your view? > > I recall saw one community with this... I forgotten it. > > WBR > > Sendoro >
A page on confluence for who are committers etc
Hello Devs, Yes, we do announcement on who has become a committer etc. and we send congratulates emails and after that all stay and left in mailing list in form of emails. However, how can a new members know the committers and their roles easily by visiting Fineract Page? I think a page in Fineract can help... Will love also if roles can be indicated e.g. We have committers who are known to be great in Quality Assurance etc. So it can look like below. Sorry with no number as can be considered as hierarchy Developers Xxx Xxx Xxx Quality Assurance xxx xxx Xxx Release Management Documentation xxx xxx xxx Also... You can as well list module wise Etc What is your view? I recall saw one community with this... I forgotten it. WBR Sendoro
Re: PR Reviews
Thanks James for driving this topic, summarizing, and documenting. Ed On Tue, Sep 11, 2018 at 8:42 AM Sendoro Juma wrote: > +1 > > > > > On Tue, Sep 11, 2018 at 5:12 PM +0200, "James Dailey" < > jamespdai...@gmail.com> wrote: > > > > > > > > > > > I put the content here: > https://cwiki.apache.org/confluence/display/FINERACT/Committer%27s+Zone > > > > On Tue, Sep 11, 2018 at 1:43 AM Myrle Krantz wrote: > > > Hey all, > > > > I believe that James has correctly captured the consensus and would > > encourage him to document that. > > > > James if you need any help finding a good spot in the wiki for that, just > > shout. > > > > Best Regards, > > Myrle > > On Tue, Sep 11, 2018 at 8:47 AM Sendoro Juma wrote: > > > > > > +1 > > > > > > > > > > > > > > > For document... Any change improvement will be done in the document > > page... > > > > > > > > > > > > > > > I would also like the page to indicate... > > > > > > > > > > > > > > > On Tue, Sep 11, 2018 at 4:40 AM +0200, "James Dailey" < > > jamespdai...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all - I will comment that I think this is directionally great. > > > > > > As Sendoro suggested: > > > 1) The dev A should try to ask a specific person(s) to review if they > > can, > > > as in dev B, and to anyway give the list some time to review the PR. > > Then > > > 72 hrs later or so, they're able to commit their own PR under a > principle > > > of lazy consensus. This also assumes that people are fully discussing > > > their ideas for a PR in advance and there is a jira issue where the > > > requirements are documented. > > > > > > 2) The Committer may decide that the proposed PR is significant enough > > that > > > they really want someone to review and they can flag that too. > > > > > > Also, the other part of my suggestion (and the really cool insight at > > > Apache) was that: > > > 3) Members of the community who are NOT yet committers would be welcome > > to > > > pitch in on the review, thus earning karma. This creates a dynamic > where > > > devs can give feedback and quality review without taking on a task of > dev > > > themselves. +1 for the reviewer. > > > > > > > > > I also think Myrle is right in that we don't need a vote, but hope that > > > others will weigh in and consider so we can have a sense of consensus. > > If > > > not, our lazy consensus ideal is that we're in agreement...but first > > let's > > > keep discussion going. > > > > > > I'm happy to document the above on wiki if that's useful. Not sure > what > > > else is needed aside from the 1, 2, 3. Thoughts? > > > > > > James > > > > > > On Wed, Aug 29, 2018 at 11:05 AM Myrle Krantz wrote: > > > > > > > Hi all, > > > > > > > > I suggest we give people a chance to give input before we complete > the > > > > decision making process. If we converge on common ground we may not > > need > > > > to vote at all. We may just need someone to summarize the consensus > > and > > > > document it in wiki. > > > > > > > > I like Sendoro's suggestion. I don't see a need to hurry PR's merges > > to > > > > faster than 72 hours, and I'd like people to look at each other's > code > > to > > > > increase quality, but if we can't get people to do that, it shouldn't > > block > > > > progress. > > > > > > > > Best Regards, > > > > Myrle > > > > > > > > > > > > On Wed 29. Aug 2018 at 08:03 Mexina Daniel wrote: > > > > > > > > > Hello Ed > > > > > > > > > > Thank you for the prompt reply, > > > > > > > > > > So do we have to vote for James's proposal or we can implement it > > from > > > > now > > > > > on? > > > > > > > > > > Hello Sendoro > > > > > > > > > > Thanks for more inputs, > > > > > > > > > > Adding to that, i think even non-committers should be involved in > > > > > reviewing i.e non-committer A can review to any submitted PR that > > hasn't > > > > > started to be reviewed. > > > > > > > > > > Best Regards > > > > > > > > > > > On August 28, 2018 at 11:06 PM Sendoro Juma > > > > > wrote: > > > > > > > > > > > > > > > > > > Dear Ed, Mexina, > > > > > > > > > > > > > > > > > > I would wish we meet at the middle... '"Peer Review", i.e. > > > > > committer A, ask committer B reviewing his/her PR. and vice > versa... > > > > > > > > > > > > > > > > > > However, as rule like you said if not happen in 72 hours.. > then > > > > > Committer A can proceed especially when s/he is sure Quality of > > his/her > > > > PR. > > > > > > > > > > > > > > > > > > How about that? > > > > > > > > > > > > > > > > > > > > > On August 28, 2018 at 7:16 PM Ed Cable > > > > > wrote: > > > > > > > > > > > > > > Mexina, > > > > > > > > > > > > > > Thank you for picking up on James' thread and putting > it > > into > > > > > action with > > > > > > > some spot-on questions. > > > > > > > > > > > > > > Please see my replies inline: > > > > > > > > > > > > > > On Tue, Aug 28, 2018 at 6:46 AM Mexina
A page on confluence for who are committers etc
Hello Devs, Yes, we announcement on who has become commiter etc. and we congratulates and all left on mailing list. However, how can a new members know the committers and their roles I think a page in Fineract can help... Will love also if roles can be indicated e.g. We have committers who are known to be great in Quality Assurance etc. So it can look like below. Sorry with no number as can be considered as hierarchy Developers Xxx Xxx Xxx Quality Assurance xxx xxx Xxx Release Management Also... You can as well list module wise Etc What is your view? I recall saw one community with this... I forgotten it. WBR Sendoro
Re: PR Reviews
+1 On Tue, Sep 11, 2018 at 5:12 PM +0200, "James Dailey" wrote: I put the content here: https://cwiki.apache.org/confluence/display/FINERACT/Committer%27s+Zone On Tue, Sep 11, 2018 at 1:43 AM Myrle Krantz wrote: > Hey all, > > I believe that James has correctly captured the consensus and would > encourage him to document that. > > James if you need any help finding a good spot in the wiki for that, just > shout. > > Best Regards, > Myrle > On Tue, Sep 11, 2018 at 8:47 AM Sendoro Juma wrote: > > > > +1 > > > > > > > > > > For document... Any change improvement will be done in the document > page... > > > > > > > > > > I would also like the page to indicate... > > > > > > > > > > On Tue, Sep 11, 2018 at 4:40 AM +0200, "James Dailey" < > jamespdai...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi all - I will comment that I think this is directionally great. > > > > As Sendoro suggested: > > 1) The dev A should try to ask a specific person(s) to review if they > can, > > as in dev B, and to anyway give the list some time to review the PR. > Then > > 72 hrs later or so, they're able to commit their own PR under a principle > > of lazy consensus. This also assumes that people are fully discussing > > their ideas for a PR in advance and there is a jira issue where the > > requirements are documented. > > > > 2) The Committer may decide that the proposed PR is significant enough > that > > they really want someone to review and they can flag that too. > > > > Also, the other part of my suggestion (and the really cool insight at > > Apache) was that: > > 3) Members of the community who are NOT yet committers would be welcome > to > > pitch in on the review, thus earning karma. This creates a dynamic where > > devs can give feedback and quality review without taking on a task of dev > > themselves. +1 for the reviewer. > > > > > > I also think Myrle is right in that we don't need a vote, but hope that > > others will weigh in and consider so we can have a sense of consensus. > If > > not, our lazy consensus ideal is that we're in agreement...but first > let's > > keep discussion going. > > > > I'm happy to document the above on wiki if that's useful. Not sure what > > else is needed aside from the 1, 2, 3. Thoughts? > > > > James > > > > On Wed, Aug 29, 2018 at 11:05 AM Myrle Krantz wrote: > > > > > Hi all, > > > > > > I suggest we give people a chance to give input before we complete the > > > decision making process. If we converge on common ground we may not > need > > > to vote at all. We may just need someone to summarize the consensus > and > > > document it in wiki. > > > > > > I like Sendoro's suggestion. I don't see a need to hurry PR's merges > to > > > faster than 72 hours, and I'd like people to look at each other's code > to > > > increase quality, but if we can't get people to do that, it shouldn't > block > > > progress. > > > > > > Best Regards, > > > Myrle > > > > > > > > > On Wed 29. Aug 2018 at 08:03 Mexina Daniel wrote: > > > > > > > Hello Ed > > > > > > > > Thank you for the prompt reply, > > > > > > > > So do we have to vote for James's proposal or we can implement it > from > > > now > > > > on? > > > > > > > > Hello Sendoro > > > > > > > > Thanks for more inputs, > > > > > > > > Adding to that, i think even non-committers should be involved in > > > > reviewing i.e non-committer A can review to any submitted PR that > hasn't > > > > started to be reviewed. > > > > > > > > Best Regards > > > > > > > > > On August 28, 2018 at 11:06 PM Sendoro Juma > > > > wrote: > > > > > > > > > > > > > > > Dear Ed, Mexina, > > > > > > > > > > > > > > > I would wish we meet at the middle... '"Peer Review", i.e. > > > > committer A, ask committer B reviewing his/her PR. and vice versa... > > > > > > > > > > > > > > > However, as rule like you said if not happen in 72 hours.. then > > > > Committer A can proceed especially when s/he is sure Quality of > his/her > > > PR. > > > > > > > > > > > > > > > How about that? > > > > > > > > > > > > > > > > > > On August 28, 2018 at 7:16 PM Ed Cable > > > > wrote: > > > > > > > > > > > > Mexina, > > > > > > > > > > > > Thank you for picking up on James' thread and putting it > into > > > > action with > > > > > > some spot-on questions. > > > > > > > > > > > > Please see my replies inline: > > > > > > > > > > > > On Tue, Aug 28, 2018 at 6:46 AM Mexina Daniel > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hello fineract'ers > > > > > > > > > > > > > > Can someone help me to understand few things: > > > > > > > > > > > > > >1. Should the PR be reviewed by someone (who > can be > > > a > > > > committer or not) > > > > > > > before being merged or a committer can merge > > > > his/her PR even if it hasn't > > > > > > > being reviewed by anyone? > > > > >
Re: PR Reviews
I put the content here: https://cwiki.apache.org/confluence/display/FINERACT/Committer%27s+Zone On Tue, Sep 11, 2018 at 1:43 AM Myrle Krantz wrote: > Hey all, > > I believe that James has correctly captured the consensus and would > encourage him to document that. > > James if you need any help finding a good spot in the wiki for that, just > shout. > > Best Regards, > Myrle > On Tue, Sep 11, 2018 at 8:47 AM Sendoro Juma wrote: > > > > +1 > > > > > > > > > > For document... Any change improvement will be done in the document > page... > > > > > > > > > > I would also like the page to indicate... > > > > > > > > > > On Tue, Sep 11, 2018 at 4:40 AM +0200, "James Dailey" < > jamespdai...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi all - I will comment that I think this is directionally great. > > > > As Sendoro suggested: > > 1) The dev A should try to ask a specific person(s) to review if they > can, > > as in dev B, and to anyway give the list some time to review the PR. > Then > > 72 hrs later or so, they're able to commit their own PR under a principle > > of lazy consensus. This also assumes that people are fully discussing > > their ideas for a PR in advance and there is a jira issue where the > > requirements are documented. > > > > 2) The Committer may decide that the proposed PR is significant enough > that > > they really want someone to review and they can flag that too. > > > > Also, the other part of my suggestion (and the really cool insight at > > Apache) was that: > > 3) Members of the community who are NOT yet committers would be welcome > to > > pitch in on the review, thus earning karma. This creates a dynamic where > > devs can give feedback and quality review without taking on a task of dev > > themselves. +1 for the reviewer. > > > > > > I also think Myrle is right in that we don't need a vote, but hope that > > others will weigh in and consider so we can have a sense of consensus. > If > > not, our lazy consensus ideal is that we're in agreement...but first > let's > > keep discussion going. > > > > I'm happy to document the above on wiki if that's useful. Not sure what > > else is needed aside from the 1, 2, 3. Thoughts? > > > > James > > > > On Wed, Aug 29, 2018 at 11:05 AM Myrle Krantz wrote: > > > > > Hi all, > > > > > > I suggest we give people a chance to give input before we complete the > > > decision making process. If we converge on common ground we may not > need > > > to vote at all. We may just need someone to summarize the consensus > and > > > document it in wiki. > > > > > > I like Sendoro's suggestion. I don't see a need to hurry PR's merges > to > > > faster than 72 hours, and I'd like people to look at each other's code > to > > > increase quality, but if we can't get people to do that, it shouldn't > block > > > progress. > > > > > > Best Regards, > > > Myrle > > > > > > > > > On Wed 29. Aug 2018 at 08:03 Mexina Daniel wrote: > > > > > > > Hello Ed > > > > > > > > Thank you for the prompt reply, > > > > > > > > So do we have to vote for James's proposal or we can implement it > from > > > now > > > > on? > > > > > > > > Hello Sendoro > > > > > > > > Thanks for more inputs, > > > > > > > > Adding to that, i think even non-committers should be involved in > > > > reviewing i.e non-committer A can review to any submitted PR that > hasn't > > > > started to be reviewed. > > > > > > > > Best Regards > > > > > > > > > On August 28, 2018 at 11:06 PM Sendoro Juma > > > > wrote: > > > > > > > > > > > > > > > Dear Ed, Mexina, > > > > > > > > > > > > > > > I would wish we meet at the middle... '"Peer Review", i.e. > > > > committer A, ask committer B reviewing his/her PR. and vice versa... > > > > > > > > > > > > > > > However, as rule like you said if not happen in 72 hours.. then > > > > Committer A can proceed especially when s/he is sure Quality of > his/her > > > PR. > > > > > > > > > > > > > > > How about that? > > > > > > > > > > > > > > > > > > On August 28, 2018 at 7:16 PM Ed Cable > > > > wrote: > > > > > > > > > > > > Mexina, > > > > > > > > > > > > Thank you for picking up on James' thread and putting it > into > > > > action with > > > > > > some spot-on questions. > > > > > > > > > > > > Please see my replies inline: > > > > > > > > > > > > On Tue, Aug 28, 2018 at 6:46 AM Mexina Daniel > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hello fineract'ers > > > > > > > > > > > > > > Can someone help me to understand few things: > > > > > > > > > > > > > >1. Should the PR be reviewed by someone (who > can be > > > a > > > > committer or not) > > > > > > > before being merged or a committer can merge > > > > his/her PR even if it hasn't > > > > > > > being reviewed by anyone? > > > > > > > > > > > > > > > > > > > > > > In the spirit of James' email
Re: [ANNOUNCE] New Apache Fineract Committer James Dailey
Congratulations James! I'm looking forward to continuing to work with you! Best Regards, Myrle Krantz On Tue, Sep 11, 2018 at 9:34 AM Shreyank Byadagi wrote: > > Congratulations James! > > Thanks > Shreyank > > On Tue, Sep 11, 2018 at 12:12 PM Dingfan Zhao > wrote: > > > Congratulations James! > > > > Regards, > > Dingfan > > > > > On 8 Sep 2018, at 8:15 AM, Ed Cable wrote: > > > > > > Hello Fineract community! > > > I'm happy to announce that Apache Fineract has a new committer. > > > > > > James is in fact the longest standing member of the Mifos and Fineract > > > community as he is the origin of the project as the original founder and > > > visionary behind Mifos back when it started as MOAP within Grameen > > > Foundation - http://moap.sourceforge.net/. > > > > > > See this post for more on the roots of Mifos, now Fineract and James' > > story > > > - http://mifos.org/blog/the-roots-of-the-mifos-initiative/ > > > > > > Throughout the years, James has been an active member of the community. > > > Most recently he's helped the community stay on the pulse of payments and > > > digital financial services through valuable valuable insight he provides > > > regularly on the mailing lists as a consultant to the Gates Foundation on > > > their Level One Project. James has also shared his expertise on pay as > > you > > > go clean energy solutions. > > > > > > While not a developer, James has contributed significantly in sharing > > > requirements and spearheading discussions across a variety of subjects on > > > the mailing lists. He has provided valuable feedback and insight into > > > forward-looking architectures for banking and financial inclusion. Most > > > recently he's been stewarding critical discussions on payments > > integration > > > and the alignment between Apache Fineract and Mojaloop. He recently has > > > been spearheading efforts to improve our processes and fix the > > contribution > > > model for the community. > > > > > > James is eager to come on board as a committer and become more deeply > > > involved in the Apache Fineract community. > > > > > > Congratulations James! Thank you for your contributions, and thank > > > you for accepting our invitation! We look forward to continuing to > > > work together with you. > > > > > > Best Regards, > > > > > > Ed Cable > > > Apache Fineract > > > > > > P.S. James, would you mind if we announce your committership on social > > > media? > > > >
Re: PR Reviews
Hey all, I believe that James has correctly captured the consensus and would encourage him to document that. James if you need any help finding a good spot in the wiki for that, just shout. Best Regards, Myrle On Tue, Sep 11, 2018 at 8:47 AM Sendoro Juma wrote: > > +1 > > > > > For document... Any change improvement will be done in the document page... > > > > > I would also like the page to indicate... > > > > > On Tue, Sep 11, 2018 at 4:40 AM +0200, "James Dailey" > wrote: > > > > > > > > > > > Hi all - I will comment that I think this is directionally great. > > As Sendoro suggested: > 1) The dev A should try to ask a specific person(s) to review if they can, > as in dev B, and to anyway give the list some time to review the PR. Then > 72 hrs later or so, they're able to commit their own PR under a principle > of lazy consensus. This also assumes that people are fully discussing > their ideas for a PR in advance and there is a jira issue where the > requirements are documented. > > 2) The Committer may decide that the proposed PR is significant enough that > they really want someone to review and they can flag that too. > > Also, the other part of my suggestion (and the really cool insight at > Apache) was that: > 3) Members of the community who are NOT yet committers would be welcome to > pitch in on the review, thus earning karma. This creates a dynamic where > devs can give feedback and quality review without taking on a task of dev > themselves. +1 for the reviewer. > > > I also think Myrle is right in that we don't need a vote, but hope that > others will weigh in and consider so we can have a sense of consensus. If > not, our lazy consensus ideal is that we're in agreement...but first let's > keep discussion going. > > I'm happy to document the above on wiki if that's useful. Not sure what > else is needed aside from the 1, 2, 3. Thoughts? > > James > > On Wed, Aug 29, 2018 at 11:05 AM Myrle Krantz wrote: > > > Hi all, > > > > I suggest we give people a chance to give input before we complete the > > decision making process. If we converge on common ground we may not need > > to vote at all. We may just need someone to summarize the consensus and > > document it in wiki. > > > > I like Sendoro's suggestion. I don't see a need to hurry PR's merges to > > faster than 72 hours, and I'd like people to look at each other's code to > > increase quality, but if we can't get people to do that, it shouldn't block > > progress. > > > > Best Regards, > > Myrle > > > > > > On Wed 29. Aug 2018 at 08:03 Mexina Daniel wrote: > > > > > Hello Ed > > > > > > Thank you for the prompt reply, > > > > > > So do we have to vote for James's proposal or we can implement it from > > now > > > on? > > > > > > Hello Sendoro > > > > > > Thanks for more inputs, > > > > > > Adding to that, i think even non-committers should be involved in > > > reviewing i.e non-committer A can review to any submitted PR that hasn't > > > started to be reviewed. > > > > > > Best Regards > > > > > > > On August 28, 2018 at 11:06 PM Sendoro Juma > > > wrote: > > > > > > > > > > > > Dear Ed, Mexina, > > > > > > > > > > > > I would wish we meet at the middle... '"Peer Review", i.e. > > > committer A, ask committer B reviewing his/her PR. and vice versa... > > > > > > > > > > > > However, as rule like you said if not happen in 72 hours.. then > > > Committer A can proceed especially when s/he is sure Quality of his/her > > PR. > > > > > > > > > > > > How about that? > > > > > > > > > > > > > > > On August 28, 2018 at 7:16 PM Ed Cable > > > wrote: > > > > > > > > > > Mexina, > > > > > > > > > > Thank you for picking up on James' thread and putting it into > > > action with > > > > > some spot-on questions. > > > > > > > > > > Please see my replies inline: > > > > > > > > > > On Tue, Aug 28, 2018 at 6:46 AM Mexina Daniel > > > wrote: > > > > > > > > > > > > > > > > > > > Hello fineract'ers > > > > > > > > > > > > Can someone help me to understand few things: > > > > > > > > > > > >1. Should the PR be reviewed by someone (who can be > > a > > > committer or not) > > > > > > before being merged or a committer can merge > > > his/her PR even if it hasn't > > > > > > being reviewed by anyone? > > > > > > > > > > > > > > > > > > > In the spirit of James' email requesting a cultural change > > > around PRs and > > > > > the feedback from Ross on minimizing any barriers to > > > contribution, James > > > > > had proposed and I vouch we adopt a lazy consensus policy > > > around committers > > > > > being able to merge their own PRs - if nobody objects within > > > 72 hours, the > > > > > committer can merge their own PR. As James puts, if it > > breaks, > > > it can be > > > > > unmerged. This would be a shift from our current
Re: [ANNOUNCE] New Apache Fineract Committer James Dailey
Congratulations James! Thanks Shreyank On Tue, Sep 11, 2018 at 12:12 PM Dingfan Zhao wrote: > Congratulations James! > > Regards, > Dingfan > > > On 8 Sep 2018, at 8:15 AM, Ed Cable wrote: > > > > Hello Fineract community! > > I'm happy to announce that Apache Fineract has a new committer. > > > > James is in fact the longest standing member of the Mifos and Fineract > > community as he is the origin of the project as the original founder and > > visionary behind Mifos back when it started as MOAP within Grameen > > Foundation - http://moap.sourceforge.net/. > > > > See this post for more on the roots of Mifos, now Fineract and James' > story > > - http://mifos.org/blog/the-roots-of-the-mifos-initiative/ > > > > Throughout the years, James has been an active member of the community. > > Most recently he's helped the community stay on the pulse of payments and > > digital financial services through valuable valuable insight he provides > > regularly on the mailing lists as a consultant to the Gates Foundation on > > their Level One Project. James has also shared his expertise on pay as > you > > go clean energy solutions. > > > > While not a developer, James has contributed significantly in sharing > > requirements and spearheading discussions across a variety of subjects on > > the mailing lists. He has provided valuable feedback and insight into > > forward-looking architectures for banking and financial inclusion. Most > > recently he's been stewarding critical discussions on payments > integration > > and the alignment between Apache Fineract and Mojaloop. He recently has > > been spearheading efforts to improve our processes and fix the > contribution > > model for the community. > > > > James is eager to come on board as a committer and become more deeply > > involved in the Apache Fineract community. > > > > Congratulations James! Thank you for your contributions, and thank > > you for accepting our invitation! We look forward to continuing to > > work together with you. > > > > Best Regards, > > > > Ed Cable > > Apache Fineract > > > > P.S. James, would you mind if we announce your committership on social > > media? > >
