157 lines
6.0 KiB
Markdown
157 lines
6.0 KiB
Markdown
|
---
|
||
|
simd: '0007'
|
||
|
title: SIMD Access Policy
|
||
|
authors:
|
||
|
- Jacob Creech (Solana Foundation)
|
||
|
category: Meta
|
||
|
type: Meta
|
||
|
status: Draft
|
||
|
created: 2022-12-10
|
||
|
---
|
||
|
|
||
|
## 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](https://www.mozilla.org/en-US/about/governance/policies/commit/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](https://github.com/ethereum/EIPs) 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](https://www.rust-lang.org/governance) have sub-teams that review and
|
||
|
triage new proposed changes. This is a possibility, but would require more
|
||
|
granular labeling of different SIMDs.
|
||
|
|
||
|
[PEP](https://peps.python.org/pep-0013/) 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](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||
|
for the [Solana Improvement
|
||
|
Documents](https://github.com/solana-foundation/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](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||
|
for the [Solana Improvement
|
||
|
Documents](https://github.com/solana-foundation/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](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||
|
for the [Solana Improvement
|
||
|
Documents](https://github.com/solana-foundation/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](https://github.com/solana-foundation/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`](https://github.com/orgs/solana-foundation/teams/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](https://github.com/solana-foundation/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.
|