Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0102] Moderation Team #102

Merged
merged 9 commits into from
Feb 21, 2022
Merged

[RFC 0102] Moderation Team #102

merged 9 commits into from
Feb 21, 2022

Conversation

tomberek
Copy link
Contributor

@tomberek tomberek commented Aug 19, 2021

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:

  1. There is a desire to improve our ability to perform community moderation
  2. Trust in the existing moderators
  3. Agreement with the mission and statements of the NixOS Foundation

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.

Initial draft

Add 2 future works items extracted from discussions with RFC 98 authors
that requires moderation, and we'd like to help the community become more
self-regulating.

(adopted from #98)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@L-as
Copy link
Member

L-as commented Aug 19, 2021

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.

@7c6f434c
Copy link
Member

While this is another interesting direction, it is very barebones on what their actual duties are.

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…

There is almost nothing about their concrete duties,

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.

what they're supposed to do, transparency requirements, etc.

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)

[examples-and-interactions]: #examples-and-interactions

The initial Moderation Team is defined to be @grahamc, @zimbatm, @domenkozar,
and @ryantm.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@lf-
Copy link
Member

lf- commented Aug 20, 2021

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:

The Moderation Team is a volunteer group that may receive, invite, and evaluate applications to the team or alter the composition at any time with approval from the NixOS Foundation board or by any individual choosing to resign

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?

@7c6f434c
Copy link
Member

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.

@blaggacao
Copy link
Contributor

blaggacao commented Aug 20, 2021

@lf-

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:

  • We can avoid a rather complex question until something actually starts to fail in daily practice and we have a concrete issue and need to make an RFC about it.
  • Tying parts of the Checks & Balances, specifically "approval", to the legal framework of a sovereign nation actually opens up the possibility for legal enforcment of duties. For example, if the foundation grossly violates their duties with respect to see for a well functioning Moderation Team, and as a result members might suffer significant odds related to lack of moderation, then, if the situation is serious enough, holding someone legally responsible (for their gross violation of duties) at least enters into the realm of (very remote) possible options. Regardless, it's on the table.

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:


@7c6f434c

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.


@L-as

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.
Copy link
Member

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?

Copy link
Contributor

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?

Copy link
Member

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.

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?

Copy link
Contributor

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.

@shlevy
Copy link
Member

shlevy commented Aug 20, 2021

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?

@shlevy
Copy link
Member

shlevy commented Aug 20, 2021

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.

@lf-
Copy link
Member

lf- commented Aug 20, 2021

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.

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.

@ryantm
Copy link
Member

ryantm commented Aug 20, 2021

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>
@7c6f434c
Copy link
Member

7c6f434c commented Aug 20, 2021

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.

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)

@blaggacao
Copy link
Contributor

blaggacao commented Aug 20, 2021

@shlevy @lf-

Re: Authority / Responsability

The NixOS foundation [...] not really responsible for the project communication spaces.

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.

@shlevy
Copy link
Member

shlevy commented Aug 20, 2021

@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 discord (ETA: discourse) would be appropriate. Neither the NixOS Foundation nor the RFC steering committee is an appropriate body for oversight.

Copy link

@aaronchall aaronchall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong objections but I do want to see the need/motivation better documented and I want it clear that fully reading and understanding 98 isn't a prerequisite to participating in this RFC - see my in-line responses.

* 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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@blaggacao blaggacao Sep 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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?

@Mic92 Mic92 added the status: open for nominations Open for shepherding team nominations label Sep 2, 2021
@Mic92
Copy link
Member

Mic92 commented Sep 2, 2021

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.

Copy link
Member

@endocrimes endocrimes Jan 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@7c6f434c
Copy link
Member

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)

@ryantm
Copy link
Member

ryantm commented Feb 1, 2022

As a shepherd of this RFC, I sign off on 7c6f434c's motion to enter the Final Comment Period with disposition to accept.

@IreneKnapp
Copy link

As a shepherd of this RFC, I likewise sign off on 7c6f434c's motion for FCP with disposition to accept.

1 similar comment
@zimbatm
Copy link
Member

zimbatm commented Feb 1, 2022

As a shepherd of this RFC, I likewise sign off on 7c6f434c's motion for FCP with disposition to accept.

@7c6f434c
Copy link
Member

7c6f434c commented Feb 1, 2022

@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>
@nixos-discourse
Copy link

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

@lheckemann lheckemann merged commit 01d0c07 into NixOS:master Feb 21, 2022
@piegamesde
Copy link
Member

I'd appreciate a follow-up on this one, please. What's the current progress of the actions set in the RFC?

@ryantm
Copy link
Member

ryantm commented Mar 23, 2022

@piegamesde I updated the NixOS website with some of the information this RFC asks for: https://nixos.org/community/teams/moderation.html

@mweinelt
Copy link
Member

mweinelt commented Apr 6, 2022

Is there a Matrix room set up where I can discuss a problem I'm seeing?

@ryantm
Copy link
Member

ryantm commented Apr 6, 2022

@mweinelt Yes, there is https://matrix.to/#/#moderation:nixos.org Though also feel free to contact us directly if it is sensitive.

@infinisil infinisil added status: accepted and removed status: FCP in Final Comment Period labels Aug 23, 2023
KAction pushed a commit to KAction/rfcs that referenced this pull request Apr 13, 2024
Co-authored-by: David Arnold <dgx.arnold@gmail.com>
Co-authored-by: 7c6f434c <7c6f434c@mail.ru>
Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.