Governance Structure

1. Preamble

OpenSRP (or the Open Smart Register Platform) is a meritocratic, consensus-based, open source, community project.

OpenSRP grew from the desire of a couple of passionate design and software engineering students to simplify and digitize how data collection could successfully be conducted from the field. Since 2014, OpenSRP has been the key focus of the THRIVE (Technologies for Health Registers, Information, and Vital Events) Study. THRIVE was a multi-country research study that focused on the adaptation, scaled deployment and impact assessment of the OpenSRP platform and associated technology innovations in 3 countries: India, Pakistan and Bangladesh.

OpenSRP is now being implemented beyond research purposes and rolled out at a much larger scale across multiple countries. The tool is currently deployed and is live in eleven countries with different implementing partners and stakeholders. Programs in another nine countries are in progress or planned for rollout from the end of 2019. The longest-running deployments to date are in Pakistan, Bangladesh, Indonesia and Zambia, where the tool enjoys great buy-in from Ministries of Health and local implementing partners.

2. Background

This type of governance model was selected for OpenSRP, based on the analysis of various different models. Variables we considered in terms of choosing the best model for OpenSRP included:

How big do we want the network of contributors to be?
- At present (Dec 2020) , we do have a fairly small team of contributors, but we want to expand this – but in a controlled fashion – and ultimately make it as big as possible and so therefore we considered the “Bazaar” and the “Meritocratic” approaches as the best fit
How many committees or layers do we want to have in the structure?
- Our original thinking was that we need 3 committee, but to keep this as simple as possible, whilst allowing for an expansion in terms of contribution and collaboration, we have opted to institute 2 committees: a PMC (Project management committee) or Governance Committee and a PTC (Project technical committee, or the Product / Tech Committee)
How regularly do we want to release code?
- We want to keep this fairly ‘controlled’ as we most of the collaborators have to balance core product / platform development with non-core work that may be more client facing. We therefore want to determine at what pace code is reviewed and released and are opting for a not-so-aggressive approach in terms of code releases

3. Roles And Responsibilities

3.1 Users

Users are community members who have a need for the project. They are the most important members of the community and without them the project would have no purpose. Anyone can be a user; there are no special requirements, however users typically include:

Technical / software development companies
Ministries of Health
Donors that fund global health programs
Research companies wanting to use the tool to carry out research
Health companies that provide services or resources in terms of health care service delivery
Implementers of health tech solutions

OpenSRP asks its users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users.

Common user contributions include (but are not limited to):

evangelising about the project (e.g. a link on a website and word-of-mouth awareness raising)
informing developers of strengths and weaknesses from a new user perspective
providing moral support (guidance, appreciation, direction setting)
providing financial support (the software is open source, but its developers need to eat)

Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors, as described in the next section.

3.2 Contributors

Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms.

There is no expectation of commitment to the project, no specific skill requirements and no selection process.

In addition to their actions as users, contributors may also find themselves doing one or more of the following:

supporting new users (existing users are often the best people to support new users)
reporting bugs
identifying requirements
providing graphics and web design
Software programming
assisting with project infrastructure
writing documentation
answering questions
fixing bugs
adding features

Contributors engage with the project through:

Weekly technical meetings
an issue tracker
Developer mailing list (The developer mailing list is the most appropriate place to ask for help when making that first contribution)
writing or editing documentation for the project wiki.
Submitting changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section).

As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership.

3.3 Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.

This does not mean that a committer is free to do what they want. In fact, committers have no more authority over the project than contributors. While committership indicates a valued member of the community who has demonstrated a healthy respect for the project’s aims and objectives, their work continues to be reviewed by the community before acceptance in an official release. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before.

It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC (see next section) in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.

A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the PMC. This role is described below.

3.3.1 How can you become a committer?

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time.

3.3.2 Seeking Approval after Making a Contribution

This process is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole. By the time a contributor is invited to become a committer, they will have become familiar with the project’s various tools as a user and then as a contributor.

