1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
= Teams and Internal Organization
Alpine is organized into various teams.
Teams help with delegating work.
Delegating work requires people to be available and get the necessary permissions to do their work.
Teams also make it easier for people to join specific teams, rather than the entirety of the project and all that entails.
Finally, this organizational structure gives more transparency as to how work is divided, and aids collaboration with outside entities.
This section describes the status quo of how Alpine is organized.
[glossary]
== Glossary
[glossary]
Developer:: Any Team Member is considered a fully fledged developer.
Team:: A group of people with a specific purpose/scope that they tend to.
Team Administrators::
Team members that are allowed to vote in various organizational meetings and can appoint new team members.
Team Admins are marked in *bold* in official team listings.
Team Member:: A registered member of a team, given access to that team's workspaces.
[NOTE]
====
There is no distinction between technical and non-technical team members. Both are valued, and any useful distinctions are left to the discretion of individual teams.
====
== Membership
=== Being a Member
Being in a team grants grants you the things you need to work on whatever the scope of the team is.
You should know your fellow team members well, and cooperate with them (and potentially other teams) to achieve tasks.
As a team, you may request various workspaces, such as a separate irc channel, git namespace, dedicated host, and more.
As a team, it is up to you how you manage yourselves internally, but the contents of this document should serve as guidelines.
[WARNING]
====
Some teams are strict supersets of others.
For example, the packaging team handles all packages, but the core team handles the `main/` repository and the python team handles python-related packages.
Teams with the more concrete scope (core and python in this example) are given priority over their domain.
If you are part of the generic team, but are not part of the specific team, you should communicate with the specific team if you wish to change something within their domain.
Doing otherwise (especially if it has negative consequences) can be considered abuse of your power, and may even lead to you being removed from the team.
====
=== Being a Team Administrator
As a team admin, you have more powers, and thus more responsibility.
Since you have the power to vote (e.g in nominating other team admins), you are expected to be present for meetings and voting sessions.
In the scenario that you must be absent for significant periods of time (more than a few days), you are expected to inform other team admins of that.
=== Becoming a Member
Team admins have the ability to add new members.
You should have already contributed to the team in question (whether technically or non-technically), and convinced a admin that you should be in a team (just asking can be enough, sometimes).
Technically, any admin may add or remove members, and teams may organize themselves however they wish internally.
However, we recommend that all the team admins of a given team vote on adding a member, with the goal being a 2/3 majority.
NOTE: 1/1 is 100%.
=== Becoming a Team Administrator
New team admins are voted in by all the other team admins in the project.
In order for a team admin to be voted in, they must garner a 50% majority vote, and already be a part of that team.
This vote can be done asynchronously, but in that case the absolute time limit is 2 weeks, after which, if the vote is inconclusive, the matter is resolved by the core team.
=== Removing a Member
Sometimes, members must be removed.
This can happen for a variety of reasons.
Teams are free to organize themselves as they see fit, but we recommend leaving purging team members as the last option on the table.
In the case that it must come to pass, we recommend the proceedings be identical as in <<_becoming_a_member>>.
=== Removing an Administrator
Team admins are members as well, but there is no higher in-team authority available to remove them.
In the scenario that this last resort is considered, the procedure will be the same as in <<_becoming_a_team_administrator>>.
[WARNING]
====
Removing members (and especially administrators) is an extreme measure.
In most cases, it is possible to solve issues through other means.
It is highly recommended that the removal of anyone from the project be strongly considered before it is suggested.
====
=== Project-Specific Resources
There are some resources the project has access to that don't make sense on a per-team basis.
As an example, consider the `@alpinelinux.org` email addresses.
All non-team management related resources are handled by the core team.
As such, any member may request any such resources from the core team, though access may be denied.
NOTE: If your request is denied, don't worry - consult the reason given and feel free to ask again later (depending on the reason).
[WARNING]
====
Having access to project-specific resources (*especially* email addresses) makes you a representative of the project.
Use with caution, and make sure you clearly differentiate between your opinions, and those of the project.
====
== Team Structure
=== Internal Organization
Teams organize themselves internally however they want.
This document does contain multiple recommendations, which, if followed, will make external relations easier.
Further, team administrators must follow non-team-local expectations.
=== Creating a New Team
An existing team member within the project may propose creating a new team.
In that scenario, the process will be the same as in <<_becoming_a_team_administrator>>.
If the vote passes, the new team is formed, with the sponsor member as the only administrator.
=== Dissolution of Teams
A team is dissolved if it has no more members.
If a team has no more administrators, one must be nominated, as in <<_becoming_a_team_administrator>>.
If the vote does not pass, the team is dissolved as well.
// TODO: specify what specific access each team has
== Current Team Listing
=== Core
Core team members have oversight over the entire project.
They also have the final say on packaging and security matters, and are the sole arbiters of the `main` repository.
NOTE: The core team may also do everything the packaging team may do during the (currently unlimited) transitional period.
|===
| Name | Nick | Email
| Carlo Landmeter | clandmeter | clandmeter@alpinelinux.org
| Christian Kampka | ckampka | christian@kampka.net
| Francesco Colista | fcolista | fcolista@alpinelinux.org
| Jakub Jirutka | jirutka | jakub@jirutka.cz
| Kaarle Ritvanen | kunkku | kaarle.ritvanen@datakunkku.fi
| Kevin Daudt | \_ikke_ | kdaudt@alpinelinux.org
| Leonardo Arena | rnalrd | rnalrd@gmail.com
| Nathan Angelacos | nangel | nangel@alpinelinux.org
| *Natanael Copa* | *ncopa* | ncopa@alpinelinux.org
| Roberto Oliveira | rdutra | rgdoliveira@alpinelinux.org
| Soeren Tempel | nmeum | soeren@soeren-tempel.net
| Timo Teräs | fabled | timo.teras@iki.fi
| William Pitcock | kaniini | nenolod@dereferenced.org
|===
=== Infrastructure
The infrastructure team takes care of the Alpine Linux infrastructure - maintaining the servers and services needed to keep everything running.
|===
| Name | Nick | Email
| *Carlo Landmeter* | *clandmeter* | clandmeter@alpinelinux.org
| Daniel Isaksen | danieli | d@duniel.no
| Kevin Daudt | \_ikke_ | kdaudt@alpinelinux.org
|===
=== Documentation
The documentation team creates and maintains all official documentation for Alpine Linux.
// TODO: once toast@toastin.space is recognized as an email, simplify entry
|===
| Name | Nick | Email
| *Chloe Kudryavtsev* | *SpaceToast* | mailto:toast@toastin.space[toast@toastin.space]
|===
=== Security
The security team takes care of communication with vulnerability reporters, maintaining an Alpine security advisory program, and information sharing with other projects.
|===
| Name | Nick | Email
| *Natanael Copa* | *ncopa* | ncopa@alpinelinux.org
|===
=== Packaging
Packaging team members have (limited) access to aports, take care of maintaining and creating packages, as well as accepting PRs and patches from the community.
|===
| Name | Nick | Email
| A. Wilcox | awilfox | awilcox@wilcox-tech.com
| Andy Postnikov | andypost | apostnikov@gmail.com
| Breno Leitao | leitao | breno.leitao@gmail.com
| Christian Kampka | ckampka | christian@kampka.net
| Daniel Sabogal | dsabogal | dsabogalcc@gmail.com
| Henrik Riomar | HRio | henrik.riomar@gmail.com
| *Natanael Copa* | *ncopa* | ncopa@alpinelinux.org
| Roberto Oliveira | rdutra | rgdoliveira@alpinelinux.org
| N/A | Shiz | hi@shiz.me
|===
|
