[RFC 0102] Moderation Team #102
Conversation
Initial draft Add 2 future works items extracted from discussions with RFC 98 authors
rfcs/0102-moderation-team.md
Outdated
| that requires moderation, and we'd like to help the community become more | ||
| self-regulating. | ||
|
|
||
| (adopted from #98) |
There was a problem hiding this comment.
Maybe also mention a desire for transparency of how to request attention of the moderation team? It's not necessary an official action that is desired.
|
While this is another interesting direction, it is very barebones on what their actual duties are. There is almost nothing about their concrete duties, what they're supposed to do, transparency requirements, etc. |
Thanks for this comment. I like the idea of trying to collect a minimal useful RFC on the topic, and of course to find out what is unacceptable to omit the authors will need specific requests about what's omitted…
If the model is «we pick people we already trust to be able to do moderation», I would say «general moderation» is an acceptable task.
Yes, a transparent log of lasting-technical-impact actions would be nice… (I guess informal mediation is fine to do without transparency, 24h freeze of a flamewar could slip, but bans of appreciable length and longterm discussion freezes would be nice to log) |
rfcs/0102-moderation-team.md
Outdated
| [examples-and-interactions]: #examples-and-interactions | ||
|
|
||
| The initial Moderation Team is defined to be @grahamc, @zimbatm, @domenkozar, | ||
| and @ryantm. |
There was a problem hiding this comment.
Does anyone know if some people currently (actively) moderating any of the official spaces are missed? I cannot remember anyone else right now, I am probably missing someone.
Nominally Eelco Dolstra of course has moderation access on GitHub, but I am not sure when was the last time this was exercised.
There was a problem hiding this comment.
https://discourse.nixos.org/about
I think mainly I've been doing Discourse but in the cases of bigger issues, Mic92, Zimbatm, Rok, and Graham have helped.
|
I have read through this RFC and I am very concerned about the structure of the proposed organization. It puts a lot of trust/authority on the NixOS Foundation, which is an open source software foundation who, like many such organizations, its main duties are managing assets and keeping a legal entity in order, in particular, managing funding for Hydra and the binary cache. This is a very small organization (as I understand it, 3 people) that is currently doing the sorts of uncontroversial things that nobody can really take any significant issue with. The RFC proposes to additionally delegate managing membership of the moderation team to them:
I believe that this is a poor structure as it makes these positions about more than assuming legal duties to keep the organization running by adding something entirely unrelated into their job description. To be clear: I trust them in doing their job, I just don't believe that tying this task to an organization whose main mandate is handling legal responsibilities and funding is fair to the small handful of people who form it, since it gives them a responsibility and potential for controversy by giving these positions significant control over day to day community matters, detracting from their regular duties. A side note: this sentence should be reworded as it is ambiguous as to what it is intended to mean: does an individual choosing to resign have authority to approve altering composition in the course of resigning? |
|
I also think that an implication of a continuous active role of the foundation is unfortunate. On the other hand, by virtue of handling the only resource that actually keeps the project together as a single thing, Foundation will have effective override authority whether we admit it or not, so its ability to exercise oversight can be as well mentioned. |
|
Re: lack of broader constituency procedures / chore strain on foundation members I can hear your argumentS and we discussed them. We should have left better notice in the drawback section. There is an open question whether the foundation wants to be involved in this way in the RFC. Also, there is an ongoing discussion in the comments to hint at very legit more relaxed interpretations of "approval" (in a more general sense of "oversight"). As a complement to the constituency argument that you present, I want to give context on the main reasons for the current formulation:
To preserve terseness of the RFC, this discussion comment may suffice though for that entire context that has been subsumed under "approval" while redacting the RFC. May it be ok to open that can of worms in an agile RFC once we see that actual problems arise? Presuming that the legitimacy of this RFC process will always be higher than that of the Foundation, similar to how a parliament is higher than that of the executive branch. EDIT: Re: matter-of-fact circumstantial powers of the foundation I agree, that in the current setup, the foundation has mater-of-fact powers, that we can just as well make explicit. I sense to (fundamentally) change that setup, might also be an interesting topic for another RFC, if desired. Re: accountable guidlines As the authors, we don't have the proven practical experience so that we would have felt competent enough to make those shots, but we agree in principle they might become practically necessary. We tried to subsume that perspective in the Future Work section. A very elegent outcome would be if the team itself (in the shape of its initial setup) proposes further material in follow up RFC, such as accountable moderation guidlines, but also material that might cover more general community governance affairs would be certainly welcome. |
| There is not currently any official mechanism for moderation action. It's not | ||
| sustainable to have to call on Graham any time there's a spammer or conflict | ||
| that requires moderation, and we'd like to help the community become more | ||
| self-regulating. |
There was a problem hiding this comment.
I still think this motivation is a bit sparse. Can we include some specific instances where this team would have been helpful and what we did instead?
There was a problem hiding this comment.
I don't know what an "o-tone" is but this would be part of it, yes. The other part would be to clarify what portion of their moderation work actually needs doing, vs what portion can be left without official authority. It's plausible to me that all of it is in the former category, but these discussions are continually shrouded in lack of specification so I'm genuinely unsure.
There was a problem hiding this comment.
I think we need some documentation on the needs for additional structure around moderation, not the mere assertion. Perhaps there is some that I'm not aware of. I'm aware of the need for moderation in many areas, I'm a moderator elsewhere myself, but I haven't seen any moderation issues coming up in NixOS. If there have been, that simply means the current moderation is doing a great job. And I haven't seen them complaining about the burden. I haven't seen any stakeholders complaining about the moderation, either. Can we please get this documented?
There was a problem hiding this comment.
@ryantm Might you be able to step in and offer us a quotable paragraph that sums up your experience from your personal point of view? I also feel your or graham's input is missing.
|
I don't think having this responsibility fall to the foundation board makes much sense. The NixOS foundation has a very focused mission and is not really responsible for the project communication spaces. Is there a problem with leaving oversight in the RFC process and letting the team itself propose specific mechanisms for changing its composition if RFCs are too much? |
|
I strongly disagree with the implication that because the foundation has the ability to damage the project in various ways, therefore it actually already has the authority to make these decisions. Authority is not merely formal words on top of technical ability to exercise power. |
The Foundation at best has authority over IP rights, but depending on the licensing of those, it may not be relevant. If the actual non-organization of maintainers decided that they had enough of the Foundation, they effectively can just get rid of them and make a new one, it would be a great effort but would take a rack or two of computers and a lot of sysadmin work. The same cannot be said for the other way around: they rely on maintainers to exist, and serve the community. There does not currently exist a power relationship where the Foundation has any real control over development or governance and this RFC effectively introduces one. My perception is that this decision to give the Foundation power was a case of "we need an authority to resolve disputes, this looks like one, they own all the infrastructure", when the named group is 3 respected people, some servers, and paperwork. It is constructed to help the project succeed but it does not control the existing governance. Consider the recent example of Freenode: the people who took it over thought they had power because they owned servers and assets. They didn't. With much inconvenience and growing pains, the people with social capital (the administrators) formed a new network and everyone moved. This is how the NixOS organization works too: the people owning the computing assets are merely here to help, with the approval of the community and the teams making decisions. |
|
It would be the case without saying it, but maybe it would help (and be enough by itself) to say authority over the team is retained by the RFC process itself. |
Co-authored-by: David Arnold <dgx.arnold@gmail.com>
Would this benefit from a mention that process RFC discussions should be moderated with special caution? (off-topic removal in RFC discussions happens, and sometimes it is debatable, which is fine but might be a problem if it looks like interference with oversight) |
|
Re: Authority / Responsability
The intended focus was placed on the need for checks & balances that complement the work & responsibilities of the team. I think we should clarify if the current RFC elicits another focus (such as a "one-directional power relationship" or "responsibilities") during reading. Maybe @ryantm suggestion could be helpful to explicitly add the RFC process as a third source for checks & balances. |
|
@blaggacao I understand the desire for checks and balances, but I'd prefer we just be clear that this team does not have a very broad mandate to begin with and use existing mechanisms until and unless further need arises. Or if we want to, maybe just some formal vote on |
| * A potential RFC providing additional guidance and detail for the moderation | ||
| team's activities and functions. | ||
| * The role of the moderation team could evolve through an effort similar to | ||
| [RFC 98][] into taking a broader community leadership responsibility as a |
There was a problem hiding this comment.
98 is a complete non-starter for me and I don't think it should be used as any sort of official reference. It is an excessively long screed that injects a one-sided political view, and it's an unnecessarily large burden to make it a prerequisite for understanding what we're doing here. I suggest either dropping allusions to it or making it clear that this is summing up whatever ideas were being communicated there.
There was a problem hiding this comment.
Is the word could & the fact that it's within the future section not concise enough?
I can understand your impressions on 98, but for the sake of bringing people together, we also wanted to leave a potential dovetail - subject of "(maybe) future work".
There was a problem hiding this comment.
98 is a complete non-starter for me and I don't think it should be used as any sort of official reference
Same view here. If this is supposed to be a simpler and less controversial version of RFC98, it should be completely standalone. Maybe incorporate some of its text, but not cite it altogether.
There was a problem hiding this comment.
I agree 98 is a non-starter, this was started as a direct response to the mess it became. Should we remove this reference and allow the PR's conversation+commentary to retain that historical link? (I don't have a clear strong preference either way, just trying to find what would be best and acceptable to as many people as possible.)
There was a problem hiding this comment.
We have to measure sentiments both ways. Consensus includes all stakeholders. And as much as 98 has turned many participants sour, the authors of that RFC are by no means adverseries of this RFC.
I think certain amount of dovetailing [especially so in the future section] is neither 1) binding nor 2) ill-scoped.
If this is becoming a blocker, though. We might only retain it in spirit, not text.
(Although that would send a bit of a "we-against-them" message - the type of messages I find very unfortunate in principle)
OTOH, I find the essence of @aaronchall 's formulation is worth clarifying:
I want it clear that fully reading and understanding 98 isn't a prerequisite to participating in this RFC
| There is not currently any official mechanism for moderation action. It's not | ||
| sustainable to have to call on Graham any time there's a spammer or conflict | ||
| that requires moderation, and we'd like to help the community become more | ||
| self-regulating. |
There was a problem hiding this comment.
I think we need some documentation on the needs for additional structure around moderation, not the mere assertion. Perhaps there is some that I'm not aware of. I'm aware of the need for moderation in many areas, I'm a moderator elsewhere myself, but I haven't seen any moderation issues coming up in NixOS. If there have been, that simply means the current moderation is doing a great job. And I haven't seen them complaining about the burden. I haven't seen any stakeholders complaining about the moderation, either. Can we please get this documented?
Mic92
added
the
status: open for nominations
|
We need at least one shepherd from the #98 rfc team on this RFC too, to ensure coordination. |
Co-authored-by: 7c6f434c <7c6f434c@mail.ru>
Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
| - Establish and publish a clear point of contact for abuse reporting and a | ||
| venue for discussion about moderation specific topics such as a dedicated | ||
| Matrix channel or Discourse topic. | ||
|
|
There was a problem hiding this comment.
This RFC is missing some major parts of running a moderation team. Namely, it's missing the lifecycle management and onboarding of new moderators, and the phasing out of existing ones.
I understand that the primary purpose here is to ratify the status quo, but to be successful we also need to define the next steps and what defines a healthy moderation team, to prevent this from stalling after minimal progress.
A healthy moderation team often operates with a term based system - both to reduce burnout and ensure that nobody ends up in a position of being a moderator for life.
To that end, I think this RFC needs:
- an initial set of working practices (that can be adjusted in the future), as an example, the CoCC bootstrapping done within the kubernetes community https://github.com/kubernetes/community/blob/master/committee-code-of-conduct/bootstrapping-process.md.
- to require an odd number of members to prevent split-decisions when a vote is required (there are currently 6 suggested initial members and simplify quorum).
- a requirement that a formal charter (e.g https://github.com/kubernetes/community/blob/master/committee-code-of-conduct/charter.md) is defined within some period after the initial committee is bootstrapped.
There was a problem hiding this comment.
In general I am not opposed to adding more detail, but we don't seem to differ too much from the k8s document, and we have more detail about the specifics.
-
initial working practices are sparse, but do specify overall guiding principles that don't seem to be controversial (mission + twitter statement). Perhaps we add a few explicit expectations into the "Examples and Interactions" section? Though I don't quite know what we should add. Do you have a minimal recommended addition?
-
odd number of members: We're trying to enumerate the current moderators (either de facto or de jure). I'd like to avoid adding or removing arbitrarily (and there is almost never a timezone or opportunity for all to meet anyway and deadlock can be seen as both a feature or a curse). I'm open to adding someone I may have missed.
-
formal charter: I included some items in Future Work and in the statement "The team's composition, contact information, procedures, moderation log, and announcements should...". Add "charter" to that list? or change procedures to charter?
There was a problem hiding this comment.
This RFC is missing some major parts of running a moderation team.
Yes, and these are currently handled pretty ad-hoc, and that will have to do for some more time.
RFC SC also seems to have some regular practices beyond what is written down as a public document, and moderation currently happens somehow, so formalising initial procedures seems optional based on experience.
It is unclear why do we need to make deadlocks on a decision procedurally impossible. After all, RFC SC needs to make a lot of decisions unanimously and progress still happens. Full team consultations take a lot of time either way so they cannot be a way to make instant decisions. And unlike RFC SC duties, quick decisions are a part of moderation.
We have already had an «X must be defined by Y» attempt (documentation system choice). I think that outcome is «the attempt failed, then a more typical RFC process happened, and took quite some time to converge». (I don't think the implementation has converged yet, either). I do not see any reasons to believe a deadline would bring us much good here.
RFC SC rotation rate is quite limited by new applications, and moderation needs more of trust in each member (for RFC SC with its unanimity procedures it is enough to have trust in good faith of all members and values of a half — especially when different project participants trust different subsets). So it's better to first just stress explicit rotation decisions as a part of moderation team duties, which this proposal does.
Overall I think each of the proposed additions would need non-trivial amount of discussion to decide in favour or against, and I see no argument why this has to be a part of the scope here.
|
As one of the shepherds of this RFC proposal, I formally propose Final Comment Period with disposition to accept. As usual, the FCP shall start as soon as all of the shepherds confirm agreement and the corresponding summary announcement is posted here and on Discourse. (pedantic note as this is a procedure discussion anyway: RFC 0036 does not say that the shepherd leader should be the first one to go on record in favour of FCP, only that all shepherds need to reach unanimous agreement) |
|
As a shepherd of this RFC, I sign off on 7c6f434c's motion to enter the Final Comment Period with disposition to accept. |
|
As a shepherd of this RFC, I likewise sign off on 7c6f434c's motion for FCP with disposition to accept. |
1 similar comment
|
As a shepherd of this RFC, I likewise sign off on 7c6f434c's motion for FCP with disposition to accept. |
|
@zimbatm As you have access to RFC Announcements area at Discourse, maybe you will announce the FCP (here and there)? |
Co-authored-by: 7c6f434c <7c6f434c@mail.ru>
lheckemann
added
status: FCP
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfc-0102-fcp-moderation-team/17607/1 |
|
I'd appreciate a follow-up on this one, please. What's the current progress of the actions set in the RFC? |
|
@piegamesde I updated the NixOS website with some of the information this RFC asks for: https://nixos.org/community/teams/moderation.html |
|
Is there a Matrix room set up where I can discuss a problem I'm seeing? |
|
@mweinelt Yes, there is https://matrix.to/#/#moderation:nixos.org Though also feel free to contact us directly if it is sensitive. |
infinisil
added
status: accepted
and removed
status: FCP
Co-authored-by: David Arnold <dgx.arnold@gmail.com> Co-authored-by: 7c6f434c <7c6f434c@mail.ru> Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
The intention behind this RFC is to directly address the motivating problem behind #98 in a minimal way, building upon what seem to be the general points of agreement:
This RFC presumes that the team will take a few steps to self-organize, determine effective procedures, and communicate with the community writ-large - but purposefully leaves the specific details for the team to decide.
Rendered
Edit: through discussion, the oversight role of the Foundation has been replaced by the RFC process.