3.3.3 Committer Nominations

New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the project management committee (PMC; see below). Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.

3.3.5 Committer Voting

Committer voting is one of the few activities that takes place on the project’s private management list. This is to allow PMC members to freely express their opinions about a nominee without causing embarrassment. Once the vote has been held, the aggregated voting results are published on the public mailing list. The nominee is entitled to request an explanation of any ‘no’ votes against them, regardless of the outcome of the vote. This explanation will be provided by the PMC Chair (see below) and will be anonymous and constructive in nature.

4. Contribution Process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For instance, a contributor might be active on the project mailing list and issue tracker, or might supply patches. The developer mailing list is the most appropriate place for a contributor to ask for help when making their first contribution.

5. Contribution Types

The various ways of contributing are described in the tables above, although the types of contribution are not limited to these examples. More contribution types may come to the fore, as the needs of the community and the project expands and grows. The current types of contribution include:

Strategy and Direction-setting
Evangelising and Marketing
Software Design And Implementation
User experience
User support
Quality Assurance
Graphics And Art
Documentation
Language communities
Monetary donations.

6. Chair

The Project management committee (PMC) Chair is a single individual, co-founder and CEO of Ona – Matt Berg. Once someone has been appointed Chair, they remain in this role until he chooses to retire, or the PMC casts a two-thirds majority vote to remove him.

The PMC Chair has no additional authority over other members of the PMC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.

7. Committees

OpenSRP has 2 committees that resort under this Governance Structure:

The Project management committee (PMC) as well as the
Project technical committee (PTC)

7.1. The Project Management Committee (PMC)

The project management consists of those individuals identified as joint ‘project owners’. The PMC has additional responsibilities over and above those of a committer. These responsibilities ensure the overall smooth running of the project.

7.1.1 Mandate of the PMC

PMC members are expected to:

participate in strategic planning and direction setting of the project,
approve changes to the governance model
manage the copyrights within the project outputs
Vote on acceptance of new committers to join the community
Make final decisions if no community consensus is reached
Manage the project’s private mailing lists and it’s archives (holding possibly sensitive information such as votes for new committers, legal matters, etc)
Attend an annual strategic planning meeting (ideally face-to-face)
Attend quarterly update / progress meetings (virtually)

7.1.2 Membership of the PMC

Membership is by invitation from one of the existing PMC members. A written nomination must be addressed to the Chair, and will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.

7.1.3 Tenure of the PMC

PMC members have a tenure of one year and are committing to serve in this capacity for one calendar year post the constituting of the committee. Once that one year lapses, existing members can either:

Opt to extend their tenure by another year,
Nominate a new member to join the PMC, or
Tender their resignation from the committee

7.1.4 To Nominate a Member of the PMC

Please send your nomination, containing the following information:

Name and surname of the nominee
Title of the nominee
Organisation/ Affiliation of the nominee
A short 1-2 paragraph motivation – i.e. why do you think they should be a member of the PMC

Please send your nomination to pmc@smartregister.org, by 31 January 2021

7.2. The Product Technical Committee (PTC)

The Product and Tech committee (PTC) consists of those individuals identified as joint ‘technical owners’. The PTC has additional responsibilities over and above those of a committer. These responsibilities ensure the overall technical quality and abilities of the open source product.

7.2.1 Mandate of the PTC

PTC members are expected to:

Draft and publish a tech charter for OpenSRP
Oversee the overall Technical development of new features and functionality, per the defined and published road map
Productization / packaging of OpenSRP from a technical perspective
Formalise a process for feature development, prioritisation and releases
Review all code committed
Web-based form updates and data model sync to allow for configuring of forms, form versioning, and pushing updates to OpenSRP Android Clients
Improved support for data clean-up and client merging
QA and Testing
Release planning
Releases
Document and extend existing REST API to cover core functionality, by
- Standardizing documentation and extending the REST API to support RESTful verbs and by
- Integrating the documentation with a tool that supports automated online documentation
Correspondence / Documentation with technical contributors via the WikiReview Code Submissions
Collaborate with the broader community to define and publish a quarterly technical roadmap
Report on progress of the roadmap items, to the rest of the committee members, quarterly
Attend annual technical strategy meeting (preferably face-to-face)
Attend quarterly technical meetings (virtually)

