Subject: [alpine-devel] Stripping down the governance model proposal

From: Drew DeVault <[email-masked]>
Date: Mon, 15 Apr 2019 11:23:30 -0400

There is a general sense of dissatisfaction with the governance proposal
under discussion. It's too big and makes a lot of changes at once.

Simplified governance model:

1. The core team is stripped down to 3 trusted people.
2. The core team is generalized to "responsible for everything".
3. The core team delegates their responsibilities at their discretion.

Notes:

- The new core team would immediately grant everyone already in core the
  necessary abilities to do the jobs they already do.
- The core team can delegate delegation itself, for example to expand
  the leadership of aports.

Based on this simplified model, informal teams will materialize as
they're needed with minimal pomp & circumstance. The process for e.g.
joining aports as a committer to community, becomes informally
convincing the people who are responsible for giving people commit
access to aports to add you. The person making that call might want to
run it by the mailing list or the IRC channel for comments before
pulling the trigger. The process for establishing a Python team is just
getting a bunch of interested people together and doing the work. If
it's necessary to connect an ad-hoc team like that with resources, just
make the case to the person responsible for those resources.

Official externally-facing roles can be established at the pleasure of
the core team, as well. A security team, for example, can be established
less informally and have membership written down somewhere, with a
point-of-contact for the rest of the world.

This may be simple enough for bootstrapping purposes and ought to solve
the problems we set out to fix. As more complex procedures are shown to
be necessary over time, they can be added.

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Wed, 17 Apr 2019 19:24:22 -0400

> 3. The core team delegates their responsibilities at their discretion.

The concern here is that we'd just delay the problems a bit.
The problem is that virtually all decisions currently go through a 
single choke point.
Make that choke point bigger might help temporarily, but I have doubts 
as to the degree.

>    the leadership of aports.

The current system basically has the large core with all the powers and 
abilities.
In practice, the problems we have remain.
This usually means that there isn't enough "grease" in the system to 
move things along.
Formality (up to a certain point, past which it becomes red tape 
instead) usually is said "grease".

> pulling the trigger.

Again... this is basically the status quo, and it isn't really working 
out, with very few people disagreeing on that front.

> The process for establishing a Python team is just getting a bunch of interested people together and doing the work. If it's necessary to connect an ad-hoc team like that with resources, just make the case to the person responsible for those resources.
How well this works generally depends.
This worked out somewhat ok with docs, because there was a lot of 
motivation to help getting it started, and only one person (me) actually 
needed any access.
This didn't quite happen to the suggestion of said python team, though, 
which again suggests a lack of grease - more people = more things to do 
= greater initial resistance to get through.

> point-of-contact for the rest of the world.

There are currently informal themes (in an internal-only wiki).
However, due to lack of formality (or some other factors), not everyone 
on them is actually active.
Furthermore, the lists aren't up to date in the other direction too - 
some people are effectively on them, while not being on the list.
This ultimately defeats the purpose of having these lists around, and 
does not help with external facets.

> be necessary over time, they can be added.

This does not solve the problems we have set out to fix.
As a reminder, let me re-iterate them here:

1. All decision making has to be done by a small number of people, so 
things get done slowly, if at all.
This stays in place, the number of people goes up to 3, and that's about it.
Since we aren't improving the system in any other way relevant to this, 
there is no reason to expect this to suddenly change.

2. Motivated people can't make their way into a position of trust, and 
become demotivated.
Similarly, we are not changing the methods of getting into a position to 
do the work effectively.
There is no reason to expect this to change the situation.

3. There is no interface between alpine and the outside world.
As I mentioned, we currently have an internal-wiki with semi-unofficial 
listings, like what you propose.
They are not accurate.
There is no reason to assume that, without making things more official, 
they would be taken more seriously.
Having an inaccurate and buggy interface might be worse than the choke 
point, even.

4. People responsible for everything are unable to specialize.
This does nothing in that regard too.
It says that the new core would be able to delegate things, but they 
have that ability *now*, and it isn't happening very much.
There is no reason to assume this would change if we don't modify anything.

> under discussion. It's too big and makes a lot of changes at once.

The issue with the dissatisfaction is that it reduces the odds of 
passing it through.
If a proposal that fixes all the issues does not pass through, it fixes 
no issues.
This is the other end of the spectrum.
It is simple to make a proposal that passes, but actually fixes nothing.
However, if a proposal that fixes nothing passes, nothing was fixed.
These two scenarios are effectively identical.

