The plan for elected positions

Committees Steering Committee
1

The plan for elected positions

You recently asked us if not changing how the roadmap talks about elections was an oversight. We discussed this and have some changes to the roadmap in response!

SIGs, committees and their nature

Until now, SIGs and committees have been “ad-hoc”, where anyone could join. In stage 3 of our roadmap, “Solidification”, we’ll change this to be more like the Kubernetes structure. In the Kubernetes structure, contributors to the project elect SIG members, and being a SIG member will be a much more trusted position than it is now.

SIGs will remain fully transparent so everyone can participate in areas they’re interested in, even if they’re not a member of the SIG. You can think of it as the SIG members becoming leaders in their domain. Some committees may have private communications but are encouraged to be as open as possible. An example could be the security committee, which may have private communications surrounding a not-publicly-disclosed vulnerability.

The voting

Addressing integrity concerns

By the time we start elections, we’ll have a loomio instance. Loomio will ensure integrity by avoiding issues like false accounts. Loomio can also help prevent underrepresentation by using algorithms such as Single Transferrable Vote.

A step-by-step walkthrough

When we get to the “implementation” stage on our roadmap (stage 2), we’ll elect Special Interest Group (SIG) leaders. We wanted to balance holding elections early with letting you learn about the position and who you’re voting for before asking members to stand or electing anyone. Group membership will remain by application, and we expect group leaders to continue accepting most or all applications as they do today.

In “Solidification” (stage 3), SIGs and committees will become fully formed groups. They’ll get more of a complete say in the direction of their domain, and group membership will be elected.

Finally, as we have a minimal implementation and enter “Polish” (stage 4), we’ll replace the “boot group” steering committee with elected members. We want to wait until Aux is at this “minimum-viable” stage because we want a consistent view as we progress through the “bootstrapping” phases of the roadmap. We also want to provide an example of typical steering committee activity, which can only properly begin as other SIGs and committees solidify.

We hope that the new steering committee will be able to provide a sustainable long-term view for Aux.

Many thanks to @minion for help with writing this up.

8 Likes
2

This sounds really positive. It would be great to use Loomio, when planning the evolving Roadmap, if it’s available.

Chris

2 Likes
3

Sorry if this sounds negative, it’s not intended. I’m just confused by the post, it has a few sections which I feel are not explicit enough to be understandable without making assumptions and/ or guesses.

I’m not sure I understand the difference here. From a first read (without having looked at the Kubernetes structure) it feels like those two sentences contradict each other.

Maybe it’s only a wording issue, would you mind elaborating?

I’m reading this as “each member is only allowed to vote once”, is that correct?
If so, is there a plan to enforce this technically?

Who is “we”?

This might tie back to my first question, is the idea to vote on every group member?
If so, how does this link into “everyone can participate in areas they’re interested in”?

4

This was also my original concern when writing so I consulted @minion. I hope she reads through my response.

“We” is referring to the Aux community.

So the idea is that anyone and everyone can contribute towards the SIG repos and communicate with SIG member. However, SIG members are now elected positions, where they should be recognised by others to manage and act as leaders their respective domain. Every group member will apply to a position such as joining SIG go and SIG Gnome, then if they meet the expected requirements, for some repos this may be 20 PRs merged for another this might be 50 each are set by their respective SIG. These members are expected to lead and head thier teams. Similar to nixpkgs anyone can open a PR but SIG members will operate similar to the nixpkgs committers that merge PRs and decide on the direction for the repo. Unlike the current structure where only members of the SIG work on their respective repos.

1 Like
5

The requirements would be set by the SIG/ committee themselves?

And one more clarifying question:
What do we expect to be the difference between SIG/ committee members and leaders?
The sentence above seems to mix “leadership” into the member role.

6

Yes. This is probably the most important part.

The SIG/ committee leaders should manage their teams and help coordinate all team members. This would heavily involve active community engagement whereas members is a less intense role. Some examples of community engagement maybe heading calls to discuss new plans and ideas, preparing new posts in the forum to keep people engaged and so on.

2 Likes
7

Thanks for the clarifications @isabel :+1:

1 Like