Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
70 lines (43 sloc) 3.75 KB

Approved by Open Mainframe Project TSC on 2018-09-05

NOTE: This document is intended to provide an example governance structure for any Open Mainframe Project project to consider as a starting point. All projects hosted by Open Mainframe Project are not bound by these governance polices, but in absence of any prior governance structure should consider this as a recommended structure

Overview

This project aims to be governed in a transparent, accessible way for the benefit of the community. All participation in this project is open and not bound to corporate affilation. Participants are bound to the project's Code of Conduct.

Project roles

Contributor

The contributor role is the starting role for anyone participating in the project and wishing to contribute code.

Process for becoming a contributor

  • Review the CONTRIBUTING.md guidelines to ensure your contribution is inline with the project's coding and styling guidelines.
  • Submit your code as a PR with the appropriate DCO signoff
  • Have your submission approved by the maintainer(s) and merged into the codebase.

Maintainer

The maintainer role enables the contributor to commit code directly to the repository, but also comes with the responsibility of being a responsible leader in the community.

Process for becoming a maintainer

  • Show your experience with the codebase through contributions and engagement on the community channels.
  • Request to become a maintainer.
  • Have the majority of maintainers approve you becoming a maintainer.
  • Your name and email is added to the MAINTAINERS.md file for the project.

Maintainer responsibilities

  • Monitor email aliases (if any).
  • Monitor Slack (delayed response is perfectly acceptable).
  • Triage GitHub issues and perform pull request reviews for other maintainers and the community.
  • Make sure that ongoing PRs are moving forward at the right pace or closing them.
  • In general continue to be willing to spend at least 25% of ones time working on the project (~1.25 business days per week).

When does a maintainer lose maintainer status

If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of the maintainers per the voting process below.

Lead

The project maintainers will elect a lead ( and optionally a co-lead ) which will be the primary point of contact for the project and representative to the TSC. The lead(s) will be responsible for the overall project health and direction, coordination of activities, and working with other projects and committees as needed for the continuted growth of the project.

Release Process

Project releases will occur on a scheduled basis as agreed to by the maintainers.

Conflict resolution and voting

In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the maintainers can be called in to decide an issue. If the maintainers themselves cannot decide an issue, the issue will be resolved by voting. The voting process is a simple majority in which each maintainer receives one vote.

Communication

This project, just like all of open source, is a global community. In addition to the Code of Conduct, this project will:

  • Keep all communucation on open channels ( mailing list, forums, chat ).
  • Be respectful of time and language differences between community members ( such as scheduling meetings, email/issue responsiveness, etc ).
  • Ensure tools are able to be used by community members regardless of their region.

If you have concerns about communication challenges for this project, please contact the maintainers.