Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GOVERNANCE.md: remove “Community Processes” in favor of “GOVERNANCE.md” #21067

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
226 changes: 226 additions & 0 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,226 @@
# Governance of the RIOT Community

The RIOT community is dedicated to creating a free and open source operating system for the constrained Internet of Things [[RFC7228], [draft-ietf-iotops-7228bis]] based on open standards.
This document explains the governance of the project.

<!-- TOC start -->
<!-- TOC start, TOC end comments are required to generate TOC in Doxygen properly -->
- [Values](#values)
- [Community Processes](#community-processes)
- [Roles](#roles)
+ [Contributors](#Contributors)
+ [Maintainers](#Maintainers)
+ [Release Managers](#Release-Managers)
+ [Admins](#Admins)
+ [GitHub Owners](#GitHub-Owners)
+ [Moderators](#Moderators)
- [Decision Making](#decision-making)
- [Meetings](#meetings)
- [Code of Conduct](#code-of-conduct)
- [Security Response Team](#security-response-team)
- [Modifying this Charter](#modifying-this-charter)
- [Attribution](#attribution)
<!-- TOC end -->

## Values

The RIOT community embraces the following values:

* **Openness:** Communication and decision-making happens in the open and is discoverable for future reference.
As much as possible, all discussions and work events eventually take place in public forums and open repositories.

* **Fairness:** All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits.

* **Community over Product or Company:** Sustaining and growing our community takes
priority over shipping code or sponsors' organizational goals.
Each contributor participates in the project as an individual.

* **Inclusivity:** We innovate through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment.

* **Participation:** Responsibilities within the project are earned through participation, and contributors can grow into more responsible positions.


## Community Processes
The community around RIOT gathers many IoT developers and users from around the world, from the industry, from academia, and hobbyists.
The RIOT community is open to everyone.
Our channels to communicate can be found in our [contributing guidelines].
The community self-organizes using the roles described below.


## Roles
### Contributors
Contributors are people who contribute their work to RIOT.
This includes,

- of course, code contributions, but also
- writing documentation,
- bug reports,
- other issue reports,
miri64 marked this conversation as resolved.
Show resolved Hide resolved
- reviewing PRs,
- participation in technical as well as non-technical discussions, or
- organizational considerations.

Code contributions are very welcome.
In order to streamline and harmonize code quality, contributors must follow the [contributing guidelines].

Contributors may be associated with organizations—by employment or otherwise—who have a vested interest in RIOT or may be individuals who have their own personal stakes in RIOT.
We call these organizations and individuals “stakeholders” throughout this document to summarize them.

### Maintainers

Among contributors, some have maintainer status, which consists in rights (write access to the [RIOT GitHub repository](https://github.com/RIOT-OS/RIOT/)) and duties.
The current maintainers can be found in the [maintainers list].

Maintainers are people who care about RIOT and want to help it grow and improve.
A maintainer is not just someone who can make changes, but someone who has demonstrated their ability to collaborate and organize with the team, get the most knowledgeable people to review code or documentation, contribute high-quality code or documentation, as well as follow through to fix issues (in code, tests, or tests).
More on maintaining RIOT can be found in the [maintaining guidelines].

We are constantly looking for more maintainers.
So if you are up for that, please start (or continue) contributing code and reviews!

To contact maintainers, the best is to interact over actual RIOT code on [GitHub](https://github.com/RIOT-OS/RIOT/pulls).

#### Becoming a Maintainer

Maintainers can propose to give maintainer status to contributors that have been noticed as particularly active in some domain of RIOT.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question from my side: can a contributor also actively ask for becoming maintainer? This would make it less of a 'waiting until someone may ask me' and gives some responsibility to a contributor too.

If yes: can there be an addition to the text, stating this possibility and a description of how to do that (how to reach out, to whom etc)?
If no: than don't add :).

(I would advice to describe here how the procedure currently is, so if the procedure is someone is being asked only, than keep it this way. If it has happened before that people reach out by themselves and that is desirable, than change it)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the past it was very obvious in their behavior if a contributor intended to be a maintainer (reviewing PRs even without the rights to merge and writing issues), but in general there is no precedence of a would-be maintainer outright asking. So I'd say let's keep it as is, but I will put this in my forum summary of the current state of discussion.

The decision to grant this status is then taken via consensus among the maintainers.
If there is consensus on granting the status to a particular contributor, a maintainer will personally contact this contributor with the proposal, which the contributor can then accept (or turn down).

Maintainers who are selected will be

- invited to the [maintainers GitHub team] by one of the admins of the RIOT project, which grants them the necessary GitHub rights,
- invited to the maintainer forum group by the forum moderators, which will give them access to the (private) maintainer part of the forum, and
- invited to the RIOT-maintainer chat room by one of the moderators of that room, for more informal exchanges between maintainers.

#### Removing a Maintainer

Maintainers may resign at any time if they feel that they will not be able to
continue fulfilling their project duties.

Maintainers may also be removed after being inactive, upon failure to fulfill their
Maintainer responsibilities, because of violating the Code of Conduct, or for other reasons.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is decided what 'failure to fulfill their Maintainer responsibilities' or 'for other reasons' is and thus when someone should be removed as maintainer?

Answering this question (and adding something in this text) is relevant if this is a point where a healthy working process can get stuck (e.g., not getting to an agreement whether a maintainer should be removed or not, resulting in nothing happening and more of these situations can occur in the future).

If this is not expected to become an issue, no additions to this text are needed. (referencing to my general 'describe the process steps when it prevents big problems, otherwise a general description is ok').

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't expect this to become an issue. But maybe others do?

Inactivity is defined as a period of very low or no activity in the project.
A yearly maintainer ping, an e-mail sent to inactive maintainers, determines if the maintainer is still willing to fulfill their project duties.
On failure to reply to the maintainer ping within the specified amount of time (usually a month), the maintainer will be removed.

### Release Managers

Release managers make sure the quarterly release comes out in time.
They are one or more maintainers which were appointed for a specific release by the Virtual Maintainer Assembly (VMA).
Their duties include setting the dates for feature freeze for the release, enforcing the feature freeze, coordinating the (mostly automated) tests of a release, writing the release notes and creating the tags defining the release and its release candidates.
The full set of tasks can be found in the document [Managing a Release].
Their duties end once the release is out or if all bug-fixing point releases are out.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quoting from #21067 (comment) as this is somewhat lost in truncation.

also, this is a bit unclear. How do we know that "all bug-fixing point releases are out"? Just before starting a new (soft/hard) feature freeze for the next release ?

I think that is something we need to decide on. Because I don't know an answer to your questions.


### Admins

GitHub admins are a special subgroup among RIOT maintainers.
They are marked as such in the [maintainers list].
They have more access rights to the RIOT repositories, such as granting access to a repository, adding new members to a team, or enabling protection for Git branches.
Release managers might need to contact GitHub admins to configure the branch protection rules for the release branch.
Beyond those technical duties and access rights, they do not have any special rights among maintainers.
They are picked by the maintainers, usually based on seniority.
miri64 marked this conversation as resolved.
Show resolved Hide resolved
The maintainers try to take care to spread the admin responsibility over several project stakeholders within the maintainer body.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not directly clear to me what is meant here with stakeholders. I saw the earlier discussion on it, and therefore understand the choosing of this word. This may not be clear to someone fresh reading the text.

Maybe there can be added a word overview to the document, explaining what is meant with 'stakeholders' in this document? Something showing that within the RIOT community there are many people who are part of an organization/institute and work from that institute on RIOT, but we also have individuals not belonging to an organization and want to address them all alike.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like 30a2f85?


There are also admins on the other RIOT discussion platforms. Beyond technical administrative duties they do not have any special rights.
These admins usually are appointed or self-appointed on merit, i.e., whoever sets up the platform usually is (one of) its admin(s).

### GitHub Owners
Github owners are a special subgroup among RIOT GitHub admins.
They are marked as such in the [maintainers list].
Beyond this special status and the usual GitHub admin rules and duties they do not have any special rights among maintainers.

### Moderators

Moderators are responsible to enforce the values of the RIOT community within its discussion platforms. Each platform usually has its own set of moderators, a list of which can be found there.
The forum moderators, e.g., can be found [here](https://forum.riot-os.org/g/moderators) (link requires you to be logged into the forum).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently don't have any appointed moderators for other communication channels, do we? This text makes it sound as if we had (or at least would like to have) them, but doesn't give a hint on what those are.

Copy link
Member Author

@miri64 miri64 Dec 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do. The forum moderators where appointed by the community back when the forum was started. [edit: 2024-12-10T14:35] Should have read more clearly. No, we don't have.

With the chats it usually goes the “IRC way”. People are appointed somewhat on merrit and on how active they are. Since the moderation roles in the chats is, however, a little bit different than on the forum, I don't think there needs to be a moderator appointment procedure for that.

With the few mailing lists remaining, the moderators are mostly sorting out spam, so while similar to forum moderation, I also don't think appointment procedures are necessary here.

A forum moderator, on the other hand, actually can moderate a discussion on the forum, in the traditional sense of the word. They can edit posts, they can split out conversations in new topics and make forum topics a “wiki post” (so something everyone can edit). In that regard, they have much more power and require a certain level of trust from the community.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@miri64 miri64 Dec 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also lost in trunctation #21067 (comment):

We currently don't have any appointed moderators for other communication channels, do we? This text makes it sound as if we had (or at least would like to have) them, but doesn't give a hint on what those are.

[…] No, we don't have.

With the chats it usually goes the “IRC way”. People are appointed somewhat on merrit and on how active they are. Since the moderation roles in the chats is, however, a little bit different than on the forum, I don't think there needs to be a moderator appointment procedure for that.

With the few mailing lists remaining, the moderators are mostly sorting out spam, so while similar to forum moderation, I also don't think appointment procedures are necessary here.

A forum moderator, on the other hand, actually can moderate a discussion on the forum, in the traditional sense of the word. They can edit posts, they can split out conversations in new topics and make forum topics a “wiki post” (so something everyone can edit). In that regard, they have much more power and require a certain level of trust from the community.

The tools at the disposal of the moderator are also very platform-dependent but in general, they try to resolve conflicts that may arise between contributors, unless a [Code of Conduct] violation takes place.
Moderators are people that the community put their trust upon.
As such, they are granted this status via consensus from the community.
Typically, other moderators may propose new moderators.

## Decision Making
Decisions within the RIOT community are made on the principles of “rough consensus and running code” as [coined by the IETF](https://datatracker.ietf.org/doc/html/rfc7282). To directly quote RFC 7282 which defines the IETF governance:

> […] our credo is that we don't let a single individual dictate
> decisions (a king or president), nor should decisions be made by a
> vote, nor do we want decisions to be made in a vacuum without
> practical experience. Instead, we strive to make our decisions by
> the consent of all participants, though allowing for some dissent
> (rough consensus), and to have the actual products of engineering
> (running code) trump theoretical designs.
>
> Having full consensus, or unanimity, would be ideal, but we don't
> require it: Requiring full consensus allows a single intransigent
> person who simply keeps saying "No!" to stop the process cold. We
> only require rough consensus: If the chair of a working group
> determines that a technical issue brought forward by an objector has
> been truly considered by the working group, and the working group has
> made an informed decision that the objection has been answered or is
> not enough of a technical problem to prevent moving forward, the
> chair can declare that there is rough consensus to go forward, the
> objection notwithstanding.

Within the RIOT community, the duties of an IETF working group chair fall to maintainers knowledgeable in the area of expertise.
This knowledgability is determined by their own contributions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to have a person who can act as tiebreaker!

How exactly is decided who this is? As in: if there is disagreement on a topic, how is decided who the maintainers knowledgeable the area of expertise is, exactly? Can that be described here?

If there is disagreement on who this person is, what can be used as tiebreaker to decide?
(to answer this question it helps to ask yourselves: what did successfully work in the past?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How exactly is decided who this is? As in: if there is disagreement on a topic, how is decided who the maintainers knowledgeable the area of expertise is, exactly? Can that be described here?

Within the IETF there working groups with one chair are uncommon. So why can't multiple maintainers be the deciders here as well? Rough consensus means that the opinions of experts also should not be disregarded, so this describes exactly this case.

If there is disagreement on who this person is, what can be used as tiebreaker to decide?
(to answer this question it helps to ask yourselves: what did successfully work in the past?)

So far a tiebreaker was not needed, if I remember correctly.

On decisions regarding a release, the release manager(s) take this position.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this work with decision regarding documentation?
And regarding strategy setting/vision/goals?

Here too: what has worked successfully on (controversial) decisions in documentation in the past, and what procedures lie behind it that can be used for future decision making? And what was successful for taking strategy decisions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this work with decision regarding documentation?

Documentation is typically about something code related, so I'd say the maintainer responsible for the code (after all, they could e.g. also see immediately that the doc is factually incorrect).

And regarding strategy setting/vision/goals?

We have our maintainers / experts there as well (see #21067 (comment) ff). :-)

## Meetings

There are three types of regular meetings within the RIOT community:

- The annual General Assembly (GA),
- The quarterly Virtual Maintainer Assembly (VMA), and
- The Weekly Coordinational Meeting.

The GA is public and anyone who sees themselves as a member of the RIOT community can participate.
Larger community steering decisions for the community are made during the GA, e.g., electing contact people for the Code of Conduct.
The GA usually takes place during the [RIOT Summit](https://summit.riot-os.org/), the annual get-together of the RIOT community.
The GA moderator usually is appointed by the organizers of the RIOT Summit.
It is usually recorded and its notes will be published publicly in the RIOT forum.
The agenda for the GA is collected before the assembly but may be bashed at the start of the meeting.

The Virtual Maintainer Assembly (VMA) is a closed meeting among maintainers.
The VMA appoints the release manager for upcoming releases and the moderator for the next VMA.
Other maintenance decisions such as the fate of larger sections of code are discussed after these administrative tasks are done.
The VMA usually takes place about a month after the latest release, usually in a virtual space, such as a video conference.
The VMA moderator polls the maintainers for a sufficient date around the date of the upcoming release.
Every forth VMA may or may not co-incide with the GA. However, the VMA moderator usually decides to merge these two meetings.
In this case, VMA moderator and RIOT Summit organizers decide together on who is moderating the joint event (it may be the VMA moderator, it may be someone else).
The agenda for the VMA is collected before the assembly but may be bashed at the start of the meeting.
The notes of the VMA will be published publicly in the RIOT forum.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The notes of the VMA will be published publicly in the RIOT forum.
The notes of the VMA will be published publicly in the [RIOT forum](https://forum.riot-os.org/tag/vma).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally try to avoid links to platforms beyond our website or GitHub in this document, as those might change in the future, while putting them in here would just ossify them (or the links could spoil like milk,... see the old maintainer list or other links I just had to move around), see also #21067 (comment).


The Weekly Coordinational Meeting is a closed meeting among maintainers.
It usually serves as a small communal get-together of maintainers on a regular basis.
Smaller maintenance decisions are made during these meetings, but also short term admistrative tasks are discussed.
The Weekly Coordinational Meeting usually takes place every Friday at 10:00 in a virtual space, such as a video conference.
A maintainer that feels responsible for it shares the link to the meeting as well as a proposed agenda, which may be amended by other maintainers, usually a day in advance.

## Code of Conduct

[Code of Conduct] violations by community members will be discussed and resolved on the [email protected] list.
If one of the appointees to that list (see the [Code of Conduct reporting guidance] for the members on that list) is involved in a Code of Conduct violation, two forum moderators from other stakeholders than the appointee take their place in the discussions.

## Security Response Team

The maintainers will appoint a Security Response Team to handle security reports.
This committee may simply consist of the maintainers themselves.
The Security Response Team is responsible for handling all reports of security holes and breaches according to the [security policy].

## Modifying this Charter

Changes to this Governance and its supporting documents require the approval of at least four maintainers who all must be employed by or associated with different stakeholders.

miri64 marked this conversation as resolved.
Show resolved Hide resolved
## Attribution
This document was originally based on the [GOVERNANCE-maintainer.md template] by the Cloud Native Computing Foundation (CNCF).

[RFC7228]: https://datatracker.ietf.org/doc/html/rfc7228
[draft-ietf-iotops-7228bis]: https://datatracker.ietf.org/doc/draft-ietf-iotops-7228bis/
[contributing guidelines]: https://github.com/RIOT-OS/RIOT/blob/master/CONTRIBUTING.md
[maintainers list]: https://riot-os.org/maintainers.html
[maintainers GitHub team]: https://github.com/orgs/RIOT-OS/teams/maintainers
[managing a release]: https://github.com/RIOT-OS/RIOT/blob/master/doc/guides/managing-a-release/README.md
[maintaining guidelines]: https://github.com/RIOT-OS/RIOT/blob/master/MAINTAINING.md
[Code of Conduct]: https://github.com/RIOT-OS/RIOT/blob/master/CODE_OF_CONDUCT.md
[Code of Conduct reporting guidance]: https://doc.riot-os.org/coc-reporting-guide.html
[security policy]: https://github.com/RIOT-OS/RIOT/blob/master/SECURITY.md
[GOVERNANCE-maintainer.md template]: https://github.com/cncf/project-template/blob/main/GOVERNANCE-maintainer.md
6 changes: 6 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -136,6 +136,12 @@ help. Our Forum provides an archive of prior questions and answers.
- [GitHub Issue tracker](https://github.com/RIOT-OS/RIOT/issues) for issues
with the code and documentation.

### Governance

For how our community is structured and governed, please see our [governance document].

[governance document]: GOVERNANCE.md

### How to Ask

Please include as much detail as you can that is relevant to your question, not
Expand Down
1 change: 1 addition & 0 deletions doc/doxygen/.gitignore
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
src/css/variables.less
src/changelog.md
src/coc.md
src/governance.md
13 changes: 8 additions & 5 deletions doc/doxygen/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -16,17 +16,17 @@ doc: $(DOCUMENTATION_FORMAT)

# by marking html as phony we force make to re-run Doxygen even if the directory exists.
.PHONY: html
html: src/changelog.md src/coc.md
html: src/changelog.md src/coc.md src/governance.md
( cat riot.doxyfile ; echo "GENERATE_HTML = yes" ) | doxygen -
@echo ""
@echo "RIOT documentation successfully generated at file://$(RIOTBASE)/doc/doxygen/html/index.html"

.PHONY: check
check: src/changelog.md src/coc.md
check: src/changelog.md src/coc.md src/governance.md
( cat riot.doxyfile) | doxygen -

.PHONY: man
man: src/changelog.md src/coc.md
man: src/changelog.md src/coc.md src/governance.md
( cat riot.doxyfile ; echo "GENERATE_MAN = yes" ) | doxygen -

src/css/riot.css: src/css/riot.less src/css/variables.less
Expand All @@ -42,9 +42,12 @@ src/changelog.md: src/changelog.md.tmp ../../release-notes.txt
src/coc.md: ../../CODE_OF_CONDUCT.md
awk 'NR == 1 {print $$0,"{#coc}"} NR > 1 {print $$0}' $< > $@

src/governance.md: ../../GOVERNANCE.md
@sed 's/<!-- TOC start -->/\[TOC\]\n\0/' $< | sed '/<!-- TOC start -->/,/<!-- TOC end -->/d' > $@

.PHONY:
latex: src/changelog.md src/coc.md
latex: src/changelog.md src/coc.md src/governance.md
( cat riot.doxyfile ; echo "GENERATE_LATEX= yes" ) | doxygen -

clean:
-@rm -rf latex man html doxygen_objdb_*.tmp doxygen_entrydb_*.tmp src/changelog.md src/coc.md
-@rm -rf latex man html doxygen_objdb_*.tmp doxygen_entrydb_*.tmp src/changelog.md src/coc.md src/governance.md
2 changes: 1 addition & 1 deletion doc/doxygen/riot.doxyfile
Original file line number Diff line number Diff line change
Expand Up @@ -866,7 +866,7 @@ INPUT = ../../doc.txt \
src/ \
src/mainpage.md \
src/vision.md \
src/community-processes.md \
src/governance.md \
src/roadmap.md \
src/coc-info.md \
src/coc.md \
Expand Down
Loading
Loading