Slack user moderation needs a new home (New SIG?)

[castrojo]

Slack user moderation feels out of scope for ContribEx, we've written up a bunch of policies and expanded the moderation team, but a new SIG is needed to drive this forward.

We'd like to ask steering to help us with defining scope for this. Most people in contribex are too busy to drive this and might include asking CNCF to help us find staffing for this, either through a member company providing a community manager or staffing directly.

[timothysc]

This might be a great example for what a CNCF proposal template looks like.

[castrojo]

Add more things here for context about the things we need to ask CNCF.

• A new position for a community manager to run a new SIG User Experience
  • Similar to Zach @ SIG Docs, we're not asking for moderators, we're asking for people who can build community programs around our user-facing properties
• Assumption of more administrative duties.
  • As a recent example, contribex had to go through the slack admin interface and remove inactive people, add active new ones, make sure they turn on 2FA, etc. Ideally it should just be filing a ticket with the CNCF service desk "Add Jane to slack admins" with a link to the github issue following the documented process.

New SIG would be responsible for (among other things):

Helping to moderate the user-generated content on Slack , since we have both users and contributors on slack, this would be a shared responsibility with Contribex

Currently all of our slack policies and teams are documented here:

• https://github.com/kubernetes/community/blob/master/communication/slack-guidelines.md
• https://github.com/kubernetes/community/blob/master/communication/moderators.md
• https://github.com/kubernetes/community/blob/master/communication/moderation.md

The slack team is currently working on automation for helping with a lot of this toil, and a bunch of the policy is already done, it just needs a place to live and a dedicated manager who would grow community programs around this. (Starting with slack but there are other user-facing properties that could use with some full time love).

For SIGs, there's no change as their requests are nearly always contirbutor related so there would be no process change there for them, they would continue to work through contribex.

[castrojo]

Also as a note, this SIG could possible take on things that are being formed right now, such as user groups and other things around the project, but for now I wanted to be cleanly scoped to just slack.

[coderanger]

Re-posting a cleaned up version of my message to the steering list from a few weeks ago:

Slack has been an enormous asset to our community, a point I think all of both the Slack Admins and SIG-ContribEx agree on. Having a space shared by both end-users and contributors helps to keep our community approachable and is an important part of the novice-to-user-to-contributor-to-leader pipeline that I feel is crucial to the continued health of any project. Currently, almost all people involved in running the Slack as either admins or advisors come from the contributor community. This makes sense, contributors probably like our community and care about or they wouldn’t be contributors. Also Slack has a very limited permission model, and to be a moderator of any kind requires at least “admin” level access, which is a very broad brush so people do need to be fairly trusted thus biasing us towards picking moderators from people we already know and trust.

However, this leads to an issue, that the majority of users on Slack are end-users rather than contributors, especially when it comes to the spaces and users that need moderation and admin attention. We have addressed the immediate need for additional Slack Admin team members, so we can set that to the side more or less. The long term problem is we still don’t have a conduit to the end-user community and so while I’m very glad that we were able to find moderators to fill the need this time, what happens in 6 months, or 12, or 18? Open source community work is draining at the best of times, and community moderation even more so. We need to plan for people stepping down and while SIG-ContribEx acts as a nexus point for folks interested in contributor experience so we can at least hope that even as some folks move up or on in our community, we as Slack Admins will always be able to find contributor-y folks if we need help with that part of the community. No similar thing exists for end-user spaces.

To put a very fine point on it, a bunch of the largest and most active Slack channels are either from cloud vendors (#gke, #sig-aws, #eks, #sig-azure), affiliated projects (#helm-users, #helm-dev), or don’t clearly belong to any SIG (#kubernetes-users, #kubernetes-novice, #kubernetes-careers, #events). I feel strongly that for these channels to continue, we need defined ownership and those owners should either be from the responsible companies when one exists or from a new end-user team in the broader cases.

We can discuss the specifics of if it should be a SIG or UG (or WG (or something else)) later, but the important part is that I think we need a *G-EndUserSupport to be created and we need to push hard for the major vendors who maintain a presence on our Slack should designate people to represent them in this group. From this group we can source new Slack Admins and other moderators as needed, and consult with them when issues that affect the end-user support experience.

[michelleN]

I've been working with Paris/Jorge on a proposal we can send to Steering for approval. Once it is approved, we can bubble it up to CNCF. I sent a draft to Paris and Jorge for review and am waiting on feedback before I send it off to the steering list. Brandon has created a process here for requesting funding but in this case we're requesting a bit more than money, so I am going to through steering to get approval.

[michelleN]

We need to post a description of the community manager role, someone to manage the user community - Jorge to follow up with moderators

[michelleN]

@castrojo would it make sense to track this work on the kubernetes/community repo and close it out here? cc/ @parispittman

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cblecker]

/remove-lifecycle stale

[parispittman]

take this to the next contribex meeting and get an update; if it's still a concern/open ended then steering will hear next meeting (april)

[nikhita]

/unassign @philips @michelleN

[nikhita]

/remove-priority important-soon
/priority important-longterm

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[coderanger]

I think we can probably close this out? Slack moderation seems fairly stable at this point.

[castrojo]

Agree, team is on the ball, if this needs to come up again we can re-address.