Page tree
Skip to end of metadata
Go to start of metadata

Being a committer in FINERACT is a responsibility that we wish to encourage as many good contributors as possible to share with us.  It is also an honor which is earned by good behavior.

Apache explains what values underlie Apache community work here:

FINERACT will designate contributors to committers via the following process.

  1. A current committer will decide to sponsor a contributor.
  2. The sponsor will propose via the private mailing list, that a contributor be made a committer. The sponsor should explain why he or she believes the contributor should be made a committer.  At this point it would be unkind to inform the contributor in case the proposal fails the vote.
  3. If within 72 hours of the proposal, no committers have vetoed the proposal, the proposal is accepted.
  4. The sponsor will ask the contributor if he or she wishes to become a committer.
  5. If contributor so desires, the sponsor will set in motion the processes necessary to add a new committer to FINERACT.

If a contributor is vetoed there is no need to inform him or her that a vote occurred.  Depending on the reason for a veto, the question may be raised again at a later date.

Because committers determine who will become committers, they need to be able to recognize good committers.  A good committer also has other qualities.

Developer committer qualities

To be made a developer committer, a contributor should have developed experience with FINERACT by

  • creating bug fixes AND programming features,
  • producing multiple high quality code changes as determined by an existing committer using the Code Review Guide,
  • owning and fixing their own mistakes, and
  • mentoring other contributors.

Community Liaison Committer qualities

To be made a community liaison committer, a contributor should have developed experience with FINERACT by

  • helping other users learn to use FINERACT,
  • helping programmers learn what users need by providing detailed business requirements and use cases required for functional specifications,
  • testing FINERACT for correctness, robustness, scaleability, security, or usability, and reporting bugs and issues found,
  • connecting users with complementary needs with each other,
  • supporting implementers and users of FINERACT with best practices and lessons learned from practical implementation,
  • writing documentation and tutorials for usage of FINERACT and design of financial services,
  • owning and fixing their mistakes, and
  • mentoring other contributors.

Developer committer rights and responsibilities

Community Liaison Committer rights and responsibilities

  • Everything listed in
  • Prioritizing and refining user stories and tickets on JIRA. 
  • Moderating and maintaining functional documentation on FINERACT.
  • Taking part in conversations on the dev mailing list when he or she has something to contribute.

PMC member rights and responsibilities

  • Taking part in conversations on the private mailing list and keeping those conversations private.
  • Proposing new committers and new PMC members.
  • Representing Apache Fineract to the ASF Board.
  • Occasionally cleaning up the committer list.

How to clean up the committer list

  • Look for committers who have not performed any visible public action listed above for at least 6 months.
  • Write to each such committer to ask them if they still wish to be a committer.
  • Anyone who responds that they no longer wish to be a committer can be removed from the committer list, thus loosing all rights and responsibilities associated with being a committer.
  • Anyone who does not respond in four weeks can be removed from the committer list, thus loosing all rights and responsibilities associated with being a committer.
  • Any committer can at any time request removal from the committer list.
  • No labels


  1. Should we add non-developers too, e.g. a contributor that provides support, sufficient input for features, or does hardcore testing. I guess if a contributor is very engaged with our project, and helps out with support or product management capabilities it feels natural to me making him a committer.

    1. +1, through the nature of the project I think it will be good to properly recognise (and 'reward') input from business people, etc. 

      Otherwise nice work on the overview, think this is definitely a great start and can be adapted over time based on initial experiences. 

    2. What you're saying seems to match the Apache philosophy too.  ( I suggest you and Sander (at least) fill out the TODOs I've added for what I've called a Community Liaison Committer.

  2. More general point: Are there any thoughts on the reverse process, eg people who are committers but have gone quiet and not really done anything in the project for a long time? Can also see that this might be something to be left for a later date.

    1. As far as I know it is unusual to revoke a committer. If they cease from the project, they simply stay quite. But this maybe is something we can extend the current process for?

    2. I'll add a bit to the proposal for this.

  3. So I've added a section to the proposal for this.  What this doesn't cover though is removing a committer who has gone rogue.  I'm just going to assume that doesn't happen, and that if it does happen we'll find a solution then.

    1. What do you think about adding the CoPDoC principle?

      This should provide some rough guidelines in general.

  4. I've relaxed the proposed voting requirements to simply no veto, based on the consensus in other areas to avoid voting.

  5. I've added a few additional details to the qualities and rights and responsibilities of committers.