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

docs!: Volunteer's handbook #2700

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
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
130 changes: 130 additions & 0 deletions docs/about/handbook/community.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
---
title: Community Basics
---

Everything within our community must adhere to our conduct policies. This document deals with some trickier moderation decisions you may be wondering about.

[:material-book: Read our Code of Conduct](../../CODE_OF_CONDUCT.md){ .md-button .md-button--primary }

## Keep a Light Touch

In many situations, our community can be trusted to self-moderate. If you have been granted moderation privileges, you are empowered to make any moderation decisions you deem necessary.

However, it is better in many situations to enter a conversation and "cool down" the discussion taking place, or steer it towards a more constructive topic.
redoomed1 marked this conversation as resolved.
Show resolved Hide resolved

This is better than ending conversations, deleting posts, or locking threads in many situations. People can feel very passionate about some of the issues we discuss in our community, and this can lead to heated discussions, but in the end many such people only want to be a vocal advocate for their position, and can be guided to do so in a constructive manner.

Of course, conversations that devolve into harassment or other violations of our strict code of conduct should be ended immediately and reported.

## Identifying "Bad Faith" Comments

We should always strive to enter discussions in good faith. Likewise, we expect participants in our communities to engage in good faith as well. When reading comments in our community, comments which meet the following definition of "bad faith" should be removed:

1. The poster fails to provide reasoning for their criticism, and is unwilling to engage in a meaningful discussion.
2. The poster presents their criticism as factual, when it's really a matter of opinion.
3. The poster presents their critisicm as factual, when it's actually false or misinformation.
4. The poster is not looking for anything to be improved, they are simply spreading negativity.
5. The poster is speculating, but presenting their conjectures as informed or factual.
6. The poster engages in ad hominem attacks against us, community members, or other communities.

You should **never** close topics or remove comments simply because you personally disagree with the topic or direction of the conversation.

## Forum Organization

Generally speaking, this is what's most important in order for readers to comfortably read our forum:

1. Clear, concise topic titles
2. Thoughtful discussions

What is *less* important:

1. Proper categorization and tagging
2. Every post being perfectly on-topic
3. Removal of duplicate posts

These things are *good*, but they are not critical for our forum to function effectively. You are empowered to fix these things, but if you have any doubt that you are making the right changes it may be better if you hold off on doing so, or get a second opinion.

Generally speaking, the forum is divided into two overarching sections:

- **General Privacy Discussions:** Where privacy-related topics and news are discussed, where people ask questions
- **Site Development Discussions:** Where we talk about making changes to this website and our organization