I would prefer to fix as much as possible without dissatisfying the 
community, as opposed to enact minimal change with no effect.
If a specific thing doesn't fix something, while being intended to fix 
it, it should either be improved to have the desired effect or replaced 
with something that does.
This is not such a thing.

---

---

From: Allison Randal <[email-masked]>
Date: Thu, 18 Apr 2019 18:07:37 -0400

> These two scenarios are effectively identical.

There is a third possibility that's worse than those two: a proposal
that fixes a large number of issues passes, but is generally not
accepted by the community because they aren't comfortable with it. It
becomes official, but no one respects or abides by it, and you
effectively end up with no governance model at all, and a lot of
confusion and disruption to the project.

I can't say how likely that is to happen here, but it is definitely a
common risk when considering such substantial changes. So, it's worth
taking the time to carefully consider changes, make them incrementally,
and ensure that the currently active governance body always leads
changes to the governance model. Trust takes time.

Allison

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Thu, 18 Apr 2019 21:15:51 -0400

> confusion and disruption to the project.

That seems to be at least tangentially related to what happened to the 
previous interim policy - it never ended up being followed.
My hope is that through discussing this in a public and transparent way 
(rather than simply announcing "this is how it is now"), we can get 
community members that aren't comfortable with parts of the proposal to 
speak out, and for the debate to improve the proposal's state.
Considering the comments around the forced rotation stuff, it seems that 
my hopes of this happening are not completely in vain - which is good.

> changes to the governance model. Trust takes time.

I think having a concrete roadmap may be helpful.
Solve some issues at a time, but have a specific timeframe during which 
we plan to solve the other issues, along with a "current state of the 
discussion" for each planned iteration.

The concern with not solving all of the issues at once is that the 
"we'll solve this later" may never come.
One way of solving that (and thus effectively allowing for iterative 
approaches) is to follow SMART criteria[1], which would require a 
roadmap (the T component: Time-constrained).
This would also allow us to merge the less controversial parts of any 
proposal sooner, while giving much more discussion time and mindspace 
(since the less controversial stuff has already been merged) for any 
controversial components.

The potential problem of that approach is that we lose holistic cohesion.
However, the extent of that damage is not too far-reaching, I would 
think - most FOSS projects evolve iteratively anyway.

[1]: Doran, G. T. (1981). There’s a S.M.A.R.T. Way to Write Management’s 
Goals and Objectives. Management Review, 70, 35-36.

---

---

From: Allison Randal <[email-masked]>
Date: Fri, 19 Apr 2019 10:19:30 -0400

> my hopes of this happening are not completely in vain - which is good.

That public discussion is absolutely essential, yes. You'll also find
that having more people involved in creating the proposal in the first
place, will mean that far more people are comfortable with what's
proposed. Part of that is the simple practical effect that capturing the
perspectives of more people in the proposal will mean that it more
accurately reflects what the community wants and needs. But, part of it
is also a network effect of trust, where it's easier for the whole
community to trust a proposal if several people with a long history of
respect in the project were involved in drafting it, and are confidently
saying that they're comfortable with it.

> think - most FOSS projects evolve iteratively anyway.

The important thing to keep in mind is that the ultimate goal is to be
more effective as a project and community. From where we are today, we
can make some good guesses about what might be hindering effectiveness,
or what changes might improve things, but, we can't precisely predict
the effect any change will have, even a tiny one. That doesn't mean
projects should avoid change or be scared of it, but it does mean that
iterative changes are generally more successful, so that after each
change the whole community can look back, honestly assess what worked
and what didn't, and then decide what they want to change next.

Also keep in mind that there's no such thing as a perfect state, there
will always be things that can be improved. It's healthier to keep
evolving slowly and continuously, than to try to fix everything. You
never will fix *everything*, but you absolutely can get more and more
effective over time. Get into a habit of thinking that change is normal,
instead of putting it off until it's a big pile of messy things you want
to change all at once. (This is actually pretty similar to code changes,
it's generally better to make small patches iteratively, than to land a
massive ugly patch all at once.)

