Contributor Experience is going to take on the moderation of non-sig/wg community mailing lists. This includes k-dev and k-users. We need to write down some basic moderation guidelines for it - the how, who, and what we do. One of two things: 1-new file under /communication for this or 2-combine with slack guidelines for a main moderation doc.
/sig contributor-experience
I like the idea of a single common moderation document with the intent and philosophy of moderation and then sub-bullets for implementation details specific to doing moderation on a mailing list, slack, or other communication techs.
Something like this perhaps: https://support.mozilla.org/en-US/kb/moderation-guidelines
Why not moderate the sig/wg lists also?
We would need to be set to admin on all of those lists. If that's the direction that we should go in, we'll need to get all of the chairs/leads to give us permission and also figure out how to divvy up the work since there are so many lists.
We should do that. It would reduce the bus factor, also.
https://github.com/kubernetes/community/blob/master/communication/moderation.md is our first draft for it, is there anything specific we need to add?
We need to add the mailing list guidelines and specifics on moderation. ie - add us to their mailing lists as owners, lock the thread before banning/removing someone so that no replies come in, etc.
The ownership bits are covered here: https://github.com/kubernetes/community/blob/master/sig-governance.md#creating-a-mailing-list
I'll work up a PR on closing a thread.
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
This is completed.
Most helpful comment
Something like this perhaps: https://support.mozilla.org/en-US/kb/moderation-guidelines