Adds mod guidelines for new Hubs relevant rule

[hobbs-Hobbler]

What?

Adds moderator guidelines for a Hubs-relevant rule for the Hubs Discord original or first posts.
Includes examples of what does and does not follow the rule. Also includes moderator guidelines on channels where enforcement should not be as strict.

Why?

We occasionally see metaverse, crypto, other platform posts, or posts where any connection to Hubs seems missing. Making this a server rule for all members will help enforcement because especially new members will have just agreed to it upon joining. Therefore, members can be held to this rule. Moderators can, if they have to, remove posts or at least minimally ask the original poster to edit/add Hubs relevance to the post. Moderators should check out links, and/or investigate the posting member, and remove posts if they are not relevant to the Hubs community.

Note: If discussion approves adding this as a Discord rule, that will need to be done at Discord separately as:
12. Make posts relevant to Hubs

An alternative idea floated in discussion is that Hubs relevance be added to rule #3. "Use appropriate language. This is a professional environment."

There are two key changes included in this rule:

1. The post must be obviously Hubs related OR the posting member must make it relevant by adding context to their post (usually this will be added text) that makes the perceived connection between Hubs and the content clear.

2. It places some responsibility on the Moderators to keep the rest of the community safe by checking links, which might be spam, or by investigating the posting members by using publicly available data.

Limitations

Encourages moderators to step in and take more action than they have been used to.
This rule is not meant to conflict with any prior Moderator guideline. If anything, it should be a stronger policy reason to delete questionable content.

Alternatives considered

Current Discord moderation guidelines are good and come close to addressing non-Hubs content. A Hubs-relevant rule would be required of all members and therefore would put some of the burden on the members following the rule, not just Moderators making decisions.

Open questions

None at this time

Additional details or related context

Per conversation, this change would need an announcement and a change to the Discord rules.

Discussion on the following text has already occurred because it was placed inside the commit-- see edits immediately following. The text is now removed from the commit.

Moderators could delete posts, then directly message the member that the original poster is welcome to re-post if they add context about connection to Hubs. If the member refuses, the original post stays deleted. If a member posts repeatedly, is messaged about relevance, and does not re-post, the Moderators could take this as a reason to remove the member from the server. All this could be documented in the admin private channel.

[EDIT: There has been discussion on the fact that once a Discord post is deleted, it is gone; it cannot be retrieved by a moderator or admin. There are times, however, when a to-be deleted post would be captured (cut-and-paste of text or screen captured) and the content of the post could be either re-presented to the member to re-post themselves OR the moderator could re-post with a text credit to the member. So there are ways around the problem of something being deleted and then re-posted.

Further, there has been discussion and agreement on "extreme cases" (very egregious posts which should be deleted) and "confusing cases" (where the moderator truly does not know what to do and leaving a post up might cause harm). These are likely to really rare. Writing rules for edges cases seems like a waste of time. Therefore, discussion these possible situations is ended. All of the prior existing moderator guidelines do a good job of guiding moderators through most situations.]

The random (and off-topic?) channel should have a wide leeway for posts not related to Hubs. Still, all Discord server rules apply. Most of the posts we’ve seen that have been deleted are blatant server violations. When in doubt, it is safest to take a post out of public view while it is being discussed with other Mods.

[EDIT: discussion did not favor pre-full deicison deletion. Therefore this text represents discussion, not decision or counsel.]

[DougReeder]

I think this just makes explicit what has been implicit. No need to get agreement from users.

[Exairnous]

I like this mostly (especially the examples), but there are a couple things.

1. The text you're proposing shouldn't be phrased as a suggestion. Having it in a pull request already makes it a suggestion, so you should just include your finalized wording in the document itself and leave all the rationale and discussion to your PR description and the PR comments.
2. Could this be reformatted within a bullet structure to fit the style of the rest of the document?

[Exairnous]

