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
|
= Teams and Internal Structure
:votelink: xref:Policies:voting.adoc
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]
Team:: A group of people with a specific purpose/scope that they tend to.
Team Member:: A registered member of a team, given access to that team's workspaces.
Developer:: Any Team Member is considered a fully fledged developer.
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.
[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.
However, all team members are expected to follow project-wide policies (all of which are in the developer handbook as well) and the https://alpinelinux.org/community/code-of-conduct.html[Code of Conduct].
=== Being a Team Administrator
As a team admin, you have more powers, and thus more responsibility.
Since you have the power to {votelink}[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 perform an internal voting process, similar to that of {votelink}[project-wide voting].
=== Becoming a Team Administrator
The position of team admin involves a large amount of trust.
Team admins can vote on actions that will change the entirety of the project.
As such, the only way to become a team admin is by suggesting yourself to an existing admin, and having them call a {votelink}[Vote].
=== 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 that all the team admins of a given team perform an internal voting process, similar to that of {votelink}[project-wide voting].
=== 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, this shall be done through a {votelink}[Vote]
[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.
====
=== Removals Due to Inactivity
Sometimes, people go missing.
If a member has not been active for 120 days, they will be asked about the situation.
Administrators have an even higher standard (as they are expected to come to meetings and {votelink}[vote]).
As such, on top of the 120 day limit, administrators will be asked about the goings-on if they have missed 5 consecutive meetings or votes.
NOTE: This line of questioning may lead to their removal: if they contribute every 4 months, perhaps they should send patches instead, and if they are not participating in {votelink}[votes], perhaps they should simply be members, rather than admins.
=== 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 Base team.
As such, any member may request any such resources from the Base 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.
However, all teams must have at least 1 admin, and at most 3.
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.
== The Base Team
The Base team is purely an administrative one.
It is also the only team that shall not have admins, and has a static number of members.
The Base team must always have exactly 3 members, to guarantee quorum.
The Base team technically owns Alpine.
Alpine's policies apply to them, but they have the power to bypass them in case of extreme need.
It is expected that the Base team does not do anything unless prompted.
Violation of this without there being a strong need is effectively a violation of trust of the entire rest of the project.
Similarly, the Base team is expected to trust team admins and members to do the correct thing on their own.
Base team members are elected through a project-wide {votelink}[Vote].
A term is 3 years long, and the terms are staggered (each year, a new Base team member must be elected).
Term cycling is allowed - you cannot replace yourself, but you can replace the next person to rotate out.
|
