Getting commit access

<!-- Part of the Carbon Language project, under the Apache License v2.0 with LLVM Exceptions. See /LICENSE for license information. SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception -->

Pull request

<!-- toc -->

Table of contents

• Abstract
• Problem
• Background
  • Commit access
  • Related policies
• Proposal
• Rationale
• Alternatives considered
  • Longer idle times

<!-- tocstop -->

Abstract

Establish a process for getting commit access. We will:

• Grant access based on a developer's commit history.
  • Someone with commit access should nominate, and a contributor may ask.
  • A lead will approve nominations. Only one lead is needed.
• Remove commit access once someone is idle for 6 months.
  • "Idle" means no significant project activity on any of GitHub, Discord, or in meetings.
  • Access removed due to being idle will be restored on request.

Problem

Right now, we have an undocumented process for getting commit access, and no real agreement for when to remove it. Commit access is important, so rather than just making a documentation edit, I'm submitting this as a proposal.

Background

Commit access

When we say "commit access", what we mean is the ability to push commits to the main carbon-lang repository, regardless of branch. Some details about the implications:

• Review and approvals would remain required for pushes to trunk.
  • This does grant access to push to other branches, although we will continue to encourage fork-based workflows.
• Pushing PRs becomes easier with commit access.
  • Action workflows will automatically execute, instead of requiring a per-commit approval by someone with commit access.
  • Modifying PRs after review approval is possible.
    • This is both good (for small updates such as fixing typos and resolving conflicts) and bad (particularly for code security).
  • Communication delays can make it hard for an author to resolve conflicts and reviewer to approve and merge before more conflicts are introduced.
    • A possible solution to the conflict problem is to have the reviewer merge PRs more frequently, and regardless of any decision here, we may eventually need to adopt that approach.
• Commit access functionally means the ability to approve and merge PRs from others.
  • As alternatives, we could use either a separate GitHub team for approvals or CODEOWNERS. We have avoided these so far because we're small, having backup approvers can be helpful, and mistakes are easy to undo.
• This does not include the ability to push to other repositories. While there are a few in the carbon-language organization, only the carbon-lang repository is actively used.
• People with commit access in effect have access to secrets, can make releases, and so on.

Related policies

This proposal does not supersede other project policies, in particular:

• CLA
• Code of Conduct
• Review process

Proposal

The key things I think should be covered in this proposal are:

• Whether we want to require a lead to approve commit access additions.
• We're choosing to do a 6 month inactive period for removal.

Things I think we should be okay iterating on without going through evolution include:

• Exactly how we define non-idle activity beyond merging and approving PRs, both of which mechanically require this access.
• The detailed process for additions, including nominating.
  • We want a good starting point, but it may not be worth sending all changes through the proposal process.
• The detailed process for removals, such as whether leads are approving removals.
  • This is something it's been suggested to fully automate, preventing review of removals.

See the new Commit access document for details.

Rationale

• Community and culture
  • Establishing the processes around commit access, and making sure they're reasonable, is important to maintaining the community.

Alternatives considered

Longer idle times

We discussed using a longer idle time, like 1, 2, or 3 years. We're leaning towards the shorter 6 month period because of concerns about forgotten access causing issues. We're hoping 6 months is a minimum of inconvenience, and want it to be easy to get access back on request.