Create venue sub-team of mods

[oli-obk]

The github rust-lang/mods team and the zulip mods group now correspond to the larger group of folk that are the venue moderators.

I also chose to retire the mods-discord team at the same time, considering that we're shutting down the discord server soon.

cc @steffahn @rylev @Nadrieril

cc @jieyouxu @Noratrieb @apiraino

cc @rust-lang/leadership-council

[github-actions]

Dry-run check results

[WARN  sync_team] sync-team is running in dry mode, no changes will be applied.
[INFO  sync_team] synchronizing github
[INFO  sync_team] 💻 Team Diffs:
    📝 Editing team 'rust-lang/all':
      Deleting member 'sgrif'
    ➕ Creating team:
      Org: rust-lang
      Name: moderation
      Description: Managed by the rust-lang/team repository.
      Privacy: closed
      Members:
        Nadrieril: member
        oli-obk: member
        rylev: member
        steffahn: member
    ➕ Creating team:
      Org: rust-lang-nursery
      Name: moderation
      Description: Managed by the rust-lang/team repository.
      Privacy: closed
      Members:
        Nadrieril: member
        oli-obk: member
        rylev: member
        steffahn: member
    📝 Editing team 'rust-lang/mods':
      Adding member 'Nadrieril' with member role
      Adding member 'Noratrieb' with member role
      Adding member 'apiraino' with member role
      Adding member 'jieyouxu' with member role
      Adding member 'rylev' with member role
    📝 Editing team 'rust-lang-nursery/mods':
      Adding member 'Nadrieril' with member role
      Adding member 'Noratrieb' with member role
      Adding member 'apiraino' with member role
      Adding member 'jieyouxu' with member role
      Adding member 'rylev' with member role
    ❌ Deleting team 'rust-lang/mods-discord'

[apiraino]

Would a ping-group be useful here?

[oli-obk]

we'd still need a team to put the venue mods under to get them the github org powers they need

[oli-obk]

apropos @rust-lang/infra can we move/duplicate the powers that the mods team has on github to the mods-mediators team, too? Or should we just keep ensuring every mods-mediators member is also a mods member?

[marcoieni]

It seems that the mods team is being renamed to mods-mediator, right?

So after this migration we need to ensure that the mods-mediator team has the same permissions that the mods team had previously, right?

[oli-obk]

Well, moda venue has the github name mods, which has the right permissions. And all mediators are also venue mods, so they got those perms, too

[marcoieni]

Oh, I missed the team-name field in [[github]].

can we move/duplicate the powers that the mods team has on github to the mods-mediators team, too? Or should we just keep ensuring every mods-mediators member is also a mods member?

imo both works. It's up to you, based on what you and the team prefer. 👍

[oli-obk]

I think having both mods and mods-mediators have the same github powers while allowing some ppl from mods-mediators not be in mods and thus not receive the github pings is best

[oli-obk]

We can just merge the PR as is now, and once mediators have the powers, we can remove ppl when they want to be removed

[marcoieni]

Ok, I'll merge the PR once an infra admin approves it 👍

[traviscross]

It seems that the mods team is being renamed to mods-mediator, right?

Well, moda venue has the github name mods, which has the right permissions. And all mediators are also venue mods, so they got those perms, too.

Since the moderation team is specifically chartered under RFC 3392 with certain powers and with a certain relationship to the council, we should probably write down fairly explicitly how these are being transferred.

[traviscross]

Given the potential governance implications of this, I'd suggest let's let the council discuss before merging:

• Discuss proposed changes to the mods team leadership-council#185

[oli-obk]

Only the name is changed. I think creating a sub team is very much in the purview of the mod team (or any team). The council can have oversight here, but blocking it on a discussion does not seem necessary to me.

[traviscross]

Creating mods-venue isn't the concern. I agree it's within the purview of mods to do that.