7.2.2 Membership of the PTC

Membership is by invitation from one of the existing PTC members. A written nomination must be addressed to the Chair, and will result in discussion and then a vote by the existing PTC members. PTC membership votes are subject to consensus approval of the current PTC members.

7.2.3 Tenure of the PTC

PTC members have a tenure of one year and are committing to serve in this capacity for one calendar year post the constituting of the committee. Once that one year lapses, existing members can either:

Opt to extend their tenure by another year,
Nominate a new member to join the PTC, or
Tender their resignation from the committee

7.2.4 To Nominate a Member of the PTC

Please send your nomination, containing the following information:

Name and surname of the nominee
Title of the nominee
Organisation/ Affiliation of the nominee
A short 1-2 paragraph motivation – i.e. why do you think they should be a member of the PTC

8. Decision Making Process

Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PMC and PTC members. All non-sensitive project management discussion takes place on the project contributors’ mailing list. Occasionally, sensitive discussion occurs on a private list.

In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

8.1 Lazy consensus

Decision making typically involves the following steps:

Proposal or Idea
Discussion
Vote (if consensus is not reached through the discussion process)
Decision

Any community member, PMC or PTC member, can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the project contributors’ list or submit a patch implementing the idea to the issue tracker (or version-control system if they have commit access). This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.

In general, as long as nobody explicitly opposes a proposal or patch, it is recognised as having the support of the community. This is called lazy consensus – that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.

Lazy consensus is a very important concept within this Open Source project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.

For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

8.2 Voting

Not all decisions can be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community (including the members of the PMC and PTC described above) is encouraged to express their opinions in all discussion and all votes. However, only project committers and/or PMC members (as defined above) have binding votes for the purposes of decision making.

8.2.1 Voting Process

If a formal vote on a proposal is called (signaled simply by sending an email to the whole mailing list, with ‘[VOTE]’ in the subject line), all participants on the project contributors’ list may express an opinion and vote. They do this by sending an email in reply to the original ‘[VOTE]’ email, with the following vote and information:

+1 ‘yes’, ‘agree’: also willing to help bring about the proposed action
+0 ‘yes’, ‘agree’: not willing or able to help bring about the proposed action
-0 ‘no’, ‘disagree’: but will not oppose the action’s going forward
-1 ‘no’, ‘disagree’: opposes the action’s going forward and must propose an alternative action to address the issue (or a justification for not addressing the issue)

To abstain from the vote, participants simply do not respond to the email. However, it can be more helpful to cast a ‘+0’ or ‘-0’ than to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial.

Every member of the community, from interested user to the most active developer, has a vote. The project encourages all members to express their opinions in all discussion and all votes.

However, only some members have binding votes for the purposes of decision making: in this case – the members of the Project Management Committee (PMC) have such binding votes.

8.2.2 Responsibilities of the PMC in terms of the Voting Process

The primary responsibility of the PMC is to ensure that the opinions of all community members are considered.

The votes from the PMC is binding

A PMC member can also indicate a veto.

When a [VOTE] receives a ‘-1’, it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding veto) or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the PMC will decide the forward course of action.

In summary:

Those who don’t agree with the proposal and think they have a better idea should vote -1 and defend their counter-proposal.
Those who don’t agree but don’t have a better idea should vote -0.
Those who agree but will not actively assist in implementing the proposal should vote +0.
Those who agree and will actively assist in implementing the proposal should vote +1.

8.2.3 Types Of Approval

Different actions require different types of approval, ranging from lazy consensus to a majority decision by the PMC. These are summarised in the table below. The section after the table describes which type of approval should be used in common situations.