A roadmap can be helpful, but keep it as a living document, and modify
it over time as you learn from what worked. For example, you had a good
list of issues earlier in this email thread, which could serve as a
starting point of "things we want to work on in the next few years", and
everyone could add their own additional points to the list. Then,
everyone could talk about the list, and identify which things on the
list are the greatest obstacles right now. Then talk about one practical
change that would improve the greatest obstacle. Make the change, give
it time to settle in, then reflect on how it went. You might end up
refining the change a bit, to smooth out rough edges or address corner
cases that no one saw in advance. Once everyone is comfortable with the
one change and confident that it has made the project and community more
effective, go back to the roadmap list, and start talking about
practical changes to address the second greatest obstacle. This isn't a
rigid process, it's a dynamic living process, with flexibility to adapt
to the needs of the project. So, you might do two changes at a time, or
start one when another is only part-way finished, or revert a change if
it works poorly, or add new issues to the roadmap list, or remove issues
that become irrelevant because some other change worked better than
expected.

> Goals and Objectives. Management Review, 70, 35-36.

If you're interested in that side of things (not everyone is), I highly
recommend:

Reynolds, M. & Holwell, S. (2010) Systems Approaches to Managing Change:
A Practical Guide. Springer.

I can also share some papers with you, writeups that I did applying the
concepts of traditional management theory to open source projects. The
ideas are not a perfect match, but there's a lot that open source
projects can learn from that field, as long as we take it as inspiration
and don't try to follow it too literally.

Allison

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Fri, 19 Apr 2019 11:33:26 -0400

> saying that they're comfortable with it.

Yes.
While basically everyone had been free to join in, and have all been 
taken seriously (with multiple examples to show), it seems the 
perception was still that I was "alone" in making it.
As such the Working Group thing doesn't change very much on my side 
(which was already open to discussion for the reasons you outline), but 
lends additional legitimacy to everything.

> and what didn't, and then decide what they want to change next.

This seems reasonable.
The main ask I'd have is that each of those iterative steps actually 
does something to fix a given issue (as opposed to the root of this 
discussion).

> massive ugly patch all at once.)

++
The issue is that (from my perspective), we've already got a big pile of 
messy things, so having a massive ugly patch to bring it up to 
sanitation standards past which an iterative approach is easier to 
perform is... tempting.
I see the point, though.
I believe it is possible to discuss both possibilities and weighing the 
pros and cons (the ones we can predict, at least).

> that become irrelevant because some other change worked better than

If I at any point implied that the roadmap would be fixed in stone, do 
forgive me - that was not my intent.
The roadmap should always reflect the current understanding of the 
situation.
The only component I would be skeptical of changing (at least often) 
would be the expected time-constraint of the next step.
I'd probably be comfortable with the "measure-do" approach: the first 
"deadline" is a guess; if it needs to be changed, it's fine, but the 
expectation is that through figuring out that it needs to be changed you 
also figure out a more reasonable one that should then stick.

Regarding the list, I didn't compose it by myself or anything.
This is a list of issues that came out of a talk in IRC, during which 
several people (including myself) attempted to analyze what problems 
were hurting efficiency, to come up with a concrete list of issues to 
resolve.
I'm okay with adding more points on to it, but unless those points are 
directly related to the general results that we wish to change, I'd like 
that to happen after the current list is resolved (as I think the 
current problem set is of a higher priority than, say, "the CoC is 
weird" (it is)).

I would prefer keeping the roadmap document more complete.
I.e we should have a list of practical changes that we believe will, in 
combination, resolve all issues, while each change helps resolve at 
least one.
This obviously would not be set in stone, and be updated every time a 
change's effects have become obvious.
However, this means that we have an innate advantage of being able to 
keep the goal ahead of us, rather than start discussing semantics (e.g 
the "Core"/"Base"/Other discussion that keeps creeping back up).

Otherwise, ++.

> A Practical Guide. Springer.

Will take a look.
For reference though, my background is more philosophical.
Rather than "learning about X", I "learned to learn".
As such, I tend to appreciate well-formulated meritorious ideas, rather 
than particularly lengthy papers that continually attempt to lower the 
abstraction level and raise referentiality.

Not saying this paper is an example of that, just making sure that's out 
there, since I've had previous instances of people being confused in 
that regard.

> and don't try to follow it too literally.

Considering your actual experience in the field, I'm relatively certain 
that your writeups would not have the potential issues I outlined above.
As such, I would be glad to read them, if you wish to share. :)

====

In summary, and correct me if I'm wrong, the way forward is such:

