[teams] Update based on new policies/discussion

1. Voting, conflicts, etc are not mentioned elsewhere.
2. Rename Core -> Packaging
3. Rename Packaging -> Packaging: Community
4. Add "Base" as an administrative team

1 files changed, 30 insertions, 29 deletions

diff --git a/modules/ROOT/pages/teams.adoc b/modules/ROOT/pages/teams.adoc
index 47bbe83..0d6615f 100644
--- a/modules/ROOT/pages/teams.adoc
+++ b/modules/ROOT/pages/teams.adoc
@@ -1,4 +1,5 @@
 = Teams and Internal Structure
+:votelink: xref:Policies:voting.adoc
 
 Alpine is organized into various teams.
 Teams help with delegating work.
@@ -30,44 +31,33 @@ Being in a team grants grants you the things you need to work on whatever the sc
 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 and the https://alpinelinux.org/community/code-of-conduct.html[Code of Conduct].
-
-[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.
-====
+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 vote (e.g in nominating other team admins), you are expected to be present for meetings and voting sessions.
+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 vote on adding a member, with the goal being a 2/3 majority.
-
-NOTE: 1/1 is 100%.
+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
-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.
+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 the proceedings be identical as in <<_becoming_a_member>>.
+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, the procedure will be the same as in <<_becoming_a_team_administrator>>.
+In the scenario that this last resort is considered, this shall be done through a {votelink}[Vote]
 
 [WARNING]
 ====
@@ -79,16 +69,16 @@ It is highly recommended that the removal of anyone from the project be strongly
 === 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).
+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 coming to votes, perhaps they should simply be members, rather than admins.
+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 core team.
-As such, any member may request any such resources from the core team, though access may be denied.
+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).
 
@@ -118,11 +108,20 @@ 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.
+=== Base
+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.
 
-NOTE: The core team may also do everything the packaging team may do during the (currently unlimited) transitional period.
+=== Packaging
+Packaging team members have oversight over all the packages and branches of aports.
+They are expected to primarily preoccupy themselves of the main repository and the stable branches.
 
 |===
 | Name | Nick | Email
@@ -173,8 +172,10 @@ The security team takes care of communication with vulnerability reporters, main
 | *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.
+=== Packaging: Community
+Packaging: Community team members have access to aports, except for the main repository.
+Their parent team is packaging.
+They take care of maintaining and creating packages, as well as accepting PRs and patches from the community, with the exception of the main repository.
 
 |===
 | Name | Nick | Email