From e2c0c3473017e81c0522d7745117ab8942611a35 Mon Sep 17 00:00:00 2001 From: Chloe Kudryavtsev Date: Thu, 28 Mar 2019 10:44:09 -0400 Subject: [teams] Move into its own module This also makes making team-specific pages easier --- antora.yml | 1 + modules/ROOT/nav.adoc | 1 - modules/ROOT/pages/teams.adoc | 122 ----------------------------------------- modules/Teams/nav.adoc | 1 + modules/Teams/pages/index.adoc | 122 +++++++++++++++++++++++++++++++++++++++++ 5 files changed, 124 insertions(+), 123 deletions(-) delete mode 100644 modules/ROOT/pages/teams.adoc create mode 100644 modules/Teams/nav.adoc create mode 100644 modules/Teams/pages/index.adoc diff --git a/antora.yml b/antora.yml index 238b860..3481db7 100644 --- a/antora.yml +++ b/antora.yml @@ -3,4 +3,5 @@ title: Developer Handbook version: '0.1a' nav: - modules/ROOT/nav.adoc + - modules/Teams/nav.adoc - modules/Policies/nav.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 2530381..3d92412 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -1,2 +1 @@ * xref:index.adoc[Introduction] -* xref:teams.adoc[Teams & Structure] diff --git a/modules/ROOT/pages/teams.adoc b/modules/ROOT/pages/teams.adoc deleted file mode 100644 index 53aa2ad..0000000 --- a/modules/ROOT/pages/teams.adoc +++ /dev/null @@ -1,122 +0,0 @@ -= 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. 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. -- cgit v1.2.3