It might be helpful to include this link down here as well (it's from the malicious content section).

Suggested change

	**Moderators are responsible for doing some research about a post to see if it is related to Hubs**; they should try out links in a safe manner. The onus of proof is not entirely upon the original poster.
	**Moderators are responsible for doing some research about a post to see if it is related to Hubs**; they should try out links in a safe manner (https://urlscan.io/ can be used to check shortened links). The onus of proof is not entirely upon the original poster.

[hobbs-Hobbler]

I incorporated this, thank you.

[Exairnous]

All this could be documented in the admin private channel.

Here is the correct place to document all this, although I would probably say the repeated spam guidelines apply to the member posting repeatedly.

[hobbs-Hobbler]

Modified this text out of the commit and into the PR, with notation that this text was discussed.

[Exairnous]

When in doubt, it is safest to take a post out of public view while it is being discussed with other Mods.

While I agree that's the safest thing to do, as far as I know we can't put posts back, so I think I would only remove a post while it was being discussed in an extreme case.

[hobbs-Hobbler]

I possibly disagree; I think extreme is not the only use case. I think Moderators could be truly confused and they should also have the leeway to delete the post.

I don't think the consequences of removing a post are severe here. If a Moderator removes a post (and fully documents why) and then the result turns out to be that the the post was OK, the Moderator can do one of two things:

1. Directly inform the community member that they can re-post, of course, with an apology, and give them a copy of their post text, if need be.
2. Offer to re-post for the community member if they cannot re-post or give a reason why they cannot (like, I'm traveling and cannot do it, can you please?).

Since I've seen both of these behaviors happen in other communities to no deleterious effect, I think it's fine to lean towards deleting. It does send a signal to the community that questionable posts are removed...even if their final status is not yet determined.

[hobbs-Hobbler]

After discussion, it was agreed that both examples: extreme cases and confused moderator cases would be rare and writing rules for rare situations is not a good use of rules; it might create far too much granularity for a moderator to know what to do. Therefore, the advice to delete pre-emptively is dropped and instead the moderators can follow the rest of the existing guidelines.

[Exairnous]

I would agree that this change only needs an announcement.

For the record, I believe the Discord rule modification we're looking at to accompany these guidelines is this (changes are bolded):

"3. Use appropriate language and keep things on topic/relevant. This is a professional environment."

[hobbs-Hobbler]

1. The text you're proposing shouldn't be phrased as a suggestion.  Having it in a pull request already makes it a suggestion, so you should just include your finalized wording in the document itself and leave all the rationale and discussion to your PR description and the PR comments.

I struggled with phrasing this as a suggestion and went back and forth including and not including that but here was my reasoning: I was actually striving for discussion, knowing that the 'final version' of what would show in the policy would not be this wording. I didn't understand that it is OK to assume that most of the discussion will happen within the actual PR "Conversation" tab and the discussion didn't have to be documented inside the PR itself in the form of proposing files to be changed. I interpreted the commit and PR guidelines perhaps as "strict" (meaning the wording has to be cut-and-dry, not really inviting discussion) when I probably should have interpreted them as "specific" (meaning they can include a request for discussion if they also include the cut-and-dry first). I am focusing on discussion step and NOT on the final version step...I realize now from these comments that y'all want more of final visible version at the first submission. That feels less like a discussion, but OK.

2. Could this be reformatted within a bullet structure to fit the style of the rest of the document?

I'll try. Bear in mind that I did not see the md of the bullets prior to submitting so I have to somewhat guess what is going on here.

[Exairnous]

@hobbs-Hobbler
Ah, I see the confusion here. No worries, and thank you for explaining (this is actually really good to know and something to note for the onboarding docs).

A PR doesn't have to be all figured out at the beginning and/or a "final version", but it does need a concrete implementation of an idea. Basically, a PR is a proposal. You're saying, here is a change I think we should implement and why I think it it should be done. It mainly consists of the actual changes you're proposing, a high level overview of those changes, and the reasoning of why you think this should be changed. So yes, a lot of them will be pretty close to a final version, but it's perfectly fine to start a work-in-progress PR and collaborate with people on it too. Such a PR's description might be structured in a fashion similar to this:

What:
Basic rules and examples for keeping posts on topic.

Why:
We've been getting a lot of Discord messages with a tenuous or non-existant relation to Hubs; this will serve to provide a recipe for diagnosis and response by moderators.

Limitations:
Only the basics have been covered so far. The rest needs to be sorted out through discussion on this PR.

Alternatives considered:
Preventing users from posting links and updating custom word block lists to catch more off topic messages, but this could severely limit conversations on legitimate topics and block lists will always miss things.

Open questions:

• How many times should we warn users?
• Should users be kicked or banned or both?
• Do we timeout the users at the beginning, if so how many warnings in?
• Example 5 is ambiguous, does anyone have an idea for better wording?
• Etc.

Additional details or related context:
The guideline changes would accompany the following rule change in the Discord server (change highlighted in bold):

3. Use appropriate language and keep things on topic/relevant. This is a professional environment.

Note

PR descriptions can (and often should) be updated as things progress.

and commits might be structured over time like so (these are simplified for brevity and the dash is used to separate the what and the why):

• add initial set of rules and examples for keeping posts on topic - standardization
• remove example X - it was extraneous
• Change number of warnings from 3 to 2 - 3 warnings was found too lenient
• Add example Y - this situation wasn't adequately covered yet
• Reorder examples to flow better - example 5 is closer related to 2 not 6
• Add message template for 3rd violation - the 3rd violation has a timeout, so it needs a separate template
• Change message template for 3rd violation to be harsher - fits the offense better
• Change message template for 3rd violation to be gentler - last change was too harsh and oversteps

And most of these commits would be the result of discussions in the conversation tab and/or comments on lines in the individual files.

The main thing with commits and PRs is to keep them clear and descriptive, so "specific" is a good word for it.

Think of GitHub like collaborative storytelling. You're proposing a plot line/twist and then it gets discussed, modified, refined, until it's ready to be added to the book; then once it's ready, it gets written into the book. The commits themselves can also be compared to a story (the story of writing the story), and only need to be clear/descriptive (so the reader can follow along and know what the writers did and their motivations for doing so).

If you really don't have an implementation in mind and just want to have a probative discussion to determine an initial implementation (or prefer to keep the PR short/focused, with comments being mainly about implementation details such as grammar, and have the proposal/discussion elsewhere), then it's probably better to open an issue about it, and then open one or more PRs once it has been decided what they should do. An issue like this is usually referred to as a design task (especially if the general change has already been approved). Here's a somewhat good example from the Blender project: https://projects.blender.org/blender/blender/issues/123332 (design tasks are more useful for code changes because you can have discussions on how the change should work in the design task and have the PR discussion focused on bugs/optimizations of the implementation of the change).

Note

I'm generally of the opinion that design/proposal tasks/issues are mainly needed for bigger and/or controversial changes (and are required for those), but there's a lot of flexibility/leeway on this topic and a lot of differing opinions out there (so if someone wants to get consensus before starting work on something, they are more than welcome to open a proposal issue first).

I'll try. Bear in mind that I did not see the md of the bullets prior to submitting so I have to somewhat guess what is going on here.

Okay. You should see the bullets just above your additions. Asterisks are used for the top level bullets and dashes are used for sub-levels (this isn't a requirement of markdown, but it's the style I went with for this document).

[hobbs-Hobbler]

"3. Use appropriate language and keep things on topic/relevant. This is a professional environment."

The trick is saying to keep things on topic/relevant means that the community member can decide what is on topic and relevant. This phrase would be improved if it had "to Hubs" tacked on the end, I think.

[hrithikwins]

"3. Use appropriate language and keep things on topic/relevant. This is a professional environment."

The trick is saying to keep things on topic/relevant means that the community member can decide what is on topic and relevant. This phrase would be improved if it had "to Hubs" tacked on the end, I think.

we can also give them the links like https://dontasktoask.com/ or https://nohello.net/en and we can make our own website guidelines with these examples as mentioned in one of the post above, using AI tools for the content would give us some good insights

[hobbs-Hobbler]

we can also give them the links like https://dontasktoask.com/ or https://nohello.net/en

I like the suggestion of giving them links!

The more I think about Rule #3 though, it is focusing on word choice/language. Encouraging folks to stict to Hubs-relevant posts feels like a separate idea.

I was thinking this could be a new rule:
#12. Make posts relevant to Hubs.

[hobbs-Hobbler]

I'm really glad that no one is counting my commits.

[hobbs-Hobbler]

Fresh review please and thank you, @Exairnous