Skip to content

Latest commit

 

History

History
126 lines (97 loc) · 5.19 KB

Contributing.md

File metadata and controls

126 lines (97 loc) · 5.19 KB

Planetary Software Organization Community Contributing Guide

This document describes a very simple process suitable for activities in the Planetary Software Organization ecosystem, including the TSC itself.

The goal of this document is to create a contribution process that:

  • Encourages new contributions.
  • Encourages contributors to remain involved.
  • Avoids unnecessary processes and bureaucracy whenever possible.
  • Creates a transparent decision making process which makes it clear how contributors can be involved in decision making.

Vocabulary

  • A Contributor is any individual creating or commenting on an issue or pull request.
  • A Committer is a subset of contributors who have been given write access to the repository.
  • A Technical Committee (TC) is a group of committers representing the required technical expertise to resolve rare disputes. For the purpose of this repository, the Planetary Software Technical Steering Committee is the TC.

Logging Issues

Log an issue for any question or problem you might have. When in doubt, log an issue, any additional policies about what to include will be provided in the responses. The only exception is a security disclosure which should be sent privately to the contact address listed in the Code of Conduct.

Committers may direct you to another repository, ask for additional clarifications, and add appropriate metadata before the issue is addressed.

Please be courteous and respectful. Every participant is expected to follow the relevant Code of Conduct (e.g. The Planetary Science TSC's Code of Conduct).

Contributions

Any change to resources in this repository must be through pull requests (PRs). This applies to all changes to documentation, code, binary files, etc. Even long term committers and TC members must use pull requests.

In general, the submitter of a PR is responsible for making changes to the PR. Any changes to the PR can be suggested by others in the PR thread (or via PRs to the PR), but changes to the primary PR should be made by the PR author. In order to merge a PR, it must satisfy both of these two conditions:

  1. have been open for 24 hours
  2. have two approvals

Pull requests should sit for at least 24 hours to ensure that contributors in other timezones have time to review. Consideration should also be given to weekends and other holiday periods to ensure active committers all have reasonable time to become involved in the discussion and review process if they wish.

In order to encourage involvement and review, we require at least two explicit approvals from committers that are not the PR author.

The default for each contribution is that it is accepted once no committer has an objection, and the above two requirements are satisfied. During review committers may also request that a specific contributor who is more versed in a particular area gives an approval before the PR can be merged. There is no additional "sign off" process for contributions to be merged. Once all issues brought by committers are addressed it can be merged by any committer.

In the case of an objection being raised in a pull request by another committer, all involved committers should seek to arrive at a consensus by way of addressing concerns being expressed by discussion, compromise on the proposed change, or withdrawal of the proposed change.

If a contribution is controversial and committers cannot agree about how to get it merged or if it should merge, then it should be escalated to the TC. TC members should regularly discuss pending contributions in order to find a resolution. It is expected that only a small minority of issues be brought to the TC for resolution and that discussion and compromise among committers be the default resolution mechanism.

Exceptions to the above are minor typo fixes or cosmetic changes that don't alter the meaning of a document. Those edits can be made via a PR which only requires a single approval (not two, and not open for 24 h) to be merged.

Some kinds of PRs have different rules (those to change the TSC Charter, applications for TLPs and TLWGs, etc.) and will be detailed in their respective policy documents.

Becoming a Committer

All contributors who get a non-trivial contribution merged should be on-boarded in a timely manner, added as a committer, and be given write access to the repository.

Committers are expected to follow this policy and continue to send pull requests, go through proper review, and have other committers merge their pull requests.

TC Process

The TC uses a "consensus seeking" process for issues that are escalated to the TC. The group tries to find a resolution that has no open objections among TC members. If a consensus cannot be reached that has no objections then a majority wins vote is called. It is also expected that the majority of decisions made by the TC are via a consensus seeking process and that voting is only used as a last resort.

Resolution may involve returning the issue to committers with suggestions on how to move forward towards a consensus. It is not expected that a meeting of the TC will resolve all issues on its agenda during that meeting and may prefer to continue the discussion happening among the committers.