From team-private discussions, it had been my understanding that we were preserving the mods team as-is and adding a mods-mediators subteam. Looking at this PR, though, I gather that we're instead dissolving the mods team and creating the mods-mediators team in its place while calling mods-venue "T-mods" in various venues.

What I believe to be the intent, then, is that mods-mediators would inherit all of the chartered roles and responsibilities of the mods team under RFC 3392. However, even being privy to the private discussions, that's not what I'd call "perfectly clear" to me, and as this affects governance, I'd like us to see about how to make this perfectly clear.

We'll also, I think, have a communication challenge to solve, since someone reading RFC 3392 will see roles and responsibilities chartered to the moderation team, but we'll be in many places calling mods-venue the mod team. We'll just want to write this all down clearly somewhere.

[oli-obk]

The website literally is still called Moderation team with zero changes. Changing the name of a rust module/file for a stable feature doesn't need T-lang discussion either

[traviscross]

Do you disagree that calling mods-venue "T-mods" raises some possibility for confusion here?

Maybe I'm too close to it. If you think this is totally clear from a governance perspective, I won't stand in your way here.

[BurntSushi]

As a former mod, this change is wildly confusing to me.

[oli-obk]

These are the ping groups for getting the right ppl notifications into their feed. They are the shortest thing ppl will reach for when there is a moderation event. Just like with the email address (except that is for private information, too).

People reaching for mods in an urgent manner care about the immediate issue being resolved. They do not care about governance.

There can absolutely be confusion, but not really more than the years out of date mod team repo that I fixed last week or the completely out of date information in the discourse and discord mods file in the teams repo.

We are actively working on improving docs in the moderation team repo. This is the next step that gets us further. If we need to figure out everything in one big go then we'll be stuck like we have been for long before I joined mods.

[jieyouxu]

I think I see why this is might be confusing:

• Structurally, there are two changes here:
  1. The top-level moderation team (in RFC 3392 sense) is renamed mod-mediators
  2. There's now a subteam for venue-specific mods called mods-venue
• The Github team named @rust-lang/mods in this PR corresponds to the venue subteam and not the top-level moderation team.
• And Zulip group wise,
  1. What's previously the top-level moderation team (T-mods) is now renamed to T-mod-mediators
  2. T-mods on zulip is repurposed to correspond to the venue subteam.

I think part of why this is difficult is because users on Zulip would in most scenarios intuitively try to ping T-mods for zulip venue moderators (before this PR, that will ping the top-level moderation team), and T-mods-venue is a bit of a mouthful 🤔 ¹. On github, users might reasonably expect something like @rustbot ping mods to contact the GitHub venue moderators.

Footnotes

1. On Zulip, there's yet another Zulip mods group which is orthogonal to this. ↩

[traviscross]

To be sure it's said, I appreciate everything you're doing here.

[pietroalbini]

infra-admins approval (as in, the changes to the sensitive files are ok from an infra perspective).

[Noratrieb]

@traviscross what kind of writing down do you envision? Would you be satisfied if RFC 3392 was edited to contain a note that the moderation team's structure has since changed?

[traviscross]

what kind of writing down do you envision? Would you be satisfied if RFC 3392 was edited to contain a note that the moderation team's structure has since changed?

Yes, I'd had a similar thought. At the same time, this is why I had nominated it for LC this Friday, so we could discuss to see what people think might make this the most clear.

[steffahn]

Coming to think of it, I'm not sure that a team mention à la @rust-lang/mods is a decent way to notify moderators anyway because it’s only possibly for organization members in the first place, isn’t it? Which means, if it’s visible practice, it excludes any non-org-member contributors from following the same approach.

This PR, publicly (org-externally), beyond the file-name and contents in this repo, the only place where a name change happend with the current PR state is on Zulip, where the mods groups situation is already a bit complex anyway, and arguably we should just make @mods do the “right” thing there. Maybe the least problematic rename for now would be to move more labels for to-level from “mods” to “moderation”, so Zulip could be T-moderation¹; and mods-venue could also be called something like mods-gh-zlp² somehow mentioning the specific venue (and falling rather into the more broad, pre-existing category of vanue-moderator subteams, next to ). Then @mods on Zulip becomes an alias³ for T-mods-gh-zlp, and the @mods [for lack of a T-] never claims to be the team name, anyway.[^0]

