Getting commit access

[jonmeow]

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.

[jonmeow]

Note, looking at Commit acess:

• camio - last comment Apr 2023, but has been active in other forums
• chandlerc - active this week
• fowles - last comment Oct 2023, no PRs
• geoffromer - active this week
• jonmeow - active this week
• josh11b - active this week
• jsiek - Sep 2022
• mattgodbolt - Jul 2022
• pixep - Aug 2023, though recently active on Discord
• pk19604014 - Sep 2022
• pmqtt - Feb 2023
• tkoeppe - Sep 2021 for PR activity, Nov 2023 in discussions
• wolffg - Aug 2022 for PR activity, active in discussions
• zygoloid - active two weeks ago

So if we're basing this purely on PR activity, that would mean removing commit access for everyone but chandlerc, geoffromer, jonmeow, josh11b, and zygoloid.

[chandlerc]

Mostly wording tweaks... but maybe @dwblaikie can also help with wording as he's been involved in similar discussions in the LLVM community?

[zygoloid]

This looks good to me. No real comments on the policy or approach, just some minor wording things.

I do worry a little that having people self-nominate or ask their reviewer for commit access might lead to some awkward conversations if we think they're not ready yet, and might also lead to some forms of self-nomination bias, but I don't have a better suggestion, so I'm happy to go with this.

[zygoloid]

I did not understand this paragraph. (For what it's worth, I think the rest of the text works fine without it.)

First sentence: is this saying

1. Commit access is not accompanied with a responsibility to do reviews or help with approving and merging PRs. (Developers with commit access are not required to [do certain things] as a condition of their commit access)
   or
2. Reviews and approving or merging PRs can be done without the help of a developer with commit access. (Developers with commit access are not required in order to [do certain things])

Second sentence: What are the consequences of this being useful? Is some particular action encouraged or discouraged, or some policy or advice we want to give here? How is this connected to what we said in the first sentence?

Also, can authors without commit access merge their own PRs after approval? I thought that merging PRs, even once approved, still requires commit access?

[chandlerc]

FYI, there was some discussion about this paragraph here: #4246 (comment)

And...

Also, can authors without commit access merge their own PRs after approval? I thought that merging PRs, even once approved, still requires commit access?

I believe they cannot -- and I believe enabling this is a primary motivation for granting commit access.

[jonmeow]

Authors without commit access haven't ever been able to merge changes.

Also, recently actions became more restrictive for security reasons. I think in the past, a contributor only needed "approve and run" on their first PR. I'm not sure if there's any threshold where "approve and run" is no longer needed now.

So the present state is that people without commit access require assistance in order to both run actions and merge commits.

[jonmeow]

Note, rephrased the paragraph again.

[zygoloid]

Thank you! The new phrasing works for me.

[jonmeow]

Sorry, one small edit, "smooth over" -> "ease" due to possible connotations.

[zygoloid]

LGTM

[chandlerc]

Approving for leads (and confirmed with all three FWIW, given the nature of this). Thanks!