1. Refine the list of issues we are attempting to solve, while keeping 
it focused on the issues the working group wishes to solve (this 
approach can be re-used later, but by the community as a whole).
2. Think of a set of practical changes that, in combination, solve all 
of them.
3. Group them into sets, such that each set solves one specific issue. 
(minimal set size = 1)
4. Decide on a priority list for the sets, from most important to least 
important.
5. Establish a roadmap, with estimated dates and the expected changes 
for each date.
Give enough time between each change for discussion.
Expect that changes and dates will change, but attempt to limit the 
changes to the dates in order to remain time-constrained.
6. Enter an iterative process where we discuss the next change, improve 
it if needed, and at the deadline, either push it back (with the new 
knowledge of exactly how long it'll take) or implement it.
Then, during the next phase, observe the effects, and either push the 
whole stack back, inserting an entry to refine the change in question, 
or move on to the next point if the results of the change are satisfactory.
Note: all of this (6) should effectively be done in parallel.

---

---

From: Allison Randal <[email-masked]>
Date: Fri, 19 Apr 2019 13:07:46 -0400

> does something to fix a given issue (as opposed to the root of this

Yes, from what I can tell, everyone agrees about not making pointless
changes just for the sake of change. Any change needs to be grounded as
a practical step to help the project be more effective.

> also figure out a more reasonable one that should then stick.

I was probably mostly reacting to the SMART reference, since it's an
approach that tends to be more rigid.

It's fine to add dates if people find them helpful, just remember that
the dates are unlikely to ever be accurate. In the end, when you do a
specific thing isn't as important as just continuing to move forward.

> were hurting efficiency, to come up with a concrete list of issues to

Nod, I didn't mean you invented it all on your own, only that another
person summarizing the same conversations you have all had together,
might add some different points, or emphasize different points as higher
priorities.

> current problem set is of a higher priority than, say, "the CoC is

One point I didn't see mentioned clearly, which I have experienced
repeatedly in other projects both as a project member and as the project
leader: you all are putting an enormous burden on one person (Natanael),
and you're going to burn him out if you don't find a way to share that
burden across multiple people, and allow him some way to take a year off
sometimes. The risk of burn out is kind of implicit behind all the
points, but it's helpful to say it explicitly, and really focus on what
that means for the project. It is really tempting to think that what you
have now works well enough that no change is needed at all, but putting
that much stress on one person guarantees you will change at some point,
whether you do it as carefully planned change over time, or it's forced
on you all at once when the founder gets sick, has their time taken up
by other things in life, or decides to retire from the project. In my
experience, it's far better to start making small changes to share the
load early on, so everything is settled and working by the time you
actually need to give the founder a vacation.

> change's effects have become obvious.

What would seem like the most natural place for this community to keep a
document like this? In a git repo? On a wiki? It doesn't need to be a
massively detailed document, a list of bullet points would be sufficient.

> the "Core"/"Base"/Other discussion that keeps creeping back up).

I have the impression that there's more than semantics to this question
of whether the current core continues or is replaced by something
entirely different. It's worth taking the time to understand these kinds
of objections.

> abstraction level and raise referentiality.

That reference is an entire book, so may be a bit much. I have a
tendency to dive in to every new topic with great gusto, whether it's
community management, software, hardware, or more random things like
quantum mechanics and astrophysics. But, I totally know that my own
style of self-teaching isn't right for everyone.

> As such, I would be glad to read them, if you wish to share. :)

Most of my writeups are very practical, looking back on why some thing
or another went badly wrong, and how it could have been improved. I'll
send you one about the death of another Linux distro community. It was
struggling through a completely different set of problems than Alpine,
but I think it's helpful to see how fragile these communities can be,
and why caution and inclusive collaboration is so important in any change.

> Note: all of this (6) should effectively be done in parallel.

Something like that, yes. I suggest stepping back to just focus on #1
for now, and working on the list in some shared space where this
community already has a habit of collaborating. I've seen one community
do quite well keeping this kind of thing in a git repo named
"governance". You could start by capturing the existing governance
structure as files in that repo, instead of just historical posts on the
mailing list. A wiki or etherpad could work just as well as a git repo,
as long as it's public and everyone can contribute.

Allison

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Fri, 19 Apr 2019 14:44:00 -0400

> specific thing isn't as important as just continuing to move forward.

The goal of time-constraints is to make sure "moving forward" is happening.
Progress on things stalling is one of the issues we're trying to solve, 
after all.
Solving stalling by stalling the process of solving the stalling is not 
particularly effective - which is what the deadline idea's about.

