Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions project-docs/ADMINS.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
# Admins

This document lists the Admins of the Project. Admins may be added once approved by the existing Admins as described in the [Governance document](GOVERNANCE.md). By adding your name to this list you are agreeing to abide by the Project governance documents and to abide by all of the Organization's polices, including the [code of conduct](../CODE_OF_CONDUCT.md).
Inactive admins who transition off this list should be recorded in [EMERITUS.md](EMERITUS.md).


| **NAME** | **Handle** | **Affiliated Organization** |
Expand Down
19 changes: 19 additions & 0 deletions project-docs/EMERITUS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
# Emeritus Members

This document records former project Maintainers and Admins who have moved to emeritus status due to inactivity.
The goal is not to remove people from the community, but to keep role lists aligned with realistic availability so a volunteer group can plan work and responsibilities effectively.

## Policy

- A Maintainer or Admin with no qualifying project activity in the previous 12 months may be nominated for emeritus status.
- Qualifying activity includes at least one commit, pull request, issue, issue comment, or pull request review in a Vega organization repository.
- Before opening an emeritus move, maintainers/admins should make a best effort to contact the person via Slack, email, or another preferred communication channel.
- Maintainers/admins should wait at least 30 days after first outreach before opening an emeritus PR. If there is no response after 60 days, they may proceed with the PR.
- The PR proposing emeritus changes should include a brief inactivity summary and note the outreach attempts.
- Emeritus moves follow the same voting thresholds described in [GOVERNANCE.md](GOVERNANCE.md) for role removal.
- Emeritus members may be re-added as Maintainers or Admins through the normal nomination and approval process.

## Emeritus List

| **NAME** | **Handle** | **Previous Role(s)** | **Date Moved** | **Notes** |
| --- | --- | --- | --- | --- |
4 changes: 2 additions & 2 deletions project-docs/GOVERNANCE.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,15 +20,15 @@ Maintainers have write access and can push directly to branches on GitHub. Maint

To become a Maintainer, a contributor must be nominated by an existing Maintainer and approved by a simple majority of Maintainers via Slack reactions within 7 days (simple majority of responses). A new Maintainer should be added to 1) the GitHub team, 2) the Slack channel, and 3) the [MAINTAINERS.md file](MAINTAINERS.md). The details of the vote should be deleted before the new maintainer is added to the channel. We want more people to become Maintainers and lower the barrier the entry. If being a Maintainer would make it easier for you to contribute, please reach out to an existing Maintainer to express your interest in becoming a maintainer.

Maintainers who are inactive for more than six months may be removed from the Maintainer list by 3/4 vote of the existing Maintainers.
Maintainers who are inactive for more than six months may be removed from the Maintainer list by 3/4 vote of the existing Maintainers. As a default process, Maintainers with no qualifying activity in the previous 12 months should be moved to [EMERITUS.md](EMERITUS.md), unless Maintainers decide otherwise during the vote. Outreach expectations, timing, and PR documentation requirements are defined in [EMERITUS.md](EMERITUS.md). The intent is planning accuracy for a volunteer team, not exclusion from the community.

### Admins

Admins are maintainers who can make and are responsible for releases. Admins are [owners of the GitHub organization](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#organization-owners).

To become an Admin, a Maintainer must be nominated and approved by the existing Admins using the same process as for Maintainers. Admins are listed in the [ADMINS.md file](ADMINS.md).

Admins who are inactive for a year may be removed from the Admin list by 3/4 vote of the existing Admins.
Admins who are inactive for a year may be removed from the Admin list by 3/4 vote of the existing Admins. As a default process, Admins with no qualifying activity in the previous 12 months should be moved to [EMERITUS.md](EMERITUS.md), unless Admins decide otherwise during the vote. Outreach expectations, timing, and PR documentation requirements are defined in [EMERITUS.md](EMERITUS.md). The intent is planning accuracy for a volunteer team, not exclusion from the community.

## Decisions

Expand Down
1 change: 1 addition & 0 deletions project-docs/MAINTAINERS.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
# Maintainers

This document lists the Maintainers of the Project. Maintainers may be added once approved by the existing maintainers as described in the [Governance document](GOVERNANCE.md). By adding your name to this list you are agreeing to abide by the Project governance documents and to abide by all of the Organization's polices, including the [code of conduct](../CODE_OF_CONDUCT.md).
Inactive maintainers who transition off this list should be recorded in [EMERITUS.md](EMERITUS.md).

| **NAME** | **Handle** | **Affiliated Organization** |
| --- | --- | --- |
Expand Down