How best to approach Github, I’m not sure, but the foundation (of calling groups moderation and mods-gh-zlp next to unchanged mods-discourse) could at least facilitate some mentions-based and/or bot-based approach that will somehow (and clearly) “translate” this into a T-mods-gh-zlp ping.⁴

Footnotes

1. like the current full name of “Moderation team” (not “moderators”), and apparently also matching a T-moderation label that seems to exist on the RFCs repo ↩

2. Then it’d be the “Github and Zulip moderators”, probably? I don’t love the zlp part, but T-mods-github-zulip is getting long. ↩

3. the team repo doesn't support it AFAIC; but Zulip does support making whole groups member of another group, as far as I understand, so we could just make T-mods-gh-zlp the sole member/subgroup of mods manually, once, to create such an “alias”. ↩

4. For “@rust-lang/mods”, while I’m typing this up, I see a team description pop up that says… well … just “Managed by the rust-lang/team repository.” currently, but if it was self-describing there, as an “alias” of sorts, it’d be less confusing already maybe; or if we don’t want such style of pings in the first place, the relevant teams (under whichever final name) might self-describe there with some version of “please don't use this ping, do @rustbot ping mods instead” or so 🤔 ↩

[oli-obk]

I changed the teams repo structure back to what it was originally and effectively only created a sub-team that on github and zulip is represented by the mods team and group respectively.

This is a bit confusing considering the teams repo mods team refers to the github team moderation and zulip group T-moderation, but considering the alternative was confusing to ppl, too, ... doing a smaller incremental step forward seems best.

[steffahn]

Based on the current state of this PR, I think as a minor improvement still, for Zulip, you call it something like T-mods-venue instead to increase the consistency of the managed groups naming structure, and then leave changing the mods group up to one-time manual configuration (as long as the automation does not have this capability yet) of making the whole of T-mods-venue sole member of it. This means everyone viewing mods will immediately see that it’s “T-mods-venue” who’s in that group, and also the description, which currently already says “Moderators for Zulip itself; does not correspond to the Moderation team.” (which could also be manually updated in case we want to mention the “Venue moderation” team there).

(how that would look, without further changes to the team description)

---

I think actually for Github a similar approach could potentially work eventually, making mods set up (manually, assuming lack of automation support) to have some “mods-venue” as sole child team, but I’m less sure of the exact consequences and quirks of child teams on Github¹, so IMHO, it’s reasonably possible to postpone this sort of restructuring and call them mods next to moderators for now [and also wait for how well it turns out working for Zulip].

Another very reasonable subsequent step could also be to make the teams repository automation be able to attach a more informative/useful description to the teams it creates/manages than only the current “Managed by the rust-lang/team repository.” tag. For example, the full website name of the respective team could be mentioned here; and/or also the teams-repo name of the team (which should hopefully always match the file name) would fit here quite well, which would add a mention to the teams-repo’s mods-venue tag/name in the description rust-lang/mods.

Footnotes

1. For example, I could not yet figure out from online documentation whether or not mentioning a team would notify child team members, too. ↩

[pietroalbini]

infra-admins approval

[oli-obk]

@marcoieni the feedback has been integrated and this is ready now

[traviscross]

Looks good to me. Thanks to @oli-obk for pushing this all forward.

Let's indeed get this merged.

[steffahn]

Why is @rust-lang-owner in @rust-lang/moderation now? 🤔

---

Edit: Apparently:

When you create a new team, you automatically become a team maintainer without explicitly adding yourself to the optional array of maintainers.

it’s automatic/default from GitHub; presumably the bot will then be removed the next time any PR is merged? …fun system; should I open an issue?

Edit2: Oh not even that long – there are regular scheduled runs, too!