> might add some different points, or emphasize different points as higher

Okay.
The current list is actually as-written by Drew Devault.
I do mostly agree with it, and am fine with it being rewritten a few 
times to figure out the diffs and discuss those.

> that means for the project.

Yes.
This is in fact the primary motivator for Natanael.
I have additional ones (as per the list, which I agree with).
I do believe that this point has been stated explicitly on IRC several 
times, but it makes sense to point it out in email too.

> It is really tempting to think that what you

Hopefully it's sufficiently clear by now that I'm quite strongly against 
the viewpoint you're outlining here. :)

> massively detailed document, a list of bullet points would be sufficient.

I'm working on Alpine's documentation and the de-facto governance state 
would be on docs.a.o (currently beta.docs.a.o).
I initially put it in the developers handbook (which is being blocked by 
this being resolved), but it may make sense to actually throw it 
elsewhere (for now, or even in perpetuity).

> entirely different. It's worth taking the time to understand these kinds

As a summary of current arguments (in context of the current proposal; I 
think I mentioned it previously, but you can see it over at [1]).

- Using "Core" is inherently confusing: we are separating it out into 
two separate entities.
Calling either one "Core" will inherently give existing developers false 
ideas as to what that entity is.
- "Base" is not particularly descriptive.
I took it directly out of Gentoo, and it makes sense in some angles (i.e 
the "Base" of the Team "tree"), but it's caused enough confusion that a 
better name may be warranted.

> style of self-teaching isn't right for everyone.

I'm aware: by the time I sent this in I had already acquired what I 
believe to be a pdf-formatted copy thereof (of course, being wrong is a 
thing, but I'll have to look at that later anyway).

I do indeed have a tendency to "throw myself" into things, which is 
further compounded by how my brain functions.
It might take a bit before I actually throw myself into it, thus the 
comment.

> as long as it's public and everyone can contribute.

As mentioned, [1] exists, but I'm not sure that's an appropriate place 
for the list.
Would have to think about where to keep it.
I think Kevin is supposed to be leading the working group now, so I'll 
CC him for this purpose as well.

Regarding capturing the existing governance structure, it gets a bit 
complicated.
We have an interim policy ([2], [3]), but it isn't really followed in 
practice.
In practice, nothing is really defined very well, so consolidating it 
into text is... challenging.

[1]: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/
[2]: https://lists.alpinelinux.org/alpine-devel/6024.html
[3]: https://lists.alpinelinux.org/alpine-devel/6025.html

Note on [1]: current UI requires JavaScript for navigation. Writing a UI 
that doesn't from scratch to appropriately match the rest of Alpine's 
web presence is on the TODO list.

---

---

From: Allison Randal <[email-masked]>
Date: Fri, 19 Apr 2019 15:15:25 -0400

> the viewpoint you're outlining here. :)

Yup, understood. To be clear, I'm not advocating for any one alternative
way of going about this, my goal here is just to help facilitate the
community finding a path to change that works. The path that you
personally prefer may not be the best one for the community overall. I
think we can at least agree that the response you've gotten so far isn't
what you hoped for.

> better name may be warranted.

Core at least has the advantage of already having an established meaning
in the community, so people can talk about changing that meaning in a
coherent and rational way. Starting over with something completely
different is much more difficult.

I don't personally have any attachment to the word Core, so I'm really
only advocating for holding the focus on changes that make the project
and community more effective. The name change may be more distracting
than helpful.

> CC him for this purpose as well.

Nod, I reviewed the developer handbook (0.1a), but it does seem pretty
tightly integrated with accepting the current proposal in its entirety.
So, agreed that it seems sensible to keep the handbook separate from the
list of things to consider working on.

> into text is... challenging.

Right, I wouldn't invest effort in cleaning up that interim policy, I'd
just commit those email messages exactly as they are as a file in the
repository (or page on a wiki, etc). That way, it is very clear to
everyone what we have now (not much), and what exactly is changing.

Allison

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Fri, 19 Apr 2019 15:44:06 -0400

> think we can at least agree that the response you've gotten so far isn't

I had hoped that I (with the help of comments from well-established 
members, as well as the community at large) would be good enough to 
figure out a solution that pleases most, and does not significantly 
impede the rest.
This obviously had not happened.
In terms of the response, my hopes were for one that results in 
improvement for the project.
Whether or not the response lives up to my hopes is yet to be seen.

> and community more effective. The name change may be more distracting

At this point I think the onus should be on me.
Since I can't think of anything better than "Base", perhaps "Core" 
should indeed be the way to go.
Still, this should be relegated to the roadmap (though I'd imagine it 
will end up being the first point) and discussed anyway.
However, unless someone has a better idea, I'm willing to go with 
"Core". (though again, I would very much like a better idea)

> list of things to consider working on.

Yes, I've effectively been using it to document the state of the proposal.
I think we can continue using it as such (for future parts/components of 
anything we end up with).
This way once we are fully done, the final state will be in sync.

> everyone what we have now (not much), and what exactly is changing.

That sounds reasonable.
That document can also be used for keeping/refining the list of issues, 
as well as the roadmap.

I initialized a wiki page[1] to serve this purpose.
Whether we end up using it or not for the other points remains to be seen.

[1]: https://wiki.alpinelinux.org/wiki/Governance

---

---

From: Consus <[email-masked]>
Date: Fri, 19 Apr 2019 10:46:30 +0300

> previous interim policy - it never ended up being followed.

I don't have a say on this topic, but there is a possibility that no one
followed it because there is no real need in at this moment.

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Fri, 19 Apr 2019 11:13:53 -0400

> followed it because there is no real need in at this moment.

Most members (and contributors) I've spoken to all agree that there are 
some significant problems that need addressing.
These problems aren't really new either (see above in the thread - the 
bullet point list is actually something that was worked on and agreed by 
multiple people).

