Spoke with Chloe about this privately. I think the original charter of the base team dillutes the authority necessary for it to be effective in times of crisis. By outlining a bunch of limitations on the base team, it gives tools to bad actors to undermine their authority with, and works against the trust we're supposed to be putting in that team. This reframes the base team as self-governing, putting how it governs itself as out of scope for the project-wide governance document, and updates the project governance docs accordingly to establish the base team more firmly as the final authority on the project. However, the information lost is still important. We should find a place to put a document which establishes the principles to which the base team holds itself. These include at least: - Live up to the faith the project has put in you - Trust the teams and generally avoid intervention - Have faith in the election process and trust the next base team to execute the role responsibly We should use these principles when establishing the initial base team. As new members cycle in, the veterans should use their first year to educate them on the principles by which they can be responsible stewards of the project. Aside: the first patch is pretty unopinionated. I shoved all of the opinions into the second patch. Drew DeVault (2): Move team structure before team administration Rework the base team description modules/Teams/pages/index.adoc | 62 ++++++++++++++++------------------ 1 file changed, 29 insertions(+), 33 deletions(-) -- 2.21.0 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
Any scheme that would result in Natanael being removed from the base team after three years would not get my vote. As far as I am concerned, ncopa should be Alpine Linux’s Benevolent Dictator For Life. Completely serious.
One of the stated goals of this effort is to reduce ncopa's workload and bus factor. What good is it if ncopa gets burnt out? I trust ncopa not to ratifiy a governance model that won't work, and you ought to as well. Personally I agree that the BDFL model is a very effective one, but I think that Chloe has found one which may be similarly effective and has several advantages.Ted Trask <ttrask01@yahoo.com>--- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ------ Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
Ted
There is a big difference between sharing the workload and giving up authority. My main objection is to the stipulation that a base team member cannot be reelected immediately. Not only is ncopa sharing authority with two others for the first three years, he would be forced to give up all authority in the fourth year. Or am I reading it wrong?
You're interpreting it correctly, though I assume ncopa will continue to serve his roles in teams other than base during that time. I think that you should trust ncopa to back a governance model he believes will work, even if it means he has to take a break every few years. He is far from uninvolved in these discussions, I suggest you trust his judgement in this matter. After all, if he doesn't want the authority then it's not your place to force him to accept it.Natanael Copa <ncopa@alpinelinux.org>I have never said I want to resign. I would very much like to share it and I would very much be able to take a break if needed and leave it in trusted hands. I need to be prepared to give up authority if that ever will be needed. I must admit I am not very comfortable with the thought of being forced to completely giving up authority but I am open to discuss it and not completely against it. I will unlike sit and do nothing for a year so why would I want to get back to the Alpine drama instead of continue with the new thing I'm doing?Chloe Kudryavtsev <toast@toastin.space>You only have to take a break from being on base. Membership (or even adminship) of multiple teams is allowed. So you're not "leaving the project for a year", you just take a break from being "the ultimate authority" for a year. In short, everyone except you (and maybe Carlo) are currently in thatNatanael Copa <ncopa@alpinelinux.org>There is no guarantee that anyone gets re-elected.Chloe Kudryavtsev <toast@toastin.space>Ultimately, you have to trust the project to elect good people. Just like you have to trust the project to write good code.So after being forced to step down I could have the choice to continue do bug fixing, provide user support etc, but I would no longer have any responsibility of how the projects goes, nor need to deal with people drama and CoC violations, nor need to care about technical decisions. That would be someone elses problem.position, and I don't think saying that everyone except you "sit around and do nothing" is fair.Natanael Copa <ncopa@alpinelinux.org>Ofcourse not. What I meant was that this would be a great opportunity for me to start some new exciting project. If i did that. Why would I be interested in getting back into "base" and clean up whatever mess the last person has introduced?As such, surely you'll agree, that concern is a bit moot - after all, we don't expect people that haven't and aren't doing anything with the project to be elected into base, are we?Natanael Copa <ncopa@alpinelinux.org>The concern here is, do we want rotate out good people? Or do we want try keep them.Chloe Kudryavtsev <toast@toastin.space>We want to rotate people, period. People can change - someone could go from being good to being lessNatanael Copa <ncopa@alpinelinux.org>So we want rotate out the good people. > Of course we want to keep good people, So we don't want rotate out the good people.active, or even straight out bad. Suggesting kicking someone out of a powerful group like base shakes up the entire project - it is inherently a violent event, and is inevitable. Simply waiting a bit and not re-electing them is a peaceful resolution to such things: it is a self-correction mechanism. Of course we want to keep good people, but the process of selecting people should be through positive reinforcement (re-elect the good people!), rather than negatively selecting the bad ones.Natanael Copa <ncopa@alpinelinux.org>Maybe I was unclear. I was talking about the project as a whole. We don't elect our contributors. They join on their initiative.Chloe Kudryavtsev <toast@toastin.space>We indeed do not elect our contributors. The rotation stuff *only* applies to base. Kicking an admin out for misbehavior is not the same as trying to kickNatanael Copa <ncopa@alpinelinux.org>So my point here is that whatever happens in the leadership tend to propagate to the rest of an organization. If you want honesty in the organization, the leadership needs to be honest. If you want diversity in an organization, you start in the leadership board. If you want a peaceful organization you need to have a peaceful leadership board.Chloe Kudryavtsev <toast@toastin.space>This has actually not been something I've considered, and is a good point. > So lets flip this rotation of people thing around. > > In case that that would want to have forced rotation through the > organization, where we would want to replace people, regardless if they > are good or bad, then the logical step would be to implement forced > rotation in the "base" team. > > But if we want to keep the good people within the he organization, then > maybe forced rotation of "base" team is not the best approach. I mean, > it would not surprise me if losing good people in the rotation process > becomes a side-effect, a hidden cost. > > Is rotation worth the risk of losing good people? > > Maybe it is. > > But before you say that we will not lose anyone (we already lost at > least two over this) And herein lies the obvious problem (as per the above thing I hadn't considered). If it does play out that way (and, as you say, it seems like it is), the things I outlined definitely are not worth it. Being wrong is something I do on occasion, but I had hoped that it would be caught (and properly explored as it is now) earlier.So lets flip this rotation of people thing around. In case that that would want to have forced rotation through the organization, where we would want to replace people, regardless if they are good or bad, then the logical step would be to implement forced rotation in the "base" team. But if we want to keep the good people within the he organization, then maybe forced rotation of "base" team is not the best approach. I mean, it would not surprise me if losing good people in the rotation process becomes a side-effect, a hidden cost. Is rotation worth the risk of losing good people? Maybe it is. But before you say that we will not lose anyone (we already lost at least two over this), please imagine yourself in this situation: You create a small distro and spend 13 years to raise and maintain your baby. You see people come and people go. You see people stick in good times and bad times. Then the distro grows big. And a new person shows up and after 5 months he says: - We want Chloe to step down. Anyone can take over, just not Chloe. You respond: - Hum sure, why not, would be nice to let someone else deal with the people drama. I could be a part of a technical lead team instead, that would be nice. - No, no! We don't want any separate technical lead team at all. *We* want Chloe to step down. Period. But she may come back in a year. So to prove to everyone - including yourself - that you are not a power abuser, you do step down. But would you actually want to come back after that?Chloe Kudryavtsev <toast@toastin.space>As a note, I decided not to interject within this block, and simply talk about it as a whole afterwards. 1. It is clear that you took the idea of forced rotation personally. I see why that happened, and have been trying to avoid it through my statements. The idea is so: when you write general rules, you typically do not want to add specific exceptions (especially involving a single person). Perhaps this is an atypical case. I would certainly want (and expect) for you to be elected at every instance where you are available, and it was not my intent for you to take the proposal in this way. However, my intent is mostly irrelevant to the fact that it *has* happened. I would like you to know that I am deeply sorry and regretful that this is how that played out, and reaffirm that that was never my intent. 2. As I think I mentioned at the start, the "We" I was using was supposed to include you. It's quite clear at this point that I've misrepresented the de-facto desires (whatever they are based in), and regret that as well. > So to prove to everyone - including yourself - that you are not a power > abuser, you do step down. > > But would you actually want to come back after that 3. This outlines another failing of mine - I've clearly failed to (sufficiently) empathize with you. Your original wording of the problem seemed confusing and contradictory, but instead of trying to figure out the original intent, I had responded to the words. I hope to be better in this regard as well. > - No, no! We don't want any separate technical lead team at all.4. This is quite interesting; my perception was the opposite. I see Base as both the technical and community leads, but primarily the former (after all, most conflicts they'd be resolving would be of technical nature; I expected the community things to be less common). My objection was thus to not having an additional all-powerful entity that would then be the community leadership. If we consider Base the community leadership, the technical leadership would not actually need to be all-powerful (only the parent of everything but Base), and that could certainly be done. In short, 4 seems to have been a communication issue. Not really certain who's at fault in that one (nor that there necessarily need be someone specific at fault), but I've definitely been an active participant. --- In summary, the side effects (some of which had only been pointed now) of forced rotation probably are not worth the outlined advantages. It would be nice to come up with something else that gets us at least some of the advantages without said side-effects and controversy. Further, the approach I had taken (due to my lack of attentiveness, the source of which ultimately is not relevant to the result) has caused you to take the idea personally. I find this regrettable, and I am sorry that I wasn't good enough to catch and stop that earlier. As to the way forward, please refer to my other email (response to the call re: a working group). --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ----nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---out a base member. It's still quite the event, but it is not project-wide-devastation levels. As such, there is no need to rotate out admins (and definitely not regular members). --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ----nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---This is also why you cannot be re-elected immediately. When elections are coming up, the person about to end their term would have significant amounts of influence, and if they were bad they could use those to try to pressure people into re-electing them. Similarly, a good person that's about to end their term would be vulnerable to bad external actors pressuring people into not re-electing them (for instance, someone could go through everything you have ever said, and tried to dig up something embarrassing). Both of these types of events are unneeded strain on the project, and both are effectively eliminated by enforcing a one-year-break between being in power. If the worst scenario you're considering is someone ends up finding something they like doing better, I don't believe that to be bad. I would instead be glad for the person that found something they like doing even more :) (Note: same applies to any people that leave the project in general for such reasons - we should strive to be an amazing project to contribute to, rather than keeping people around because they have a sense of obligation, in my opinion. This is one of my long term goals as well, though one that's less seemingly distant.) --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ----nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ------ Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ----nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ------ Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
Ted
> On 2019-04-09 1:55 PM, Ted Trask wrote: > > There is a big difference between sharing the workload and giving up > > authority. My main objection is to the stipulation that a base team > > member cannot be reelected immediately. Not only is ncopa sharing > > authority with two others for the first three years, he would be > > forced to give up all authority in the fourth year. Or am I reading it > > wrong? > > You're interpreting it correctly, though I assume ncopa will continue to > serve his roles in teams other than base during that time. I think that > you should trust ncopa to back a governance model he believes will work, > even if it means he has to take a break every few years. He is far from > uninvolved in these discussions, I suggest you trust his judgement in > this matter. I initially did not have strong opinion on the rotation model but the more I think about it the less I like it.
I've also been unsure about forced rotation. Why don't we compromise and eliminate the restriction about serving consecutive terms?
Chloe Kudryavtsev <toast@toastin.space>You actually brought up one of the reason forced rotation has to exist in one of our talks previously. Allow me to quote myself with the relevant examples: On 4/11/2019, I wrote: > This is also why you cannot be re-elected immediately. > When elections are coming up, the person about to end their term would have significant amounts of influence, and if they were bad they could use those to try to pressure people into re-electing them. > Similarly, a good person that's about to end their term would be vulnerable to bad external actors pressuring people into not re-electing them (for instance, someone could go through everything you have ever said, and tried to dig up something embarrassing). > Both of these types of events are unneeded strain on the project, and both are effectively eliminated by enforcing a one-year-break between being in power. If we were to eliminate the restriction about serving consecutive terms, we would have to make sure we are prepared for well-known real scenarios like the above. I think forced rotation is an adequate method of preventing them inherently, and also gives the base member the opportunity to see the world from the position of everyone else - refreshing their perspective and enabling them to serve better. If we can come out with ways to have both of the above that is not forced rotation, I would be onboard, but I'm not really seeing any acceptable approach. Do you have one? :) --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
--- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
Copy & paste the following snippet into your terminal to import this patchset into git:
curl -s https://lists.alpinelinux.org/~alpine/devel/patches/768/mbox | git am -3Learn more about email & git
You have to establish what the teams are before you can establish how they are maintained --- modules/Teams/pages/index.adoc | 66 +++++++++++++++++----------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/modules/Teams/pages/index.adoc b/modules/Teams/pages/index.adoc index 667e915..9560dc3 100644 --- a/modules/Teams/pages/index.adoc +++ b/modules/Teams/pages/index.adoc @@ -24,6 +24,39 @@ Team Admins are marked in *bold* in official team listings. 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. ==== +== 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. + == Membership === Being a Member @@ -65,36 +98,3 @@ 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. ==== - -== 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. -- 2.21.0 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
It's important to firmly establish the authority of the base team. The guiding principles to which the base team holds itself are out-of-scope for this document and better served elsewhere. --- modules/Teams/pages/index.adoc | 28 ++++++++++++---------------- 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/modules/Teams/pages/index.adoc b/modules/Teams/pages/index.adoc index 9560dc3..f3cfe1d 100644 --- a/modules/Teams/pages/index.adoc +++ b/modules/Teams/pages/index.adoc @@ -26,13 +26,24 @@ There is no distinction between technical and non-technical team members. Both a == Team Structure +== The Base team + +The Base team has ownership over Alpine Linux and is the last authority in any decision-making. +For day-to-day operations, additional teams are established at the pleasure of the base team and given the authority necessary to conduct themselves. + +The Base team consists of 3 elected members, guaranteeing a quorum. +Members of this team serve 3 year terms, staggered such that one member steps down per year. +Each year, an election is held through a project-wide {votelink}[Vote]. +Members of the Base team cannot serve consecutive terms, but may be re-elected after a one year break. + === 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. +Further, team administrators must follow the policies of other teams when working in their domain. === Creating a New Team +The base team needn't be involved in establishing every team - the project as a whole is permitted to self-govern in this respect. 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. @@ -42,21 +53,6 @@ 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. - == Membership === Being a Member -- 2.21.0 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
Ted Trask <ttrask01@yahoo.com>--- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
Ted Trask <ttrask01@yahoo.com>Any scheme that would result in Natanael being removed from the base team after three years would not get my vote. As far as I am concerned, ncopa should be Alpine Linux’s Benevolent Dictator For Life. Completely serious. Ted