mirror of https://github.com/dapr/community.git
Define the administrator role and its rules. (#269)
* Define the administrator role and its rules. Signed-off-by: Artur Souza <artursouza.ms@outlook.com> * Update ADMINISTRATORS.md Co-authored-by: Mark Fussell <markfussell@gmail.com> Signed-off-by: Artur Souza <asouza.pro@gmail.com> * Update ADMINISTRATORS.md Co-authored-by: Mark Fussell <markfussell@gmail.com> Signed-off-by: Artur Souza <asouza.pro@gmail.com> * Update ADMINISTRATORS.md Co-authored-by: Mark Fussell <markfussell@gmail.com> Signed-off-by: Artur Souza <asouza.pro@gmail.com> * Update ADMINISTRATORS.md Co-authored-by: Mark Fussell <markfussell@gmail.com> Signed-off-by: Artur Souza <asouza.pro@gmail.com> * Addresses comments. Signed-off-by: Artur Souza <artur.barbalho@outlook.com> Signed-off-by: Artur Souza <artursouza.ms@outlook.com> Signed-off-by: Artur Souza <asouza.pro@gmail.com> Signed-off-by: Artur Souza <artur.barbalho@outlook.com> Co-authored-by: Artur Souza <artursouza.ms@outlook.com> Co-authored-by: Mark Fussell <markfussell@gmail.com>
This commit is contained in:
parent
47815045c6
commit
cb7331f6b7
|
@ -0,0 +1,65 @@
|
||||||
|
# Dapr administrators
|
||||||
|
|
||||||
|
## Charter
|
||||||
|
|
||||||
|
Administrators have access to credentials equivalent to members of the steering and technical commitee (STC) and are responsible to perform pre-approved routine maintenance duties and ad-hoc tasks delegated by the STC without making isolated decisions. This document outlines a list of pre-approved duties and some that require STC approval - when in doubt, the administrator should seek guidance from one STC member.
|
||||||
|
|
||||||
|
## Granted access
|
||||||
|
|
||||||
|
Administrators have the following access:
|
||||||
|
* Owner of Dapr organization in GitHub
|
||||||
|
* Access to STC and Maintaners vaults in Dapr's 1Password
|
||||||
|
|
||||||
|
### Pre-approved duties
|
||||||
|
|
||||||
|
An administrator might perform the following duties without requiring approval from any STC member:
|
||||||
|
|
||||||
|
* Rotate credentials to services currently enrolled
|
||||||
|
* Update credentials on GitHub
|
||||||
|
* Rerun failed test runs
|
||||||
|
* Provision cloud resources to existing enrolled cloud providers
|
||||||
|
* Fix operational issues with existing services the project depends on (GitHub Actions, FOSSA, etc)
|
||||||
|
* Force merge a pull request upon request by repository's maintainer
|
||||||
|
|
||||||
|
### Duties that require STC approval
|
||||||
|
|
||||||
|
* Add or remove approvers, maintainers or administrators
|
||||||
|
* Create, graduate or archive projects in [dapr-sandbox](https://github.com/dapr-sandbox)
|
||||||
|
* Sign up to a new (free or paid) service, cloud provider or a service results in creating new credentials
|
||||||
|
|
||||||
|
## Process to become an administrator
|
||||||
|
|
||||||
|
0. As a pre-requisite, an administrator candidate **must first become a maintainer** of at least one repository in [Dapr](https://github.com/dapr). Being a maintainer in [dapr-sandbox](https://github.com/dapr-sandbox) does not qualify.
|
||||||
|
|
||||||
|
1. Then self-nominate via a [new issue in the community repository](https://github.com/dapr/community/issues/new) stating which repositories you currently maintain and the reasons why you want to be an administrator.
|
||||||
|
|
||||||
|
2. Add a link to the new issue in the next STC meeting agenda, asking it to be voted on. The agenda for STC meetings can be found in [issues in the Community repository](https://github.com/dapr/community/issues). Alternatively, candidate can request one STC member to seek approval via e-mail instead of waiting for the next STC meeting and have this recorded in the issue.
|
||||||
|
|
||||||
|
3. Administrators are approved with an STC voting simple majority.
|
||||||
|
|
||||||
|
## Limits and Expiration
|
||||||
|
|
||||||
|
The administrator role expires 6 months from the date it was approved. The process for renewal is the same as to become an administrator in the first place.
|
||||||
|
|
||||||
|
To minimize the number of people with access to shared credentials, there can only be 3 active or suspended administrators. Adding one more requires the STC to remove another.
|
||||||
|
|
||||||
|
## Removal
|
||||||
|
|
||||||
|
The administrator role is permanently removed in case any of the following:
|
||||||
|
* Expiration of the 6 months term as administrator
|
||||||
|
* Administrator is no longer a maintainer in Dapr
|
||||||
|
* STC votes with simple majority to remove administrator
|
||||||
|
* Administrator joins as an STC member
|
||||||
|
|
||||||
|
## Suspension
|
||||||
|
|
||||||
|
In order to de-risk potential misuse of power or suspicion of leaked credentials, at any moment, any STC member can temporarily suspend administrator role from any individual - revoking all privilege access - for any reason, without requiring an STC meeting. Reinstating administrator role requires the same process as becoming one in the first place.
|
||||||
|
|
||||||
|
## Current Administrators
|
||||||
|
|
||||||
|
| Name | Handle | Company | Status | Timezone | Term Start | Term End |
|
||||||
|
| - | - | - | - | - | - | -
|
||||||
|
|
||||||
|
### Statuses
|
||||||
|
* Active: has full access and can perform administrator duties.
|
||||||
|
* Suspended: holds an administrator position but access has been temporarily revoked.
|
|
@ -33,7 +33,7 @@ The governance of Dapr is an open, living document, and continues to evolve as t
|
||||||
1. Define, evolve, and promote the vision, values, and mission of the Dapr project.
|
1. Define, evolve, and promote the vision, values, and mission of the Dapr project.
|
||||||
1. Set the overall technical direction and roadmap of the Dapr project.
|
1. Set the overall technical direction and roadmap of the Dapr project.
|
||||||
1. Define and evolve project governance structures and policies, including
|
1. Define and evolve project governance structures and policies, including
|
||||||
project roles and how collaborators become members, approvers and maintainers and the responsibilities of the release team.
|
project roles and how collaborators become members, approvers, maintainers and admistrators and the responsibilities of the release team.
|
||||||
1. Steward, control access, delegate access, and establish processes regarding
|
1. Steward, control access, delegate access, and establish processes regarding
|
||||||
all Dapr project resources and has the final say in the disposition of
|
all Dapr project resources and has the final say in the disposition of
|
||||||
those resources.
|
those resources.
|
||||||
|
|
Loading…
Reference in New Issue