Project Governance

Open Source Governance Process at MOSIP

1. Overview

Open source projects can have a variety of contributors. This can potentially lead to confusion or conflict. This document sets forth a simple transparent set of guidelines to describe the roles and process to be followed. As part of that it covers:

• Process of open source contributions and review of code in this project.

• Decision-making process on backlogs and including contributions.

2. Governance Structure

The MOSIP project follows a simple structure with 3 levels.

Level 1 - MOSIP Technology Committee. This committee is responsible for high level roadmap and policy decisions such as licensing, and technology stack.

Level 2 - Project leadership. This is the executive leadership at MOSIP that includes key project roles within MOSIP such as product owner, engineering lead, and architects. These members will be appointed as maintainers and lead in the project by MOSIP.

Level 3 - Members. This is a set of people who are working on the project.

Given below is a list of specific roles and their responsibilities.

Roles and Responsibilities

• Maintainers are individuals who have “Commit” rights; And are the primary caretakers of the code and the strategic vision of the project. They are empowered to make decisions and resolve disputes for all contributions. They are appointed by MOSIP.

• Project Lead is the chair of the committee of maintainers. They are appointed by MOSIP.

• Contributors are the people or organisations who take part actively in the project and its meetings, code, design, and test and are recognized for their contributions. The contributors are part of the GitHub Members and would be actively involved in the discussion of a PR and review. Members strongly influence the Maintainer's decision.

• Members are either individuals or persons affiliated with contributing organisations. All contributions are bound by the licensing of the project.

• Product Owner is responsible for the analysis, design, development, and implementation of business solutions to meet the needs of the organisation. He/She must have a strong understanding of the business domain, processes, and software development lifecycle Agile development methodologies).

3. Contributions

Scope of Contributions

The whole of the project is open to contributions. The kind of contributions that are welcome include:

• Code

• Documentation

• Design

• Raising Bugs

• Feature Request

Process to Contribute

• Code, Documentation & Design

  • All artefacts including the code are maintained in the github repository.Contributions can be made by raising a Pull Request.

• Reporting Issues & Feature Request

  • Issues and backlog are maintained in Jira and members of the project team will have access to Jira to add feature requests and report bugs

  • One off users will not have access for bug reports and feature requests. They can report the same in the community pages

  • Regular users who do not have access, can request the same and the maintainers can provide access after considerationWe use Jira to track the work associated with the project (account required). That is where issues open for community contribution can be found.Pull Request Review ProcessThe process to contribute the code is present here. Once code is submitted, it is reviewed through the following process:

We use Jira to track the work associated with the project (account required). That is where issues open for community contribution can be found.

Pull Request Review Process

The process to contribute the code is present here. Once code is submitted, it is reviewed through the following process:

• At least two members should have reviewed the submitted contribution for the pull request to be accepted. The maintainers may request for more reviews of the code from other relevant members.

• If the members deem the submitted code to be critical to overall product development, they can seek the inputs of the relevant product owners for the review process.

• The maintainers review the two (or more) sets of comments received from the tech leads and the submitted code before taking a decision regarding committing the code to the appropriate branch.

• The decision by the maintainer is communicated to the contributor via Jira as well as Pull Request.

• In exceptional cases such as an emergency or an urgent requirement or a very trivial but time-sensitive correction, a maintainer may - at their discretion - choose to directly review the submitted pull request and take a decision on the commit.

Release process

Project Lead initiates the release process. The process can be found here.

Attribution

Attribution is in accordance with the relevant licence. Individual and affiliated contributors will be listed.

4. Decision-Making

The key decisions to be taken are for the following activities

• Roadmap and backlog priority

• Triaging of bugs and requirements

• Accepting a contribution Pull Request)

• Releases

Most decisions will be made in periodical meetings where owners of the relevant aspect of work present a case for a decision and the decision will be made either by consensus, or by majority where a quorum exists. The maintainers of the project will be the decision makers. The project lead will have veto power on decisions due to their expertise and commitment to the vision of the project. Contributors can share their views in these meetings for consideration.