One way of potentially seeing it is that the interim policy did not do 
enough to actually solve the problems, and thus it wasn't followed.
However, this seems unlikely to me.
The policy was effectively posted "as-is" to the ML by a developer (who 
has now left), and there didn't seem to have been much discussion on it.
Further, being only present on the ML, it ended up being buried under, 
well, everything else, and hard to even know about for new contributors.

I'm trying to avoid both of these by inviting literally anyone with 
something to say about it to have their say, and by (once ratified) 
having a living document in docs.a.o (currently beta.docs.a.o) that 
keeps it in an easily accessible place.

In short, "there is no real need in[sic] at this moment" doesn't really 
seem accurate to me.

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 22 Apr 2019 22:38:12 +0200

Hi,

On Mon, 15 Apr 2019 11:23:30 -0400

> 3. The core team delegates their responsibilities at their discretion.

I think this may be a good starting point. We should try start as
simple as possible.

We now have:
- The current original docs[1][2] describing the (approximately)
  current state.

- The proposal written and submitted by Chloe[3] (which was based on
  feedback on IRC)
 
- Drew's simplified governance model here above.

I'd also like to share some of my thoughts on this. First, I am
thankful for the trust the community is showing me. But I don't want
become a bottleneck or single point of failure. I want have the
possibility to take a break or vacation without the project collapsing.
Not because I want to leave, but knowing that I *can* would make things
less stressful for me.

So I definitively like the idea of a trusted group of 3. Lets call it
the "council" for now.

The council would have the responsibility for the Alpine project goals,
the guiding principles, the code of conduct, the governance rules, how
decisions are made within the project. They would also be the people
that help resolving conflicts. The council would delegate the technical
responsibility to a technical board.

The technical board would have the final say on technical decisions,
and have the responsibility to coordinate the different teams
(packagers/maintainers, infra, docs, release engineering etc). They
would not deal with conflicts or other people issues.

That way we could have non-technical people in the council, people with
great people skills and great organizational skills. And we could have
people with great technical skills in the technical board.

I think we could start with letting all current core team members be a
part of both the "council" and the "technical board", and then ask who
may be interested in be in only one of those, or maybe none. Some may
be perfectly happy with just continue maintain their packages.

I still think we should have some documented procedure on how to become
a member of either of the council or the technical board, and how to
expel someone misbehaving, not complying with the code of conduct. We
could probably reuse some of the current procedures.

Now, this was only some thoughts and I think our working group (Kevin,
Allison, Richard and Chloe) should look at this and try extract
the best parts of what we have got so far. Maybe they could work out a
simple, but more specific proposal, maybe even with some options or
alternatives?

-nc

[1]: https://lists.alpinelinux.org/alpine-devel/6024.html
[2]: https://lists.alpinelinux.org/alpine-devel/6025.html
[3]: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Teams/index.html

---