Decision making process RIOT community

Community
,
1

Here is my suggestion for a document on decision making in the RIOT community, based on the discussion during the general assembly. I have tried to write down the process as it is right now, combined with suggestions from my side (mark as suggestion). Please check the parts between brackets, as these are parts where additional information is needed.

START OF THE DOCUMENT

Decision making process RIOT OS

Decisions are made by rough consensus in the RIOT-OS community. A description of what rough consensus entails can be found here: RFC 7282 - On Consensus and Humming in the IETF.

Suggestion:

The roadmap, consisting of the vision and mission statement, provides guidance for decisions. New directions can be checked with this roadmap to see if they fit the future vision of RIOT-OS.

Institutes

[what I mean for the title: How are things done and who decides, but set in 1 word. Any suggestions?]

Contributing code: https://github.com/RIOT-OS/RIOT/blob/master/CONTRIBUTING.md#contributing-code

Virtual Maintainers Assembly Quarterly meeting of maintainers after every release. Here is discussed what happenend in last release, what will be done in the next release and who will manage the 2nd next release. Also other issues relevant for maintainers are discussed [and decided on??].

RIOT-OS Summit Yearly meeting face to face of community. General Assembly where bigger decisions and directions are discussed. Rough consensus as way of deciding. Convincing each other via (technical) arguments.

Roadmap Maintainers take lead in updating the roadmap. Discussed in Virtual Maintainers Meeting (VMA). Shared via [forum, other channels? Please add!] with the community, input from community is collected via same channels and during the Summit.

Suggestion:

Deadlock resolution

In some situations there is too much difference in views for a rough consensus to be reached. This may lead to the stalling of a (sub)project. To prevent this, those involved can initiate a deadlock resolution. A group of three persons who are relatively independent on this issue will be assembled to make a proposal for how to proceed. This is always a one-off group that is dismantled after the disagreement is resolved. When difficulties arise in choosing the members of this group, both parties will chose one person. A third, independent person will be chosen by rough consensus of both parties.

The code of conduct is to be kept in mind in these situations. Be respectful towards each other and respect the difference in opinion. Keep in mind that someone may perceive a situation very differently from you.

END OF THE DOCUMENT

Practical suggestion for using the roadmap as reference: can “I have checked the roadmap” be added as part of the pull request template? So that it is highlighted and praised when contributors add things in line with this roadmap.

2

Karin Lammers via RIOT notifications@riot-os.org wrote:

> Virtual Maintainers Assembly
> Quarterly meeting of maintainers after every release. Here is discussed
> what happenend in last release, what will be done in the next release
> and who will manage the 2nd next release. Also other issues relevant
> for maintainers are discussed [and decided on??].

Do these get posted somewhere?

I wouldn’t know where to look.

3

Yes, they are posted in the Maintainer category of this forum (which is only readable to maintainers). Maybe it makes sense to publish them after the VMA? What do you think @Maintainers?

4

Making public notes of closed meetings is generally a good idea. We should just communicate this to note takers who would previously make notes of personal details freely, and have a quick look over notes before moving them to the public forum. (I’m thinking mainly of things such as vacation times, and that’s more in the Friday meetings than in the VMAs; can’t recall any other kind of non-public information ever being discussed).

1 Like
5

I would very much like it if the maintainers category was world readable, then. It would also be good if one 20min session at the summit was devoted to reviewing the decisions.

1 Like
6

chrysn via RIOT notifications@riot-os.org wrote:

> Making public notes of closed meetings is generally a good idea. We
> should just communicate this to note takers who would previously make
> notes of personal details freely, and have a quick look over notes

Chatham House rules?

> before moving them to the public forum. (I'm thinking mainly of things
> such as vacation times, and that's more in the Friday meetings than in
> the VMAs; can't recall any other kind of non-public information ever
> being discussed).

Yeah. I don’t need know about your Tuesday plans to unify yourself with a stein of beer.

7

Maybe not the whole category, but the VMA notes would be manageable.

8

Good idea to have a session at the Summit! That gives a yearly check of the community. I will add it to the text.

9

I would suggest changing this into “A vision and mission document is updated every [two? five?] years. This is supported by a roadmap that is updated annually. The roadmap provides guidance for decisions.” Since a roadmap is a very practical document stating what to do, while a vision/mission statement provides the bigger picture of where to go.

