Moving from “Community Processes” to GOVERNANCE.md

[miri64]

Returning from Christmas break and after the first fulfilled deadline of the year, I’d like to pick this up again. So here is the current state of the discussions since Dec 13th.

To keep track of the discussion, I will summarize the state of the previous (unresolved) comments and then present new ones (if any) that came up.

Previous comments

Most previous comments are resolved, but some still need discussion:

• Comment #1.1
• Comment #1.6
• Comment #1.8

Comment #1.1

@miri64

Comment #1.1: […] Should we also have also a process for the following services? Should these moderation role also be expanded to the more social responsibilities of moderators?

• Matrix: […]
• Mailing lists: […]

Still unresolved

Not much reaction specific reactions to this comment, except @chrysn’s “fine with any outcome”.

Comment #1.2

@miri64

Comment #1.2: Should there be a more specific time frame when the duties of a release manager end? […]

Resolved

The text now says:

Their duties end after the release they managed is out and all bug-fixing point releases to their release are finished.

This proposal comes from @kfessel but I did not find where he proposed it .

Comment #1.3

@miri64

Comment #1.3: Should we more explicitly state our mechanisms to keep a “balance of power”.

Resolved

@chrysn said on that

@chrysn

Gut feeling on 1.3: If we have one, it’s fine. If we have none, it’s fine to state that we aspire to.

I added a not so subtle hint to the paragraph in question:

This is to aspire some checks and balances between stakeholders as well as introduce redundancies in case a stakeholder is not able to work on RIOT anymore.

Comment #1.4

@miri64

Comment #1.4: Should there be a route for a contributor to actively ask to become a maintainer?

Resolved

After some follow-up discussions, I now decided to mention this:

Of course, contributors also can step forward themselves and declare their interest to become a maintainer. In this case, maintainers should then propose them as well, if there activities can be confirmed.

Comment #1.5

@miri64

Comment #1.5: Do we expect specific maintainer behavior that disqualifies them from staying a maintainer (beyond non-responsive inactivity and Code of Conduct violations).

Resolved

@kfessel proposed to add some words on malicious coding behavior, so I did:

Maintainers may also be removed […] upon failure to fulfill their Maintainer responsibilities […]. This also includes actively, persistently, and intentionally trying to harm or successfully harming the code base of RIOT. Especially, but not limited to, endangering the security or safety of RIOT.

Comment #1.6

@miri64

Comment #1.6 and Comment #1.7 : Do we need a more specific rough consensus declaring role (cf. IETF chairs)? Currently this is decided by expertise or special roles such as the release manager(s). Is declaring expertise in documentation, strategy, or vision unclear?

Still unresolved

For @chrysn, we should at least state that we aspire to declare expertise for documentation, strategy, or vision (or do I misinterpret that comment?)

@chrysn

Gut feeling […]: If we have one, it’s fine. If we have none, it’s fine to state that we aspire to. Similar for […] even 1.6/1.7.

To @Karin it is unclear how expertise in documentation or strategy and vision is tallied.

@Karin

Regarding 1.7 (in the part about combined comment 1.6 and 1.7, declaring roles) : to me it is not clear who would be declared as experts in general documentation, such as the readme, contributing guide etc., and in strategy and vision. For specific documentation that belongs with code, it does sound clear indeed.

I think at least regarding documentation it should be clear

@miri64

All of them are documents that are within some GitHub repo, so they can be tracked the same way as the expertise for code is tracked,

Regarding strategy / vision, it might not be as empirical, but still be clear to any longer term member.

@miri64

[…] for organizational matters, both contributors and maintainers usually know who is organizing things, so their contribution/expertise should also be clear […]

Do we need to make this more explicit?

Comment #1.7

@miri64

Comment #1.7: Should there be explicit mention of organizational dependencies and hierarchies that might effect the level of freedom of contributors?

Resolved

@Karin

Regarding 1.7 (organizational dependencies): no need to add it to the text for me.

Since @Karin brought this up originally, I see this comment as resolved.

Comment #1.8

@miri64

Comment #1.8: Should roles be described more specific? If so what are these specifics?

Still unresolved

Not much reaction specific reactions to this comment, except @chrysn’s “fine with any outcome”.

New comments

Comment 3.1

There is @mcr’s comment here in the forum, regarding taking care of balancing the “cross-review problem” and “Organizational Ossification”. This somwhat goes into the direction that Comment #1.8 is pointing to, but is worth discussing.

GOVERNANCE.md author hat off, I think we should rather try to not ossify too much. We should clearly state, how we do things, especially for newcomers (which to my mind is what I am currently doing with the GOVERNANCE.md), we should act upon these rules to make them “law”, but we should not write down every little bit of procedure as “law” (see e.g. the Task Force discussion). Procedures might change, community behaviors might change, we should keep the breathing room for that and we should not make things more complicated or bureaucratic than they ought to be (just have a look at the IETF org chart to have a contra example… ).