A good rule of thumb when deciding where a post should go is whether the post would really benefit from or require a response from the Privacy Guides team specifically. We treat [site development](https://discuss.privacyguides.net/c/site-development/7) posts as an issue tracker, and strive to respond to and eventually answer/resolve every post in those categories.

General [privacy](https://discuss.privacyguides.net/c/privacy/4) discussions on the other hand can be responded to by *any* experts within the community, and may be more open-ended.

### Low Effort Posts

Posts which...

- Duplicate an existing topic
- Ask a vague, open-ended question without adding their own opinion to the discussion
- Don't provide enough information to have a meaningful conversation
- Discuss something completely off-topic for our community

...can generally be [unlisted](#locking--unlisting-topics).

### Where Should Tool Discussions Go?

This is a tricky subject which essentially requires you to use your best judgement. At the end of the day, the [tool suggestion](https://discuss.privacyguides.net/c/site-development/suggestions/6) category is for discussing tools which someone might legitimately argue should be added to the website. Even if the community disagrees and we mark the tool as a "rejected" addition, it serves as a valuable reference point in the future and allows us to re-open discussions if circumstances change.

For example, a post evaluating [*CalyxOS*](https://discuss.privacyguides.net/t/calyxos-android-rom/11614) would be posted to the Tool Discussions page even though it does not *currently* fit our [Android ROM](../../android/distributions.md) criteria. This is because it is frequently recommended in various privacy groups, and the discussion is relevant to our other Android ROM and criteria discussions.

On the other hand, it is more appropriate to have general discussions about some tools in the privacy discussions section, especially if those tools are not widely recommended for their privacy-protections or are highly unlikely to be included in the site.

For example, a post discussing the privacy problems and benefits of *Google Chrome* would not warrant a *Google Chrome* tool suggestion topic being made to fully evaluate it. Discussing privacy-relevant topics in non-private tools is on-topic for our general community, but does not necessitate any team feedback.

Posts that ask open-ended questions about a tool without adding any opinions of their own, like simply "what do you think about the privacy of *x*?" can usually be closed as low-effort, but consider our guidelines on [closing topics](#locking--unlisting-topics) below first. Particularly, keep in mind that if a significant discussion has already occurred, it may be best to leave it as-is. Oftentimes, you should ask the poster to consider posting it to tool suggestions alongside an explanation of why they're personally considering it in the first place, so that it can be properly evaluated by the community.

### Question Posts

Whether a post belongs in the questions category comes down to whether the question is specific, that is, whether the question in theory has a "correct" answer that can be selected. Open-ended questions that are only intended to spur discussion likely belong in the general discussions category instead.

**Specific questions** about tools can be asked in our questions category, but you should consider the following:

1. Specific questions about tools we recommend are allowed
2. Specific questions about tools we don't recommend *because there is no category for them on the site* are allowed
3. Specific questions about tools we don't recommend might be off-topic for our community.

This last point requires you to use your best judgement. For example, a question asking how to set a new tab page in Google Chrome is clearly off-topic, because we are not a tech support community.

### Duplicate Topics

It is very easy to find whether a post is a duplicate in most cases if you select the **Related** tab below the post, instead of the default **Suggested** tab.

Posts which are exact duplicates can usually be [unlisted](#locking--unlisting-topics), with a link to the topic that it duplicates.

One exception includes if the post already has significant discussion in the replies. In this case, read the discussion and decide whether it would still make sense if the entire discussion was appended to the existing discussion.

- If it would make sense, it's probably acceptable to merge the topics and unlist the new one.
- If it would be confusing, it's probably best to leave both discussions as-is.

Posts which are merely similar can be merged, but only do so if the resulting single topic would make sense. If the conversations have diverged enough, it is okay to leave both discussions as-is.

### Splitting Topics

Try to avoid splitting topics, unless you can do so in a way where the resulting topic both makes sense as a standalone discussion, and is clearly distinct from the original post.

Oftentimes this is most appropriate for splitting off *specific questions* (see above) from larger discussions. Doing this is beneficial to the forum and for readers, because topics posted as questions are in a special Q&A format where an answer can be selected for easy future reference.

If you're only splitting off a handful of posts, consider whether the split would actually improve the reading experience. It is usually acceptable to let discussion topics veer off-course occasionally, as long as those comments don't commandeer the topic entirely.

### Locking & Unlisting Topics

Tool Suggestions, Guide Suggestions, and general Site Development posts should **always** be locked when they are tagged as "completed." This is because they use a voting system, where each user has a limited number of votes they can use at once, and locking the post returns any votes to readers.

Otherwise, these posts should almost never be locked or unlisted.

General discussion posts should usually be **unlisted** if they are duplicates. However, if significant discussion has already occurred, consider [merging](#duplicate-topics) them or keeping them both listed. They can also be unlisted if they are low-effort posts, but it is usually better to [flag](#flagging-posts) those posts instead of directly using the unlist method.

Posts should be **locked** if conversations are occurring that violate our code of conduct. Generally, posts don't need to be locked if there isn't a clear reason to immediately stop the conversation that is taking place. Unlisting is adequate in most cases.

### Flagging Posts

Even moderators are strongly encouraged to use the flagging system instead of directly taking action on off-topic or low-effort posts, or posts which violate our standards on civility, conduct, and spam.

Users who have Trust Level 4 (all team members) will have their flags take effect to hide the target post immediately. We have specific team members dedicated to *resolving* community issues on a permanent basis, who will be able to take action based on those flags.

The flagging system also allows us to directly communicate the poster via the forum system to let them know why their post was flagged, and how they can potentially resolve the issue. When you take direct action on a post, it can sometimes be unclear why that action occurred.

People with elevated moderator access will be able to take action on a flag directly during the flagging process by using the *Take Action* button while reporting. If you do not have this access, your flag will still act to hide the post in question for later triage.
Loading