aboutsummaryrefslogtreecommitdiffstats
path: root/modules
diff options
context:
space:
mode:
authorChloe Kudryavtsev <toast@toastin.space>2019-03-26 16:29:49 -0400
committerChloe Kudryavtsev <toast@toastin.space>2019-03-26 16:29:49 -0400
commit91faa1dc4bcca1074eb8ab627362da5e1569cf7a (patch)
tree1e164d7076e43ec8457bf9ec01fc4d8ef3ec3bc1 /modules
parent0fc447ba04878264c112284852325dc499b8350e (diff)
downloadgovernance-91faa1dc4bcca1074eb8ab627362da5e1569cf7a.tar.bz2
governance-91faa1dc4bcca1074eb8ab627362da5e1569cf7a.tar.xz
[nav] Switch from single-page
Still stay in single-module.
Diffstat (limited to 'modules')
-rw-r--r--modules/ROOT/nav.adoc3
-rw-r--r--modules/ROOT/pages/index.adoc193
-rw-r--r--modules/ROOT/pages/teams.adoc190
3 files changed, 196 insertions, 190 deletions
diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
index 8009336..a910f5a 100644
--- a/modules/ROOT/nav.adoc
+++ b/modules/ROOT/nav.adoc
@@ -1 +1,2 @@
-* xref:index.adoc[Teams & Organization]
+* xref:index.adoc[Introduction]
+* xref:teams.adoc[Teams & Organization]
diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc
index 6f9e8fc..6254a54 100644
--- a/modules/ROOT/pages/index.adoc
+++ b/modules/ROOT/pages/index.adoc
@@ -1,190 +1,5 @@
-= Teams and Internal Organization
+= Alpine Developer Handbook
-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.
-====
-
-=== 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 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 coming to 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 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
-| Kaarle Ritvanen | kunkku | kaarle.ritvanen@datakunkku.fi
-| 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 access to aports (the entire packaging repository), 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
-|===
+== What is It?
+This is the Alpine Developer Handbook, an effort to centralize relevant Alpine Linux information intended for developers and contributors.
+This handbook contains various internal details as to how Alpine is organized, the process of contributing and joining, as well as listing of internal policies and organizational bodies.
diff --git a/modules/ROOT/pages/teams.adoc b/modules/ROOT/pages/teams.adoc
new file mode 100644
index 0000000..6f9e8fc
--- /dev/null
+++ b/modules/ROOT/pages/teams.adoc
@@ -0,0 +1,190 @@
+= 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.
+====
+
+=== 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 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 coming to 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 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
+| Kaarle Ritvanen | kunkku | kaarle.ritvanen@datakunkku.fi
+| 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 access to aports (the entire packaging repository), 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
+|===