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.

Sign up for GitHub

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

Create a Moderation Team #42

Closed
wants to merge 1 commit into from
Closed

Create a Moderation Team #42

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
128 changes: 128 additions & 0 deletions text/0000-moderation-team.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
- Title: `moderation-team`
- Authors: @energyburn, @lavalulu, [@lehnberg](mailto:daniel.lehnberg@protonmail.com)
- Start date: `Feb 11, 2020`]
- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000)
- Tracking issue: [Edit if merged with link to tracking github issue]

---

# Summary

[summary]: #summary

This RFC sets out the initial structure of the moderation team.

# Motivation

[motivation]: #motivation

1. **Uphold Grin's Code of Conduct.** (CoC) To make people of any background feel welcomed to contribute to Grin in a friendly environment.
2. **Encourage positive behavior.** Strive for the community to be excessively polite and nice to each other, even when there are disagreements.
3. **Act as an independent and neutral voice of reason.** Moderation will always be subjective, but moderators will be loyal to the CoC and not to specific members or groups in the community.

# Community-level explanation

[community-level-explanation]: #community-level-explanation

## Areas of responsibility

- Online community moderation. Rulings on kick/ban decisions with motiviations, acting as escalation point for members of the community to report CoC violations to.
- Live events moderation. The same as for online, but explicitly also for live meetups and conferences. Ensure that the CoC is referred to at Grin events, and that there’s a contact on the ground where incidents can get escalated to. This does not need to be somebody in the moderation team.
- Event and community accreditation. Communities and events who adopt the guidelines of the moderation team will be endorsed and promoted on the Grin forum and website. Those who do not abide or fail to enforce proper moderation will not be listed in community materials.
- Team admin. Discussions, policies, procedures, rules, guidelines.

## Bootstrapping team

[tbd]

## Team membership

Being part of the moderation sub-team is a privilege, not a right. Applicants are vetted, and successful additions to the team are expected to actively work on moderation as required. Members will be displayed on the community’s Github, forum, and website.

### Pre-requisites

- Endorsing the Code of Conduct.
- Strong written communication skills.
- Proven track record of being polite and nice.
- Willingness to put in time and effort into moderation.
- Being a moderator in an existing well moderated Grin community is a plus.

### Joining

- Applicants apply at tbd.
- Applications are vetted by the existing moderation team members.
- Moderation team decides who it includes.
- Core team has a veto right to new members (a right that’s not expected to be used frequently).

### Working

- There is no fixed term for membership.
- Procedures for how to rule on moderation is up to the moderation team to decide on.

### Leaving

- A moderation team member can resign at any time.
- Inactive members can be removed by other members of the moderation team.
- The moderation team can decide to remove members who act inappropriately, make wrong rulings, or who are not good representatives of the moderation team.
- The core team can step in to arbitrate or rule on matters of contention, if this is requested by the moderation team.

# Reference-level explanation

[reference-level-explanation]: #reference-level-explanation

# Drawbacks

[drawbacks]: #drawbacks

Why should we _not_ do this?

# Rationale and alternatives

[rationale-and-alternatives]: #rationale-and-alternatives

- Why is this design the best in the space of possible designs?
- What other designs have been considered and what is the rationale for not choosing them?
- What is the impact of not doing this?

# Prior art

[prior-art]: #prior-art

Discuss prior art, both the good and the bad, in relation to this proposal.
A few examples of what this can include are:

- For core, node, wallet and infrastructure proposals: Does this feature exist in other projects and what experience have their community had?
- For community, ecosystem and moderation proposals: Is this done by some other community and what were their experiences with it?
- For other teams: What lessons can we learn from what other communities have done here?
- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.

This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other projects.

Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC.
Please also take into consideration that Grin sometimes intentionally diverges from common project features.

# Unresolved questions

[unresolved-questions]: #unresolved-questions

- What parts of the design do you expect to resolve through the RFC process before this gets merged?
- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

# Future possibilities

[future-possibilities]: #future-possibilities

Think about what the natural extension and evolution of your proposal would be and how it would affect the project and ecosystem as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and language in your proposal. Also consider how it fits into the road-map of the project and of the relevant sub-team.

This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related.

If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.

Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information.

# References

[references]: #references

Include any references such as links to other documents or reference implementations.