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
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.)
No new update in week 2 since opening the PR.
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.
Thanks for starting this forum thread @miri64! 
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.
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?