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

GOVERNANCE.md

@@ -0,0 +1,215 @@
+# 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 governance document explains how the project is run.
+
+<!-- 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)
+<!-- 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 there is a clear path up the contributor ladder 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 there work to RIOT.
+This includes,
+
+- of course, code contributions, but also
+- bug reports,
+- other issue reports,
+- participation in technical as well as non-technical discussions, or
+- organizational considerations.
+
+Code contributions are very welcome, but in order to streamline and harmonize code quality, contributors must follow the [contributing guidelines].
+
+
+### 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].
+
+The duties of a maintainer include the following: 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 with the team, get the most knowledgeable people to review code and docs, contribute high-quality code, and follow through to fix issues (in code 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.
+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 contact personally this contributor to propose the status, 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 forum, and
+- invited to the  private 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, failure to fulfill their
+Maintainer responsibilities, violating the Code of Conduct, or other reasons.
+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.
+
+### 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.
+The maintainers try to take care to spread the admin responsibility over several organizations within the maintainer body.
+
+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 merrit, 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).
+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.
+On decisions regarding a release, the release manager(s) take this position.
+
+## Meetings
+
+There are 3 types of meetings that maintainers may participate in:
+
+- The annual General Assembly (GA),
+- The quarterly Virtual Maintainer Assembly (VMA), and
+- 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.
+The VMA may or may not co-incide with the GA, usually the VMA moderator decides, however, 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.
+The agenda for the VMA is collected before the assembly but may be bashed at the start of the meeting.
+
+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 maintainance 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 GA notes for the members of that list) is involved in a Code of Conduct violation, two forum moderators from other organizations 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 4 maintainers who all must be employed by or associated with different organizations.
+
+[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://doc.riot-os.org/maintainer-list.html
+[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
+[security policy]: https://github.com/RIOT-OS/RIOT/blob/master/SECURITY.md

doc/doxygen/.gitignore

@@ -1,2 +1,3 @@
 src/css/variables.less
 src/changelog.md
+src/governance.md

doc/doxygen/Makefile

@@ -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
+html: src/changelog.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
+check: src/changelog.md src/governance.md
 	( cat riot.doxyfile) | doxygen -
 
 .PHONY: man
-man: src/changelog.md
+man: src/changelog.md src/governance.md
 	( cat riot.doxyfile ; echo "GENERATE_MAN = yes" ) | doxygen -
 
 src/css/riot.css: src/css/riot.less src/css/variables.less
@@ -39,9 +39,12 @@ src/css/variables.less: src/config.json
 src/changelog.md: src/changelog.md.tmp ../../release-notes.txt
 	@./generate-changelog.py $+ $@
 
+src/governance.md: ../../GOVERNANCE.md
+	@sed 's/<!-- TOC start -->/\[TOC\]\n\0/' $< | sed '/<!-- TOC start -->/,/<!-- TOC end -->/d' > $@
+
 .PHONY:
-latex: src/changelog.md
+latex: src/changelog.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
+	-@rm -rf latex man html doxygen_objdb_*.tmp doxygen_entrydb_*.tmp src/changelog.md src/governance.md

doc/doxygen/riot.doxyfile

@@ -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/creating-modules.md \
                          src/creating-an-application.md \