Moving from “Community Processes” to GOVERNANCE.md

Community
1

As discussed during the RIOT summit (see @Karin’s excellent talk), we need a GOVERNANCE.md document. There is now a PR for that:

Please join the discussion there!

1 Like
2

This PR is now open for a week and some discussions were started and questions were raised. Since this governs our community this should not be decided by a handful of people commenting on the PR. So here is a digest of the current state of discussions. Please voice your opinions on these, your comments are very welcome.

  • Comment #1.1: Currently there is only a process to appoint forum moderators since they have special technical moderation powers (editing posts, splitting out discussions into separate topics, blocking users, filtering spam, …). 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: Here the moderation powers only go as far as blocking/kicking out users
    • Mailing lists: Here the moderation powers only go as far as filtering spam.
  • Comment #1.2: Should there be a more specific time frame when the duties of a release manager end? Currently, it says “once the release is out or if all bug-fixing point releases are out.” without really stating how short before (or after) a feature freeze/RC for the next release a point release may come out.
  • Comment #1.3: Should we more explicitly state our mechanisms to keep a “balance of power”.
  • Comment #1.4: Should there be a route for a contributor to actively ask to become a maintainer?
  • 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).
  • 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?
  • Comment #1.7: Should there be explicit mention of organizational dependencies and hierarchies that might effect the level of freedom of contributors?
  • Comment #1.8: Should roles be described more specific? If so what are these specifics?

(Hope I did not forget anything. If so, please amend comments in the style of Comment #<week>.<running number> so we can keep track of which comments are discussed.)

3

No new update in week 2 since opening the PR.

4

I haven’t had time to work through all of those, but on 1.1, 1.2, 1.4, and 1.8, I’m fine with any outcome.

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. Similar for 1.5, and even 1.6/1.7.

5

Thanks for starting this forum thread @miri64! :slight_smile:

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.

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

The other comments are either mine or I do not have experience/opinion to share.

6

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, and for organizational matters, both contributors and maintainers usually know who is organizing things, so their contribution/expertise should also be clear, or am I looking at this too easy?

7

I wrote some comments, github marks them as Pending, which I’m actually confused about. Did I start a review and not finish that? Do others see my comments?

I think that RIOT-OS has the cross-review problem that many other entities suffer from. (Including the IETF). The people most qualified to do the review are either too busy, or are already involved in the patch. Other people, upon reading the patch might be “meh”, and do not know/understand/care about some subtlety in the design. It may require some leaps of faith.

I think that many of the concerns about how people become maintainers are wrapped up in the above anxiety: how to do we delegate the right amount of authority to maintainers to merge things, while also enabling sensible review, and some amount of “oh, wait, that patch also changed X?”. In the IETF, we suffer from Organization Ossificiation, where every single conflict results in a new rule/policy such that we get consistent results. So please don’t go there. I keep looking for papers that talk about how organizations ossify, and found this article: Organisational Ossification and Management Theory | The Libertarian Ideal {on a libertarian site? ick}. It does talk about Situtational Leadership Model, aka Situational leadership theory - Wikipedia and many still call them the Hersey-Blanchard charts.

I think that there are no real magic bullets here: except, well. Beer. That is building social trust among contributors, maintainers, etc. The summit is critical for this, but maybe we need more time.

1 Like
8

You need to go to the “Files” tab and submit your review.

9

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

Still unresolved

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

Comment #1.2

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 :sweat_smile:.

Comment #1.3

Resolved

@chrysn said on that

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

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

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

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?)

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

I think at least regarding documentation it should be clear

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

Do we need to make this more explicit?

Comment #1.7

Resolved

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

Comment #1.8

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… :face_with_peeking_eye:).

2 Likes
10

With hard feature freeze approaching, it was decided to get this in today. Things that are still unresolved can also be addressed later on. If need be, we can open issues for that.

11

I opened a tracking issue for the remaining discussion points