From eff06e42b8f956cd768a69ed992c7b53da85a4d9 Mon Sep 17 00:00:00 2001 From: jonmeow Date: Fri, 23 Aug 2024 13:32:26 -0700 Subject: [PATCH] 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.