Add detail about what's really specifically being evolved.

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)
 
 <!-- tocstop -->
 
@@ -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.