Alpine Governance

governance.md

title
Alpine Governance

Introduction

The Alpine Linux project exists to create a community-driven Linux distribution, with an emphasis on friendly participation. This document outlines the overall governance process of the project as well as responsibilities of individual contributors. It does not define any other details other than the governance processes.

Decision-making bodies

Decisions in the project are made by one or more of:

• Individual contributors;
• Working groups established by one or more contributors;
• the Alpine Infrastructure team;
• the Alpine Core team.

Individual Contributors

1. There is no obligation for anyone to do work for the Project. A contributor who has been delegated a specific task is not required to do the task if they disagree with the task, however, they must not actively work against the implementation of any decision made in accordance to this policy.

2. Individual contributors are required to adhere to the Code of Conduct.

3. A contributor may leave the Project at any time, by stating so publicly.

Maintainers and Developers

1. Maintainers are contributors who have been granted limited access to the git repositories.

2. Developers are contributors who have been granted full access to the git repositories.

3. Developers have the ability to sponsor contributions from maintainers and unprivileged contributors by committing the changes on their behalf.

4. A Developer may nominate a contributor for either Maintainer or Developer status. The nomination will be considered by the Alpine Core team.

Infrastructure Team

1. The Alpine Infrastructure team oversees management of the Project's infrastructure.

2. Contributors to the Infrastructure team may be granted limited access without also being Developers but this access should not include push access to the git repositories. System Administrator privileges grants are decided by the Alpine Core team, in the same way as Developers.

3. The Infrastructure team is required to implement decisions made by the Core team in accordance with these rules.

Core Team

1. The Alpine Core team oversees management of the entire Project, including making decisions of strategic importance when necessary.

2. Prospective Developers and Maintainers that have been nominated by a current Developer will have those nominations considered by the Core team.

3. If a vacancy exists on the Core team, the Core team will nominate a new member. The Project as a whole will decide whether the new member should be added to the Core team using lazy consensus.

4. Any decision made by the Core team may be overridden with a 3:1 majority quorum of current Developers.

Procedure for Nominating New Developers and Maintainers

1. Any current Developer may nominate another person as a prospective new Developer or Maintainer.

2. To nominate the Developer, the person nominating them should write to [email protected].

3. After the Core team accepts the nomination, the Secretary will announce the nomination to [email protected].

4. Statements of support or objection should be sent to [email protected].

5. Developers and Maintainers are approved by the Core team using lazy consensus.

Procedure for Nominating New System Administrators

1. Any current System Administrator may nominate another person as a new System Administrator.

2. To nominate the System Administrator, the person nominating them should write to [email protected].

3. After the Core team accepts the nomination, the Secretary will announce the nomination to [email protected].

4. Statements of support or objection should be sent to [email protected].

5. System Administrators are approved by the Core team using lazy consensus.

Procedure for Nominating New Core Team Members

1. The Core team may nominate new members to fill vacancies or to add new seats.

2. There may be a maximum of 21 seats on the Core team at any time. The number of seats on the Core team must be an odd number.

3. New Core team members are approved by the Project as a whole using lazy consensus when possible.

Procedure for the Expulsion of Privileged Contributors

1. Any Developer or System Administrator may nominate another Developer, Maintainer or System Administrator for Expulsion.

2. The nomination for Expulsion must be sent to [email protected].

3. Once the Core team accepts the nomination, the Secretary is required to contact the nominee and notify them. The nominee can choose whether to handle the matter publicly or privately.

4. The System Administrators are required to temporarily disable any accounts belonging to the nominee.

5. If the nominee chooses to go public, the nominee should write to [email protected] explaining the situation.

6. Statements in support or objections should be sent to [email protected].

7. The Core team will make a decision using lazy consensus; if the Core team decides to expel the nominee, their account will be removed.

8. In the event of an expulsion, the Core team will set a timeline for when the nominee may be nominated for Developer or System Administrator privilege again.

Lazy Consensus

1. Almost all decisions in the Project are made using a process called "lazy consensus."

2. Under lazy consensus, any issue that has sat for a period of time defined by the Secretary without any objections passes.

3. In the event of an objection, any issue that has a 3:1 majority of approval votes passes.

Project Secretary

1. The Project Secretary sits on the Core Team and is responsible for disclosing Core team decisions.

2. In the event that a Project-wide vote is required, the Secretary is responsible for overseeing the vote process. The Secretary may conduct the vote however they see fit.