Any further suggestions/reactions to the content of the document?

10

Updated version. I suggest to post it at GitHub - RIOT-OS/RIOT: RIOT - The friendly OS for IoT, just as the COC, README etc. References to the decision-making process can be redirected to that page.

Decision making process RIOT-OS

Decisions are made by rough consensus in the RIOT-OS community. A description of what rough consensus entails can be found here: RFC 7282 - On Consensus and Humming in the IETF.

A vision and mission document is updated every five years. This is supported by a roadmap that is updated annually. The roadmap provides guidance for decisions. New directions can be checked with this roadmap to see if they fit the future vision of RIOT-OS.

Institutes

Contribution to the code is as done in the manner described in the following link: https://github.com/RIOT-OS/RIOT/blob/master/CONTRIBUTING.md#contributing-code

Virtual Maintainers Assembly: quarterly meeting of maintainers after every release. Here is discussed what happenend in last release, what will b done in the next release and who will manage the 2nd next release. Also other issues relevant for maintainers are discussed and decided on.

RIOT-OS Summit: yearly face to face meeting of the community. The Summit includes a General Assembly, where bigger decisions and directions are discussed. Community members can convince each other via (technical) arguments; rough consensus is used as way of deciding. There is also a session dedicated to reviewing decisions made in the past year.

Vision and mission statement: document stating the vision and mission of RIOT-OS. Vision is what RIOT-OS wants to become and mission is how RIOT-OS is doing this.

Roadmap: practical implementation of vision and mission statement. Maintainers take lead in updating the roadmap. It is discussed during Virtual Maintainers Meeting (VMA) and shared with the community via the forum, website and GitHub. Input from the community is collected via the same channels and during the Summit.

Deadlock resolution

In some situations there is too much difference in views for a rough consensus to be reached. This may lead to the stalling of a (sub)project. To prevent this, those involved can initiate a deadlock resolution. A group of three persons who are relatively independent on this issue will be assembled to make a proposal for how to proceed. This is always a one-off group that is dismantled after the disagreement is resolved. When difficulties arise in choosing the members of this group, both parties will chose one person. A third, independent person will be chosen by rough consensus of both parties.

11

How are those people chosen?

The most common deadlock station though is that someone makes a proposal, but there is just nobody else interested in the topic (or maybe there would be a single person interested, but they are not very much involved in the project anymore).

If we find a way to assign 3 people to that case too, this would also help.

12

it is probably a sign if nobody is interested in a topic.

i don’t think that more details are necessary. we cannot force people.

13

Not nobody, just a single person.

14

Hi Ben!

On Thu, Oct 26, 2023 at 09:47:11AM +0000, Benjamin Valentin via RIOT wrote:

How are those people chosen?

I remember that at least one proposal was that both parties in the conflict could nominate people for this committee.

The most common deadlock station though is that someone makes a proposal, but there is just nobody else interested in the topic (or maybe there would be a single person interested, but they are not very much involved in the project anymore).

If there is only person involved we don’t have a deadlock (rather a starvation). The point here was more about discussions that stalls because of the inability to come to a consensus.

The problem you’re describing here is rather caused by missing person power or missing competencies. If really only one person is interested in the proposal there should be no need to pursue this topic in upstream RIOT anyway. But I guess that’s rather an exception.

Cheers Oleg

15

Thanks for your reactions!

Yes indeed. The current version of the deadlock resolution describes:

I suggest to change this into the default way of choosing the three people. This makes it clear how the one-off group is formed and avoids additional discussion. The quoted text above will then change to:

“The group will be composed as follows: both parties will chose one person. A third, independent person will be chosen by rough consensus of both parties.”

I would say that the person concerned should then approach three people him/herself to form a temporary group. What do you think about this, @benpicco?

and

If it is actually just one person interested, this will become apparent soon enough, as others will indeed not be interested in forming a deadlock-resolution group. So that resolves itself.

16

@mcr I made the two most recent VMA notes public now:

2 Likes
17

Thank you for posting these and making these public. It’s nice to have almost word-for-word stream-of-consciousness dump, but it might be too much. It’s hard to see what decisions were reached. It might be more useful for the VMA to co-edit a statement that summarises the tussle that is being worked on.

I wish I could contribute more.