Chandler CarruthandRichard Smith
94d2c1c6d4
We've talked about adding the title to the filename several times over the years and it seems really valuable. This requires us to compute a "slug" for the title spelling that can be part of the filename. Beyond that, we crossed 7000 recently, and so it seems likely that we will need to add digits sooner rather than later here, so this goes ahead and moves us to 6 digits so we don't have to adjust again for a reasonable length of time. To implement this and ensure we can sustain it going forward this adds a tool to our pre-commit that validates (and corrects if needed) the filename. In order to update everything and keep links working, there are a _lot_ of changes, but the most interesting for direct review are in `proposals/scripts`. Assisted-by: Antigravity with Gemini --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>
4.9 KiB
Getting commit access
Table of contents
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-languageorganization, only thecarbon-langrepository 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:
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.