RTBkit uses a variation on the Benevolent Dictator model for open source governance. As the community grows and various external contributors take on more responsibilities, RTBkit will move more towards a Meritocracy.



RTBkit follows on the footsteps of the open source communities everywhere, with the following roles:

  • User (anyone using RTBkit)
  • Member (anyone sharing with the community)
  • Committer (people with commit access to the RTBkit repositories)
  • Councilor (members of the RTBkit Council who set the project direction)


  • People who use the RTBkit package or
  • Involved in any activity related to RTBkit, trying or using the code
  • Reporting bugs
  • Making feature requests
  • Testing
  • Participating in events, etc.


  • Community Members are volunteers sharing knowledge and code with the community.
  • Correctly answering a question on the mailing list, for example, will elevate a User to Member level upon request.
  • The names will be published on the project’s website and announced to the mailing list in order to recognize the members.


  • The Committer role is granted by the  RTBkit Council: they are proposed by a councilor and a vote will take place.
  • Committers agree to promote and enforce the RTBkit goals as determined by the RTBkit council.
  • Committers have write access to the RTBkit code repository, which they may use to merge pull requests that go through the process detailed below.
  • Committers may submit and vote on pull requests.
  • Their status can be revoked.
  • Committers have no authority over the project’s direction.
  • Their voice carries a lot of weight in the decisions made by the councilors.
  • Committers do not represent their employers, but themselves (if they change jobs, they stay Committers). 

RTBKit Councilor

  • The RTBkit councilors are named by the RTBkit Council, based on business needs or in response to extraordinary levels of individual contributions to the community. 
  • RTBkit councilors are Committers ex officio.
  • The RTBkit Council sets the project direction and project goals and reserves the right to veto proposals.
  • Councilors may be independent, or named on behalf of their employers.
  • For example, strategic partners may have reserved seats in the council, where named employees will carry on their mandate.
  • The councilors will have a public profile and their allegiances are visible.

Types of councilors:


  • contributes to the official goals and roadmap either through new ideas or by sponsoring ideas from the community and introducing them on the roadmap.
  • Votes publicly on issues, but has no veto power.
  • Can propose adding new Committer or Council members, or propose removal of existing members.

Project Maintainer

  • votes on issues without veto power
  • communicates decisions to the community
  • wiki page maintainer
  • general admin work including permissions, announcements, and vote counts.

Benevolent Dictator

  • listens to the councilors and mandates the implementation of all decisions.
  • has veto power.
  • can resign, or can be ousted by a simple majority of the council upon which he/she returns to the Councilor role.




RTBkit distinguishes between two types of contributions:

  1. Bug fixes and code contributions that fit within the existing design
  2. Major new feature​s and changes that affect the code base in a fundamental way

While type 1 contributions are generally manageable via pull requests, type 2 contributions are trickier to manage. For the latter, by the time contributors have reached the stage where they submit a pull request, they are usually quite heavily emotionally invested in their code and rejection is usually a major source of frustration. The proposal below explicitly addresses this by first asking any contributor to propose a design which can then be discussed and vetted by the community. Once the design is approved, contributors have a much greater assurance that their contribution will be accepted. Additionally this gives other stakeholders the chance to influence the design.

Pull Requests

  • Committers must not push changes onto the master branch without submitting a pull request.
  • Anyone can submit a pull request:
    • Committers can submit a pull request for their own changes at which point discussion may happen on the mailing list. After discussions, Committers will vote and Lazy Consensus operates. If after 3 business days there are at least 3 positive votes, no negative votes and no veto, the Committer can push to the master branch.
    • Contributors and Users can also submit Pull Requests. After discussions, Committers will vote is requested and Lazy Consensus operates. If after 7 business days there are at least 3 positive votes, no negative votes and no veto, any Committer can push to Master. A Committer will volunteer to sponsor the Pull and follow it through, including committing to Master if approved.

Lazy consensus

Decision making typically involves the following steps:

  • proposal
  • discussion
  • a vote if consensus is not reached through discussion, and a lack of veto by the Benevolent Dictator.

Anyone can:

  • send a proposal for consideration to the RTBkit mailing list: this will be discussed (and/or voted on) by the RTBkit Council
  • submit a pull request implementing the idea to Github: this will be discussed (and/or voted on) on by the Committers

We encourage people to submit ideas for review before investing in writing substantial amounts of code. The Committers and Councilors will have valuable input.


  • The processes are based on the Apache Foundation guidelines.
  • Votes will happen on the mailing list whenever a call to vote is issued:
    • Committers can participate in votes on pull requests
    • RTBkit Councilors can participate in votes on major change proposals, project goals, architecture or direction
  • After the appropriate interval the proposal is accepted If there are at least 3 positive votes, no negative votes
    • the interval is 3 business days for a Commiter's pull request or 7 days for any other pull request
    • the interval is 3 business days for proposals by an RTBkit Councilor for goals/architecture proposals
  • Votes are represented as numbers between --1 and ++1, '-1' meaning 'no' and '+1' meaning 'yes.' The in-between values are indicative of how strongly the voting individual feels.
    • -1: No (Not a Veto)
    • +0: 'I don't feel strongly about it, but I'm okay with this.'
    • -0: 'I won't get in the way, but I'd rather we didn't do this.'
    • -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.'
    • ++1: 'Wow! I like this! Let's do it together!'
    • --1: Veto. There can be only one such vote from the Benevolent Dictator. The proposal is dead unless the veto is withdrawn.
    • -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'
    • +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.'

How to Submit a Bug Report

Bug reports should be submitted using GitHub issues with the label “bug”.  Before submitting a bug report users are encouraged to first describe the problem on the mailing list to confirm that it is indeed a bug. This helps avoid entering spurious entries in the bug database

How to Submit an Enhancement/Feature Request

Enhancement requests should be submitted using GitHub issues with the “enhancement” label. A design proposal can be submitted in the description or in the comments and interested parties can participate in reviewing the proposal. Once the design is accepted

How to Submit a Bug Fix

Bug fixes should be submitted using GitHub pull requests. These can be reviewed by the community and will be merged into RTBkit by the maintainers and committers. Instructions on how to do this can be found at the following address:



Mathieu Stefani, Jean-Michel Bouchard, Jean-Sebastien Bejeau, Jean Raby, Jan Sulmont, Michael Ben-David, Nicolas Emiliani, Sunil Rottoo , Eric Robert, Marc Vieira-Cardinal, Nicolas Kruchten, Mark Weiss, Francois Maillet, Jeremy Barnes.

Benevolent Dictator:

Rémi Attab


Datacratic: Sunil Rottoo , Remi Attab, Eric Robert, Alex Iancu (Project Maintainer), Marc Vieira-Cardinal, Nicolas Kruchten, Mark Weiss, Francois Maillet. 

Contributor Agreement

The goal of this CLA is to establish clear rules for individuals and companies wishing to contribute to the development of RTBkit, so that the RTBkit community can continue to use RTBkit without needing to worry about legal encumbrances. 
In order to clarify the intellectual property license granted with Contributions from any person or entity, the RTBkit Project Stewards (“Stewards”) must have a Contributor License Agreement ("CLA") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Stewards and the users of RTBkit; it does not change your rights to use your own Contributions for any other purpose.
  • Individual contributors, please enter your name and email address and you will be redirected to the Adobe Echosign form.
  • Corporate contributors, please visit our Corporate CLA page to download a physical copy of the agreement for you to sign and mail in.