[RFC 0102] Moderation Team #102
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,103 @@ | ||
| --- | ||
| feature: moderation team | ||
| start-date: 2021-08-18 | ||
| author: tomberek | ||
| co-authors: blaggacao | ||
| shepherd-team: @ryantm, @7c6f434c, @IreneKnapp | ||
| shepherd-leader: @zimbatm | ||
| related-issues: https://github.com/NixOS/rfcs/pull/98 | ||
| --- | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| Establish a team to perform moderation. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| 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. | ||
|
|
||
| The intention behind this RFC is to codify the current moderation practices. | ||
|
|
||
|
There was a problem hiding this comment. One of the biggest issues is that the current process is not documented. It should be clear what the boundaries of the acceptable behaviors are, and what happens if they get crossed. If I get banned, how long will it be? Is there an appeal process I can use? Moderation is a necessary chore and we should be removing as much uncertainty as possible in the process. There was a problem hiding this comment. I would expect a robust RFC to establish those things. The current form is pretty disappointing as it doesn't even begin to attempt to do those things. There was a problem hiding this comment. I would say that while the procedure for transparency and scope of appeals could be addressed here, the exact expactations might as well be a separate RFC; administrative code and code of administrative procedure are distinct in many jurisdictions. There was a problem hiding this comment. @zimbatm I'd like to remove the uncertainty, but I'm not sure of how to do that without opening a Pandora's box of bike-shedding and disagreement. Trying to over-prescribe exactly what the procedures are removes the human element. Additionally, trying solve the entire problem of moderation in one fell swoop does not seem wise to me. We can add something along the lines of? "The team's composition, contact information, guidelines, procedures, and announcements should be maintained at https://nixos.org/community/teams/moderation.html." This would establish an expectation that the current state is disclosed without trying to prescribe what that state should be. If something is problematic, ongoing RFCs and community discussion can address it. If that meets the need or there is some nice self-contained/non-controversial addition, then I'd love to include it. (yes, i AM attempting to be as minimal as possible in order to have a non-controversial RFC so we can make progress. I believe RFC98 has had enough opposition and strong opinions on either side that makes accepting it difficult at best, and divisive at worst. The discussion degraded several times to the point of being unproductive and the whole affair has become a mess.) There was a problem hiding this comment. In addition to the above said, I can only add that I genuinely trust the team more than the current RFC authors here AND there to come up with practical guardrails (e.g. in a complementary RFC).
Still, those fundamentally procedural guarantees might be some cornerstones that we might want to plug in here? Maybe we can remain true to the delegation-of-implementation approach, but mention in general terms 1) that the team should extend appropriate guarantees in all its actions 2) that the team should apply conservative measurement ("not be too eager"). To capture the general sentiment, here, in other words: the worst thing to write into a constitution really is "kids under 14 must go to bed before 8:15pm". There was a problem hiding this comment. With regard to the assertion that "the discussion degraded several times to the point of being unproductive", I don't actually feel that that's true. As one of the authors of RFC 98 I have done my best to welcome all criticism, including criticism from the proponents of RFC 102. The proposed standard seems to be that if anyone, at any point during the discussion of an RFC, says something rude and overly personal, that this means the discussion has degraded. I hope it's clear to everyone that this would give a de facto veto to anyone who is willing to behave rudely. I also hope everyone will reject the idea that RFC 98 is somehow unacceptable simply because there are people opposed to it. There will be people opposed to any proposal that has real substance. Finally, I want to say that this isn't a "two sides" thing. Whatever gets enacted as part of this discussion will be for the benefit of the entire Nix community. I hope everyone keeps that in mind. |
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| The Moderation Team is a volunteer group that may receive, invite, and evaluate | ||
| applications to the team or alter the composition at any time. The team's | ||
| composition, contact information, procedures, moderation log, and announcements | ||
| should be available via | ||
| [https://nixos.org/community/teams/moderation.html](https://nixos.org/community/teams/moderation.html). | ||
tomberek marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| The distribution of work within the team may be treated as an internal matter. | ||
| The team shall perform moderation activities on behalf of the community - with | ||
| oversight via the RFC process and input from the NixOS Foundation - for | ||
| discussions in [official project | ||
| spaces](https://nixos.org/community/index.html) as well as unofficial spaces | ||
| that seek and reach such an agreement with the team. The team should utilize | ||
| the [NixOS Foundation mission](https://nixos.org/community/index.html) and the | ||
| following statement during their duties: | ||
|
|
||
| ``` | ||
| The NixOS Foundation aims to promote participation without regard to gender, | ||
| sexual orientation, disability, ethnicity, age, or similar personal | ||
| characteristics. We want to strive to create and foster community by providing | ||
| an intentionally welcoming and safe environment where all feel valued and cared | ||
| for, and where all are given opportunity to participate meaningfully. The | ||
| Foundation will work with the community in service of this goal. | ||
| ``` | ||
|
|
||
| ref: [twitter](https://twitter.com/grhmc/status/1390775249424338944) | ||
|
|
||
tomberek marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| # Examples and Interactions | ||
| [examples-and-interactions]: #examples-and-interactions | ||
|
|
||
| - The initial Moderation Team - drawn from the existing Discourse and GitHub | ||
| teams - is defined to be @grahamc, @zimbatm, @domenkozar, @Mic92, @garbas, | ||
| and @ryantm. | ||
| - Rename the Discourse Team to Moderation Team on | ||
| https://nixos.org/community/teams/discourse.html and utilize | ||
| https://nixos.org/community/teams/moderation.html. | ||
| - 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:
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.
There was a problem hiding this comment.
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. |
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| * The moderation team has limited guidance from this RFC on the processes and | ||
| procedures of the team. | ||
| * This RFC is designed to address a narrow part of a current issue facing the | ||
| community. Additional RFCs may be needed to address additional concerns. | ||
| * As this is a controversial topic there is a potential this RFC does not have | ||
| enough detail to be acceptable by the overall community. | ||
|
|
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
tomberek marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * Define a constituency of project participants and some (more bottom-up/grassroots) procedure with a foundation in popular support for specific moderators. | ||
|
|
||
| * An existing [RFC 98][]. | ||
| * Do nothing. | ||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| * Does the team require additional guidance? | ||
| * Does the NixOS Foundation board want to be involved in this manner? | ||
|
|
||
| # Future work | ||
| [future]: #future-work | ||
|
|
||
| * 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.
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:
|
||
| 'Leadership Team' or 'Community Team'. | ||
| * Work on clarifying community norm guidelines. This can include adopting | ||
| typical governance tools, such as Contributor | ||
| Covenant, Statements of Values, and | ||
| others in order to provide better guiding principles to our community. | ||
|
|
||
| [RFC 98]: https://github.com/NixOS/rfcs/pull/98 | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe an o-tone from @grahamc or @ryantm on how it becomes increasingly difficult to keep up with their self-assigned (and mostly unnoticeable) moderation work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.