Type	Description	Duration
Lazy consensus	An action with lazy consensus is implicitly allowed, unless a binding -1 vote is received. Depending on the type of action, a vote will then be called. Note that even though a binding -1 is required to prevent the action, all community members are encouraged to cast a -1 vote with supporting argument. Committers are expected to evaluate the argument and, if necessary, support it with a binding -1.	N/A
Lazy majority	A lazy majority vote requires more binding +1 votes than binding -1 votes.	72 hours
Consensus approval	Consensus approval requires three binding +1 votes and no binding -1 votes.	72 hours
Unanimous consensus	All of the binding votes that are cast are to be +1 and there can be no binding vetoes (-1).	120 hours
2/3 majority	Some strategic actions require a 2/3 majority of PMC members; in addition, 2/3 of the binding votes cast must be +1. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product).	120 hours

8.2.4 When Is A Vote Required?

Every effort is made to allow the majority of decisions to be taken through lazy consensus. That is, simply stating one’s intentions is assumed to be enough to proceed, unless an objection is raised. However, some activities require a more formal approval process in order to ensure fully transparent decision making.

The table below describes some of the actions that will require a vote. It also identifies which type of vote should be called.

Action	Description	Approval type
Release plan	Defines the timetable and actions for a release. A release plan cannot be vetoed (hence lazy majority).	Lazy majority
Product release	When a release of one of the project’s products is ready, a vote is required to accept the release as an official release of the project. A release cannot be vetoed (hence lazy majority).	Lazy majority
New committer	A new committer has been proposed.	Consensus approval of the PMC
New PMC member	A new PMC member has been proposed.	Consensus approval of the community
Committer removal	When removal of commit privileges is sought.	Unanimous consensus of the PMC
PMC member removal	When removal of PMC membership is sought.	Unanimous consensus of the community

9. Support

9.1 Providing Support

All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community.

9.2 Seeking Support

Those seeking support should recognise that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.

10. Timeline

Step	Description	Timeframe
1	Internal research, meetings and drafting of this OpenSRP Governance Structure memorandum	July 2019 – Dec 2020
2	Finalization of the Governance structure memo	9 Dec 2020
3	Publishing of the Governance Structure memo on the OpenSRP website, the OpenSRP wiki page, and announcing this to the OpenSRP Tech Forum during their weekly Wednesday meetings	By 31 Dec 2020
4	Nominations of committee members to the PMC and PTC	By 31 January 2021
5	Email feedback given on this Governance memorandum, by emailing to info@smartregister.org	By 31 January 2021
6	Publication and announcement of the nominations for each committee, on the OpenSRP website, the OpenSRP wiki page, and announcing this to the OpenSRP Tech Forum during their weekly Wednesday meetings	By Friday 5 Feb 2021
7	Voting by the OpenSRP Community, for the 2 committee members. Voting process will follow the Lazy Consensus process described in this document – above.	Between Monday 8 and Friday 19 Feb 2021
8	Voting concluded	Friday 19 Feb 2021, 6pm EAT
9	Committee members informed by Ona, of their nominations, any possible objections that we received (if any), and confirmation from them that they accept the nominations / votes and agree that they will serve on the respective committees for a period of 1 year.	Monday 22 Feb – Friday 5 March 2021
10	Confirmed committee members announced to the OpenSRP Community, on the OpenSRP website, the OpenSRP wiki page, and announcing this to the OpenSRP Tech Forum during their weekly Wednesday meetings	By Friday 19 Feb 2021
11	Virtual event, formally launching the OpenSRP Governance Structure and it’s committees	By Friday 5 March 2021 – exact date to be confirmed.

11. Conclusion

A clear and transparent governance document is a key part of any open development project. This model is for a meritocratic, consensus-based project. It defines the rules of engagement within the community and describes what level of influence a community member can expect to have over a project. In addition, it enables members to decide their level of involvement with that community. In the case of a meritocracy, it also provides a clear way to contribute and a highly visible reward system.