Governance

Datacratic follows a variation of the Benevolent Dictator model. As the community grows and various external contributors take on more responsibilities, RTBKit will move more towards a Meritocracy.

 

Roles

RTBKit follows on the footsteps of the open source communities everywhere:

The User and Contributor: granted to anyone using the software and participating in the community (website, mailing list, wiki, events, etc). The Committer role is granted by the  RTBKit Council, and invitations to join are at the discretion of Datacratic. The RTBKit councilors are named by Datacratic, based on business needs or in response to extraordinary levels of individual contributions to the community. 

User

  • 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.
  • Users represent themselves and not their employers.

Contributor

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

Committer

  • The Committer role is granted by the  RTBKit Council, and invitations to join are at the discretion of Datacratic.
  • Contributors are promoted to Committer at the latitude of the Council.
  • They are proposed by a councilor and a vote will take place.
  • A Committer has write access to the RTBKit code repository.
  • They must obey by the Committer Guidelines
  • 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. 

RTBKit Councilor

  • The RTBKit councilors are named by Datacratic, based on business needs or in response to extraordinary levels of individual contributions to the community. 
  • The RTBKit Council sets the direction and reserves the right to veto.
  • Councilors may be independent, or named on behalf of their employers.
  • For example, strategic Datacratic 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:

Councilor

  • contributes to the official 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.
  • seizes power and can resign, or can be ousted by a simple majority of the council upon which he/she returns to the Councilor role.

 

Processes

Voting

  • The processes are based on the Apache Foundation guidelines.
  • The RTBKit councilors will vote on the mailing list whenever a call to vote is issued.
  • If there are at least three positive votes, no negative votes, and after three business days for a Commiter's pull request or seven days for everyone else, the results are posted to the RTBKit mailing list .
  • 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.'
 

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.

Any community member can

  • send a proposal for consideration to the RTBKit mailing list
  • submit a pull request implementing the idea to Github.

This will prompt a review and, if necessary, a discussion of the idea.

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

Contributions

RTBKit distinguishes between two types of contributions:

  1. Bug fixes and code contributions that fit within the existing design
  2. Major new features 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 requiring 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.

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

https://github.com/rtbkit/rtbkit/issues

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

https://github.com/rtbkit/rtbkit/issues

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:  https://help.github.com/articles/using-pull-requests

 
 

The Committer's Guidelines

  • The Committer promotes and enforces the RTBKit goals.
  • Commiters can submit a pull request for their own changes at which point discussion may happen on the mailing list. After discussions, a vote is requested and Lazy Consensus operates. If after 3 business days there are at least three positive votes, no negative votes and no veto, the Committer can push to Master.
  • Contributors and Users can submit Pull Requests. After discussions, a vote is requested and Lazy Consensus operates. If after 7 business days there are at least three positive votes, no negative votes and no veto, any Committer can push to Master. A Commiter will volunteer to sponsor the Pull and follow it through, including committing to Master if approved.