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.
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
> 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
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
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
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
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).
>> : 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
> 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
> 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
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
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.
Received on Fri Apr 19 2019 - 11:33:26 UTC