For discussion of Alpine Linux development and developer support

12 4

[alpine-devel] Stripping down the governance model proposal

Details
Message ID
<20190415152330.GG1179@homura.localdomain>
Sender timestamp
1555341810
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chloe Kudryavtsev
Details
Message ID
<c5146728-ebc1-f90b-4333-6871c4402c6d@toastin.space>
In-Reply-To
<20190415152330.GG1179@homura.localdomain> (view parent)
Sender timestamp
1555543462
DKIM signature
missing
Download raw message
On 4/15/2019 11:23 AM, Drew DeVault wrote:
> 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.

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.

> 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.

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".

> 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.

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.

> 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.

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.

> 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.

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.

As a summary, I think a response to your opening statement is appropriate:

> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Allison Randal
Details
Message ID
<0fdde07c-b505-fb2a-cff2-bba494c781e3@lohutok.net>
In-Reply-To
<c5146728-ebc1-f90b-4333-6871c4402c6d@toastin.space> (view parent)
Sender timestamp
1555625257
DKIM signature
missing
Download raw message
On 4/17/19 7:24 PM, Chloe Kudryavtsev wrote:
> On 4/15/2019 11:23 AM, Drew DeVault wrote:
> 
>> 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.
> 
> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chloe Kudryavtsev
Details
Message ID
<0712b237-864e-5304-f4e3-695d0a5207c6@toastin.space>
In-Reply-To
<0fdde07c-b505-fb2a-cff2-bba494c781e3@lohutok.net> (view parent)
Sender timestamp
1555636551
DKIM signature
missing
Download raw message
On 4/18/2019 6:07 PM, Allison Randal wrote:
> 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.

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.

> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Allison Randal
Details
Message ID
<a6e5bd2d-bfd1-f04d-359e-604439287105@lohutok.net>
In-Reply-To
<0712b237-864e-5304-f4e3-695d0a5207c6@toastin.space> (view parent)
Sender timestamp
1555683570
DKIM signature
missing
Download raw message
On 4/18/19 9:15 PM, Chloe Kudryavtsev wrote:
> 
> 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.

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.

> 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.

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.


> [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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Consus
Details
Message ID
<20190419074630.GA2636@eddy.kbs.local>
In-Reply-To
<0712b237-864e-5304-f4e3-695d0a5207c6@toastin.space> (view parent)
Sender timestamp
1555659990
DKIM signature
missing
Download raw message
On 21:15 Thu 18 Apr, Chloe Kudryavtsev wrote:
> On 4/18/2019 6:07 PM, Allison Randal wrote:
> > 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.
> 
> That seems to be at least tangentially related to what happened to the
> 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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chloe Kudryavtsev
Details
Message ID
<e8b33e85-ce2a-ecf9-4182-a6b1eda5bb06@toastin.space>
In-Reply-To
<20190419074630.GA2636@eddy.kbs.local> (view parent)
Sender timestamp
1555686833
DKIM signature
missing
Download raw message
On 4/19/2019 3:46 AM, Consus wrote:
> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chloe Kudryavtsev
Details
Message ID
<8fd994e4-2c1e-4507-9776-245acac44eab@toastin.space>
In-Reply-To
<a6e5bd2d-bfd1-f04d-359e-604439287105@lohutok.net> (view parent)
Sender timestamp
1555688006
DKIM signature
missing
Download raw message
On 4/19/2019 10:19 AM, Allison Randal wrote:
> On 4/18/19 9:15 PM, Chloe Kudryavtsev wrote:
>>
>> 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.
> 
> 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.

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.

> 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.

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).

> 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.)

++
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).

> 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.

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, ++.

> 
>> [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.
> 
> 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.

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.

> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Allison Randal
Details
Message ID
<2d40a15c-5be4-94ce-46ac-cdec4347ff53@lohutok.net>
In-Reply-To
<8fd994e4-2c1e-4507-9776-245acac44eab@toastin.space> (view parent)
Sender timestamp
1555693666
DKIM signature
missing
Download raw message
On 4/19/19 11:33 AM, Chloe Kudryavtsev wrote:
> 
> 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).

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.

> 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.

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.

> 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.

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.

> 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)).

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.

> 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.

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.

> 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).

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.

> 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.

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.

> 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. :)

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.


> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chloe Kudryavtsev
Details
Message ID
<7e9005e0-307f-9b25-49b0-55e8700b2d01@toastin.space>
In-Reply-To
<2d40a15c-5be4-94ce-46ac-cdec4347ff53@lohutok.net> (view parent)
Sender timestamp
1555699440
DKIM signature
missing
Download raw message
On 4/19/2019 1:07 PM, Allison Randal wrote:
> 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.

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.

> 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.

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.

> 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.

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
> 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.

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

>> 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.
> 
> 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.

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).

>> 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).
> 
> 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.

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.

> 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.

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.

> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Allison Randal
Details
Message ID
<be4c0c3c-7e00-a230-8462-cc0aeafd0a56@lohutok.net>
In-Reply-To
<7e9005e0-307f-9b25-49b0-55e8700b2d01@toastin.space> (view parent)
Sender timestamp
1555701325
DKIM signature
missing
Download raw message
On 4/19/19 2:44 PM, Chloe Kudryavtsev wrote:
> 
> Hopefully it's sufficiently clear by now that I'm quite strongly against
> 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.

> 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.

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.

> 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.

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.


> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chloe Kudryavtsev
Details
Message ID
<d639ae97-b7d7-69d7-0da2-fc765af8af42@toastin.space>
In-Reply-To
<be4c0c3c-7e00-a230-8462-cc0aeafd0a56@lohutok.net> (view parent)
Sender timestamp
1555703046
DKIM signature
missing
Download raw message
On 4/19/2019 3:15 PM, Allison Randal wrote:
> On 4/19/19 2:44 PM, Chloe Kudryavtsev wrote:
>> Hopefully it's sufficiently clear by now that I'm quite strongly against
>> 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.

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.

>> 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.
> 
> 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.

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)

>> 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.
> 
> 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.

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.

>> 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.
> 
> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20190422223812.621f30d5@ncopa-desktop.copa.dup.pw>
In-Reply-To
<20190415152330.GG1179@homura.localdomain> (view parent)
Sender timestamp
1555965492
DKIM signature
missing
Download raw message
Hi,

On Mon, 15 Apr 2019 11:23:30 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> 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.

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




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---