From 53d0792930cee3f1625264927464ba00e3e6faa8 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 09:56:24 -0700 Subject: [PATCH 01/16] Filling out template with PR 4246 --- docs/project/commit_access.md | 64 +++++++++++++++++++++++++++ proposals/p4246.md | 82 +++++++++++++++++++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 docs/project/commit_access.md create mode 100644 proposals/p4246.md diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md new file mode 100644 index 0000000000000..020c46a6b4727 --- /dev/null +++ b/docs/project/commit_access.md @@ -0,0 +1,64 @@ +# Commit access + + + + + +## Table of contents + +- [Overview](#overview) +- [Getting access](#getting-access) +- [Removing access](#removing-access) + + + +## Overview + +Commit access is what allows developers to merge PRs into the main +[carbon-lang repository](https://github.com/carbon-language/carbon-lang/). It +also gives the ability to [review, approve, and merge changes](code_review.md). + +Developers with commit access are not required to do reviews. It is granted as a +convenience in order to allow fixing PRs after approval, for example because the +review noted a minor typo, or because there is a conflict that the PR author +needs to resolve before merging. + +Developers with commit access are expected to make reasonable choices about when +to review and approve PRs for others, and what changes to make to their own PRs +without asking for another round of review. + +## Getting access + +Contributors can request commit access based on their commit history. We want to +make sure that developers with commit access are reasonably familiar with the +style and structure of the codebase. Access will typically be granted when +developers have contributed several PRs and are expecting to continue making +more. + +Typically someone who has been doing reviews for a contributor will nominate, +and contributors are encouraged to ask a reviewer to nominate if needed. +Nominations will be reviewed by at least one lead, and a lead's approval will +lead to access. + +When approved, an invitation will be sent to join the +[Commit access team](https://github.com/orgs/carbon-language/teams/commit-access) +on GitHub. The invitation should cause a notification from GitHub, but it's also +possible to go to the +[invitation link](https://github.com/orgs/carbon-language/invitation) directly. +Access is granted when the invitation is accepted. + +## Removing access + +We'll periodically remove commit access from contributors who have been idle for +over 6 months. We'll use a combination of sources to determine what "idle" +means, including whether a developer has been either sending or reviewing PRs. + +For example, for `jonmeow`, GitHub searches (defaulting to PRs for convenience, +but other types are included): + +- [repository:carbon-language/carbon-lang author:jonmeow](https://github.com/search?q=repository%3Acarbon-language%2Fcarbon-lang+author%3Ajonmeow&type=pullrequests) +- [repository:carbon-language/carbon-lang commenter:jonmeow](https://github.com/search?q=repository%3Acarbon-language%2Fcarbon-lang+commenter%3Ajonmeow&type=pullrequests) diff --git a/proposals/p4246.md b/proposals/p4246.md new file mode 100644 index 0000000000000..7f3a2155f1b0b --- /dev/null +++ b/proposals/p4246.md @@ -0,0 +1,82 @@ +# Getting commit access + + + +[Pull request](https://github.com/carbon-language/carbon-lang/pull/4246) + + + +## Table of contents + +- [Abstract](#abstract) +- [Problem](#problem) +- [Background](#background) +- [Proposal](#proposal) +- [Rationale](#rationale) + + + +## 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 + +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](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners). + 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. + +## Proposal + +See the new [Commit access](/docs/project/commit_access.md) document. + +## Rationale + +- [Community and culture](/docs/project/goals.md#community-and-culture) + - Establishing the processes around commit access, and making sure they're + reasonable, is important to maintaining the community. From eff06e42b8f956cd768a69ed992c7b53da85a4d9 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 13:32:26 -0700 Subject: [PATCH 02/16] Add detail about what's really specifically being evolved. --- proposals/p4246.md | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/proposals/p4246.md b/proposals/p4246.md index 7f3a2155f1b0b..13d4ce095c395 100644 --- a/proposals/p4246.md +++ b/proposals/p4246.md @@ -17,6 +17,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Background](#background) - [Proposal](#proposal) - [Rationale](#rationale) +- [Alternatives considered](#alternatives-considered) + - [Longer idle times](#longer-idle-times) @@ -73,10 +75,38 @@ implications: ## Proposal -See the new [Commit access](/docs/project/commit_access.md) document. +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 expiry. + +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](/docs/project/commit_access.md) document for +details. ## Rationale - [Community and culture](/docs/project/goals.md#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. From a4e15d6400a742cccd947fdbb85e39ad83ec76a5 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 13:32:58 -0700 Subject: [PATCH 03/16] not expiry --- proposals/p4246.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/p4246.md b/proposals/p4246.md index 13d4ce095c395..3e9a2cf21afc0 100644 --- a/proposals/p4246.md +++ b/proposals/p4246.md @@ -78,7 +78,7 @@ implications: 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 expiry. +- 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: From d3987864a769a7ee534e8b18d04ee2af98ba0cea Mon Sep 17 00:00:00 2001 From: Jon Ross-Perkins Date: Fri, 23 Aug 2024 13:42:25 -0700 Subject: [PATCH 04/16] Update docs/project/commit_access.md Co-authored-by: Chandler Carruth --- docs/project/commit_access.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 020c46a6b4727..1065784e0e05a 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -18,9 +18,11 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception ## Overview -Commit access is what allows developers to merge PRs into the main -[carbon-lang repository](https://github.com/carbon-language/carbon-lang/). It -also gives the ability to [review, approve, and merge changes](code_review.md). +First and foremost, commit access is **not required** for contributing to Carbon! Anyone can send a pull request with a change to Carbon. Very few parts of our process require commit access, and most development activity is exactly the same for folks with or without. This is an important feature of our GitHub workflow for us, and one we plan to keep. + +The main thing commit access allows is for developers to merge PRs into the main +[carbon-lang repository](https://github.com/carbon-language/carbon-lang/). They still need review, and often a reviewer with commit access handles the merge. It +also gives the ability to [approve and merge changes](code_review.md). Developers with commit access are not required to do reviews. It is granted as a convenience in order to allow fixing PRs after approval, for example because the From 1bea2b27aa0913966565f9199e478cb33e17ec03 Mon Sep 17 00:00:00 2001 From: Jon Ross-Perkins Date: Fri, 23 Aug 2024 13:42:43 -0700 Subject: [PATCH 05/16] Update docs/project/commit_access.md Co-authored-by: Chandler Carruth --- docs/project/commit_access.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 1065784e0e05a..73ddf3317471b 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -30,8 +30,10 @@ review noted a minor typo, or because there is a conflict that the PR author needs to resolve before merging. Developers with commit access are expected to make reasonable choices about when -to review and approve PRs for others, and what changes to make to their own PRs -without asking for another round of review. +to approve or merge PRs for others -- generally, the change either needs to be trivially understood without context on the code in question (like a cleanup, typo fix, etc), or the developer should have reasonable context on the code in question. If in doubt, feel free to review but leave approving or merging for someone else. + +Similarly, developers with commit access are expected to make reasonable choices about what changes to make to their own PRs +without asking for another round of review prior to merge, even after approval. And again, if in doubt, ask for review. ## Getting access From 1d1b229100e70f035deb35937cbf3c3b949dc163 Mon Sep 17 00:00:00 2001 From: Jon Ross-Perkins Date: Fri, 23 Aug 2024 13:42:51 -0700 Subject: [PATCH 06/16] Update docs/project/commit_access.md Co-authored-by: Chandler Carruth --- docs/project/commit_access.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 73ddf3317471b..6cd14e36e52ec 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -43,10 +43,8 @@ style and structure of the codebase. Access will typically be granted when developers have contributed several PRs and are expecting to continue making more. -Typically someone who has been doing reviews for a contributor will nominate, -and contributors are encouraged to ask a reviewer to nominate if needed. -Nominations will be reviewed by at least one lead, and a lead's approval will -lead to access. +After a few non-trivial PRs are merged, contributors should ask a reviewer to nominate for commit access if they plan to keep contributing. Reviewers can also directly suggest and nominate someone. +Nominations need to be approved by at least one lead. When approved, an invitation will be sent to join the [Commit access team](https://github.com/orgs/carbon-language/teams/commit-access) From 1ac70e7090222281c6e6a1f97c5b6ab67fc8475d Mon Sep 17 00:00:00 2001 From: Jon Ross-Perkins Date: Fri, 23 Aug 2024 13:42:57 -0700 Subject: [PATCH 07/16] Update docs/project/commit_access.md Co-authored-by: Chandler Carruth --- docs/project/commit_access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 6cd14e36e52ec..760b40e9df944 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -57,7 +57,7 @@ Access is granted when the invitation is accepted. We'll periodically remove commit access from contributors who have been idle for over 6 months. We'll use a combination of sources to determine what "idle" -means, including whether a developer has been either sending or reviewing PRs. +means, including whether a developer has been either sending or reviewing PRs. Developers should always ask for it to be restored if they plan to start contributing again or come back from a break. Any relevant past contributions will still apply and allow it to be restored trivially. For example, for `jonmeow`, GitHub searches (defaulting to PRs for convenience, but other types are included): From 7369c74ac4f0e3f0674723188cfddf559191d6fc Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 13:48:37 -0700 Subject: [PATCH 08/16] pre-commit --- docs/project/commit_access.md | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 760b40e9df944..46bfadc822f2b 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -18,10 +18,15 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception ## Overview -First and foremost, commit access is **not required** for contributing to Carbon! Anyone can send a pull request with a change to Carbon. Very few parts of our process require commit access, and most development activity is exactly the same for folks with or without. This is an important feature of our GitHub workflow for us, and one we plan to keep. +First and foremost, commit access is **not required** for contributing to +Carbon! Anyone can send a pull request with a change to Carbon. Very few parts +of our process require commit access, and most development activity is exactly +the same for folks with or without. This is an important feature of our GitHub +workflow for us, and one we plan to keep. The main thing commit access allows is for developers to merge PRs into the main -[carbon-lang repository](https://github.com/carbon-language/carbon-lang/). They still need review, and often a reviewer with commit access handles the merge. It +[carbon-lang repository](https://github.com/carbon-language/carbon-lang/). They +still need review, and often a reviewer with commit access handles the merge. It also gives the ability to [approve and merge changes](code_review.md). Developers with commit access are not required to do reviews. It is granted as a @@ -30,10 +35,16 @@ review noted a minor typo, or because there is a conflict that the PR author needs to resolve before merging. Developers with commit access are expected to make reasonable choices about when -to approve or merge PRs for others -- generally, the change either needs to be trivially understood without context on the code in question (like a cleanup, typo fix, etc), or the developer should have reasonable context on the code in question. If in doubt, feel free to review but leave approving or merging for someone else. +to approve or merge PRs for others -- generally, the change either needs to be +trivially understood without context on the code in question (like a cleanup, +typo fix, etc), or the developer should have reasonable context on the code in +question. If in doubt, feel free to review but leave approving or merging for +someone else. -Similarly, developers with commit access are expected to make reasonable choices about what changes to make to their own PRs -without asking for another round of review prior to merge, even after approval. And again, if in doubt, ask for review. +Similarly, developers with commit access are expected to make reasonable choices +about what changes to make to their own PRs without asking for another round of +review prior to merge, even after approval. And again, if in doubt, ask for +review. ## Getting access @@ -43,8 +54,10 @@ style and structure of the codebase. Access will typically be granted when developers have contributed several PRs and are expecting to continue making more. -After a few non-trivial PRs are merged, contributors should ask a reviewer to nominate for commit access if they plan to keep contributing. Reviewers can also directly suggest and nominate someone. -Nominations need to be approved by at least one lead. +After a few non-trivial PRs are merged, contributors should ask a reviewer to +nominate for commit access if they plan to keep contributing. Reviewers can also +directly suggest and nominate someone. Nominations need to be approved by at +least one lead. When approved, an invitation will be sent to join the [Commit access team](https://github.com/orgs/carbon-language/teams/commit-access) @@ -57,7 +70,10 @@ Access is granted when the invitation is accepted. We'll periodically remove commit access from contributors who have been idle for over 6 months. We'll use a combination of sources to determine what "idle" -means, including whether a developer has been either sending or reviewing PRs. Developers should always ask for it to be restored if they plan to start contributing again or come back from a break. Any relevant past contributions will still apply and allow it to be restored trivially. +means, including whether a developer has been either sending or reviewing PRs. +Developers should always ask for it to be restored if they plan to start +contributing again or come back from a break. Any relevant past contributions +will still apply and allow it to be restored trivially. For example, for `jonmeow`, GitHub searches (defaulting to PRs for convenience, but other types are included): From e072f68cd90bfbfa23cb61b38a179919d4eecdbe Mon Sep 17 00:00:00 2001 From: Jon Ross-Perkins Date: Fri, 23 Aug 2024 14:27:40 -0700 Subject: [PATCH 09/16] Update docs/project/commit_access.md Co-authored-by: Chandler Carruth --- docs/project/commit_access.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 46bfadc822f2b..d0874b1d5c18e 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -29,10 +29,8 @@ The main thing commit access allows is for developers to merge PRs into the main still need review, and often a reviewer with commit access handles the merge. It also gives the ability to [approve and merge changes](code_review.md). -Developers with commit access are not required to do reviews. It is granted as a -convenience in order to allow fixing PRs after approval, for example because the -review noted a minor typo, or because there is a conflict that the PR author -needs to resolve before merging. +Note that developers with commit access are not required to do reviews or help with approving and merging PRs. It can still be useful to allow authors to fix trivial PR comments after approval and then merge their own PR, for example because the +review noted a minor typo, or to resolve merge conflicts. Developers with commit access are expected to make reasonable choices about when to approve or merge PRs for others -- generally, the change either needs to be From 988600e8af0466228d9fbbb382b8759e42cda52c Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 14:29:54 -0700 Subject: [PATCH 10/16] pre-commit --- docs/project/commit_access.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index d0874b1d5c18e..5e09e817df800 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -29,8 +29,10 @@ The main thing commit access allows is for developers to merge PRs into the main still need review, and often a reviewer with commit access handles the merge. It also gives the ability to [approve and merge changes](code_review.md). -Note that developers with commit access are not required to do reviews or help with approving and merging PRs. It can still be useful to allow authors to fix trivial PR comments after approval and then merge their own PR, for example because the -review noted a minor typo, or to resolve merge conflicts. +Note that developers with commit access are not required to do reviews or help +with approving and merging PRs. It can still be useful to allow authors to fix +trivial PR comments after approval and then merge their own PR, for example +because the review noted a minor typo, or to resolve merge conflicts. Developers with commit access are expected to make reasonable choices about when to approve or merge PRs for others -- generally, the change either needs to be From 12ec6a4462035b74a1148d7b5f86abcbebdb2fd3 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 14:34:25 -0700 Subject: [PATCH 11/16] Some small phrasing edits --- docs/project/commit_access.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 5e09e817df800..0691d572591ba 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -35,11 +35,11 @@ trivial PR comments after approval and then merge their own PR, for example because the review noted a minor typo, or to resolve merge conflicts. Developers with commit access are expected to make reasonable choices about when -to approve or merge PRs for others -- generally, the change either needs to be -trivially understood without context on the code in question (like a cleanup, -typo fix, etc), or the developer should have reasonable context on the code in -question. If in doubt, feel free to review but leave approving or merging for -someone else. +to approve or merge PRs for others. Generally, the change either needs to be +trivially understood without context on the code in question (such as a cleanup +or typo fix), or the developer should have some context on the code in question. +If in doubt, feel free to review but leave approving or merging for someone +else. Similarly, developers with commit access are expected to make reasonable choices about what changes to make to their own PRs without asking for another round of From 3f9141fee1bb4adc733373ac82a99917cb5922d9 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Wed, 28 Aug 2024 09:39:22 -0700 Subject: [PATCH 12/16] Update commit access link --- docs/project/groups.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/docs/project/groups.md b/docs/project/groups.md index 85e418fd54d90..2d32249dddfeb 100644 --- a/docs/project/groups.md +++ b/docs/project/groups.md @@ -125,10 +125,7 @@ any of the above community groups. ### GitHub commit access Developers who can merge and approve changes on GitHub. See -[commit access](https://github.com/carbon-language/carbon-lang/pull/4246) for -information. - -> TODO: link to commit_access.md when finalized. +[commit access](commit_access.md) for information. - GitHub teams: [Commit access](https://github.com/orgs/carbon-language/teams/commit-access) From a4b1e13b60128941bb5167ba64c2018037a2adcb Mon Sep 17 00:00:00 2001 From: jonmeow Date: Thu, 29 Aug 2024 09:21:58 -0700 Subject: [PATCH 13/16] Addressing comments --- docs/project/commit_access.md | 18 +++++++++--------- proposals/p4246.md | 12 ++++++++++++ 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 0691d572591ba..f9a8b354dba69 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -29,10 +29,10 @@ The main thing commit access allows is for developers to merge PRs into the main still need review, and often a reviewer with commit access handles the merge. It also gives the ability to [approve and merge changes](code_review.md). -Note that developers with commit access are not required to do reviews or help -with approving and merging PRs. It can still be useful to allow authors to fix -trivial PR comments after approval and then merge their own PR, for example -because the review noted a minor typo, or to resolve merge conflicts. +Getting commit access can help smooth over the development process; for +contributors who don't feel comfortable doing reviews, it can still smooth the +review process for their own PRs. It allows authors to merge their own PRs, +including after resolving conflicts or fixing trivial PR comments post-approval. Developers with commit access are expected to make reasonable choices about when to approve or merge PRs for others. Generally, the change either needs to be @@ -54,10 +54,10 @@ style and structure of the codebase. Access will typically be granted when developers have contributed several PRs and are expecting to continue making more. -After a few non-trivial PRs are merged, contributors should ask a reviewer to -nominate for commit access if they plan to keep contributing. Reviewers can also -directly suggest and nominate someone. Nominations need to be approved by at -least one lead. +After a few non-trivial PRs are merged, contributors can ask a reviewer to +nominate them for commit access if they plan to keep contributing. Reviewers can +also directly suggest and nominate someone. Nominations need to be approved by +at least one lead. When approved, an invitation will be sent to join the [Commit access team](https://github.com/orgs/carbon-language/teams/commit-access) @@ -71,7 +71,7 @@ Access is granted when the invitation is accepted. We'll periodically remove commit access from contributors who have been idle for over 6 months. We'll use a combination of sources to determine what "idle" means, including whether a developer has been either sending or reviewing PRs. -Developers should always ask for it to be restored if they plan to start +Developers can ask for commit access to be restored if they plan to start contributing again or come back from a break. Any relevant past contributions will still apply and allow it to be restored trivially. diff --git a/proposals/p4246.md b/proposals/p4246.md index 3e9a2cf21afc0..faeee18cfb5b8 100644 --- a/proposals/p4246.md +++ b/proposals/p4246.md @@ -15,6 +15,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception - [Abstract](#abstract) - [Problem](#problem) - [Background](#background) + - [Commit access](#commit-access) + - [Related policies](#related-policies) - [Proposal](#proposal) - [Rationale](#rationale) - [Alternatives considered](#alternatives-considered) @@ -42,6 +44,8 @@ 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: @@ -73,6 +77,14 @@ implications: - 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](/CONTRIBUTING.md#contributor-license-agreements-clas) +- [Code of Conduct](/CODE_OF_CONDUCT.md) +- [Review process](/docs/project/code_review.md) + ## Proposal The key things I think should be covered in this proposal are: From 45a58f5699c0f3bf4f784bd8275c10fdf775368d Mon Sep 17 00:00:00 2001 From: jonmeow Date: Thu, 29 Aug 2024 09:23:53 -0700 Subject: [PATCH 14/16] mention actions --- docs/project/commit_access.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index f9a8b354dba69..8287d6ff7ee93 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -31,8 +31,9 @@ also gives the ability to [approve and merge changes](code_review.md). Getting commit access can help smooth over the development process; for contributors who don't feel comfortable doing reviews, it can still smooth the -review process for their own PRs. It allows authors to merge their own PRs, -including after resolving conflicts or fixing trivial PR comments post-approval. +review process for their own PRs. It allows authors to automatically get action +results and merge their own PRs, including after resolving conflicts or fixing +trivial PR comments post-approval. Developers with commit access are expected to make reasonable choices about when to approve or merge PRs for others. Generally, the change either needs to be From 972f28ec9703f74d7fa6eb985eadb6da8656edab Mon Sep 17 00:00:00 2001 From: jonmeow Date: Thu, 29 Aug 2024 09:24:25 -0700 Subject: [PATCH 15/16] Clarify action --- docs/project/commit_access.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 8287d6ff7ee93..6b2bac271d64f 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -31,9 +31,9 @@ also gives the ability to [approve and merge changes](code_review.md). Getting commit access can help smooth over the development process; for contributors who don't feel comfortable doing reviews, it can still smooth the -review process for their own PRs. It allows authors to automatically get action -results and merge their own PRs, including after resolving conflicts or fixing -trivial PR comments post-approval. +review process for their own PRs. It allows authors to automatically get GitHub +Action results and merge their own PRs, including after resolving conflicts or +fixing trivial PR comments post-approval. Developers with commit access are expected to make reasonable choices about when to approve or merge PRs for others. Generally, the change either needs to be From 444455cd27291e74bdf4028479b9adac305cc5b9 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Thu, 29 Aug 2024 12:58:24 -0700 Subject: [PATCH 16/16] smooth over -> ease --- docs/project/commit_access.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/project/commit_access.md b/docs/project/commit_access.md index 6b2bac271d64f..bf8c72e750f8a 100644 --- a/docs/project/commit_access.md +++ b/docs/project/commit_access.md @@ -29,11 +29,11 @@ The main thing commit access allows is for developers to merge PRs into the main still need review, and often a reviewer with commit access handles the merge. It also gives the ability to [approve and merge changes](code_review.md). -Getting commit access can help smooth over the development process; for -contributors who don't feel comfortable doing reviews, it can still smooth the -review process for their own PRs. It allows authors to automatically get GitHub -Action results and merge their own PRs, including after resolving conflicts or -fixing trivial PR comments post-approval. +Getting commit access can help ease the development process; for contributors +who don't feel comfortable doing reviews, it can still ease the review process +for their own PRs. It allows authors to automatically get GitHub Action results +and merge their own PRs, including after resolving conflicts or fixing trivial +PR comments post-approval. Developers with commit access are expected to make reasonable choices about when to approve or merge PRs for others. Generally, the change either needs to be