SIMD Access Policy

Summary

3 levels of access, in the order of increasing access:

1. Triage

   Requirement: One voucher from anyone with level 2 or above access.

2. Write

   Requirement: One voucher from anyone with level 3 access or two from

anyone with level 2 access. If only vouched by those with level 2 access, the user must have Triage access to be promoted.

3. Maintain

   Requirement: One voucher from anyone with level 3 access. This permission

is usually reserved for those maintaining the SIMD process.

Each of the levels implies having the previous levels - e.g. level 2 implies level 1. A contributor with Write access will be able to triage pull requests in accordance with Github access policies.

Motivation

Shamelessly borrowing from Mozilla's access policy :

There are two sorts of control which can be used to stop people checking in -
technical and social.

A "full technical" implementation would have per-directory permissions
everywhere, but would lead to a greatly-increased management overhead for IT,
vouchers and developers alike.
A "full social" implementation would just have a single permission which gave
you complete access to everything, but (depending on the height of the barrier
to that permission) there is a risk of making developer's lives more difficult
when they are excluded, or of giving the untrustworthy or incompetent power to
mess things up.
Therefore, a good policy balances the use of technical and social controls to
minimize both management overhead and risk to the development process.

Alternatives Considered

EIP run under two separate levels, contributors and editors. Editors are a select group of people that review each EIP and have write access. Instead of starting with a select group of editors who have exclusive write access, we could begin with an easier way to achieve write access and gradually tighten permissions as needed.

RFCs have sub-teams that review and triage new proposed changes. This is a possibility, but would require more granular labeling of different SIMDs.

PEP has an election of a council that reviews and triages new proposed changes. The PEP approach may result in an increase in governance overhead.

Detailed Design

Level 1 - Triage Access

Requirements: One voucher from any user with level 2 or above access.

Contributors with Triage access will have the associated triage Github access policy for the Solana Improvement Documents repository.

Level 2 - Write Access

Requirements: One voucher from anyone with level 3 access or two vouchers from anyone from level 2. Applicants must have level 1 access to apply for level 2.

Contributors with Write access will have the associated write Github access policy for the Solana Improvement Documents repository.

Most notably these permissions allow the contributor to approve and merge pull requests.

Level 3 - Maintain Access

Requirements: One voucher from anyone with level 3 access.

Contributors will have the associated maintain Github access policy for the Solana Improvement Documents repository.

Users with Maintain access are responsible for managing the SIMD repository and granting user access based on the above requirements.

Vouching Process

To receive a level of access as defined in SIMD-0007, follow these steps:

1. Open an issue on the Solana Improvement Documents repository with a title in the following format: "Request Access (Level [X]) for [Username]". Add information that can help identify you such as your discord id in the issue.
2. Gather your vouchers to add a comment on the issue expressing their support.
3. Once the issue has received enough support, notify the users with Maintain access by adding a comment tagging @SIMD-Maintainers and you will be granted the requested level of access.

Access Removal Process

In the event that a user requires their access to be removed, follow these steps:

1. Open an issue on the Solana Improvement Documents repository with the title in the following format: "Revoke Access (Level X) for [Username]".
2. Other users with the appropriate level of access should comment on the issue to express their support for the removal of access.
3. Once the issue has received enough support, the user's access will be revoked.

Requirements:

• If a user's level 3 access is being revoked, support from at least two other users with level 3 access is required.
• If a user's level 1 or 2 access is being revoked, support from at least two other users with level 2 or one user with level 3 is required.
• If a user opens the issue to revoke their own access, no support from others is required.

Impact

Setting a permissive way of contributing to the SIMD process will help remove engineering overhead.

Security Considerations

In the event of a malicious actor gaining any level of access, users must follow the Access Removal Process to revoke that actor's access.