[teams] Move into its own module

This also makes making team-specific pages easier

2 files changed, 123 insertions, 0 deletions

diff --git a/modules/Teams/nav.adoc b/modules/Teams/nav.adoc
new file mode 100644
index 0000000..3814ac2
--- /dev/null
+++ b/modules/Teams/nav.adoc
@@ -0,0 +1 @@
+* xref:index.adoc[Teams & Structure]
diff --git a/modules/Teams/pages/index.adoc b/modules/Teams/pages/index.adoc
new file mode 100644
index 0000000..53aa2ad
--- /dev/null
+++ b/modules/Teams/pages/index.adoc
@@ -0,0 +1,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.