Toward RFC for Guix?

watching “Why wasn't I consulted“

Today, Guix is growing and that’s awesome! As most projects, paraphrasing Wikipedia,

early contributors tend to make all decisions, big and small, without a formal process or feedback from others. Decisions are often made in “crisis mode“, with little forward planning. IRC #guix channel are held generally to rally the troops, get status reports, and assign tasks. There is little meaningful strategic development, or shared executive agreement on objectives with limited or a complete lack of coherent roadmap. Typically, there is little organizational infrastructure in place, and what is there is not used correctly.

And nothing is wrong here, obviously not! Volunteering and motivation are not fungible. All the question is how to better scale? How to strengthen decisions? How to embark more people? How can I gauge my expectations compared to project norms?

Years ago, I watched “Why wasn't I consulted“ or How Rust does OSS. Today, I have just watched it again. Since the talk is worth, here I am extracting some ideas for easing some future references. From my point of view, these ideas help in drawing a path forward for improving Guix current process.

Some patterns

Alice: This change renames foo to bar.
Bob: When did this call get made? The commit that updated the guidelines was authored by you, Alice, and had zero citations about the decision.
Alice: The decision was made during a random chat on #guix last night, and took into account of all of the feedback…

Hum, 🔥.

Alice: There has been a lot of discussion about foo. I’ve been reading some of these threads around and I merged something about foo.
Bob: Some considerations aren’t adequately integrated with your patch.
Alice: We already had a lot of discussion, let move forward now.

Hum, 🔥.

Somehow, the classic:

“Why wasn’t I consulted” is the fundamental question of the web. It is the rule from which other rules are derived. Humans have a fundamental need to be consulted, engaged, to exercise their knowledge (and thus power), and no other medium that came before has been able to tap into that as effectively.

Consultation should mean

All “major” decisions are preceded by a RFC
Goal: catalog tradeoffs and explore designs
Teams drives to steady state and consensus
Final Comment Period
No New Rationale: decisions rest on prior, public debate

“Lazy Consensus” means

More or less the current Guix process.

Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. You don't have to insist people discuss and/or approve your plan, and you certainly don't need to call a vote to get approval. You just assume you have the community's support unless someone says otherwise.

or for more details, see Apache decision making:

Everyone is equal,
all project participants with an opinion can express that opinion,
and, where appropriate, have the community consider it.
Consensus does not mean that everyone agrees on all details,
it means that the project, as a whole, has arrived a decision that everyone can live with.
Lazy consensus means that you don’t need to get explicit approval to proceed,
but you need to be prepared to listen if someone objects.
Silence indicates consent, and after that time has passed, you can assume that nobody objects, and proceed with your plan.
Objections to the plan should be accompanied by a legitimate reason, and be open to discussing possible alternative approaches.

Potential current Community rants

Why does anything have higher priority than Feature-Request?
Why is Feature-Request not a top priority for the community?
As professional of Something, I am afraid that most all of these goals are not very interesting.
Community feedback is very important but we also should remember what Henry Ford said: “If I had asked people what they wanted, they would have said faster horses.”

Hum, 🔥.

How to build altogether a roadmap?

Taking into account that,

Every good work of software starts by scratching a developer’s personal itch.

let articulate the Vision:

“Thought Leadership”: leaders need to expose a way of thinking
Inspire the community toward a clear goal
Establish shared values
Identify and explain historical themes
Show me the code

Slogans

Stability without stagnation
Hack without fear
Fast, reliable, productive – pick three!

Toward Roadmap process

Vision on a yearly cadence:

Vision and values happen at many scales
Roadmap helps people “itch” in the same way …
… and also makes it easier to say “no”
RFCs even for roadmap

The Role of Pluralism

Many perspectives; one vision.

Not everyone will share all values; that’s OK
Not everyone will interpret values the same way; that’s OK too
Making room for a diversity of values makes for a better product
Project leaders must turn this input into a singular, coherent vision

Problem of Scale

Victim of success?

Threads can get many insightful comments
Information overload: there’s so much out there that no one can find anything
Never enough “managers”

An answer: Maintainer vs. Community,

The solution to sustainability s to build processes that can grow contributors and maintainers at the same rate of the project is being adopted.

The Three Lessons

Eagerly seek input and consensus
Lead by articulating the Vision
Think about the path to leadership
- it’s not just about code (see How to help maintainers?)

Opinionated closing. Guix community is moving in the right direction, in my humble opinion. For instance, patch#66430 clarifies what consensus means. Or patch#66436 provides some guidelines for sharing reviewing standards. Well, I hope that more in this area is coming…