[PROPOSAL] COMMUNICATIONS.md and Public Slack

[nknize]

Adds new COMMUNICATIONS.md file describing the OpenSearch Project communications
policy and guidelines. First commit includes policy and guidelines for upcoming
slack workspace.

closes opensearch-project/.github#63

[ke4qqq]

So, I could understand requiring maintainers to use 2FA for access to GH and making commits. And while I wholeheartedly endorse 2FA everywhere, this feels like friction and we're appealing to authority (security) to justify the friction. While I'd love everyone to be perfectly secure, I am not sure the juice is worth the squeeze. At a minimum, we should be looking for whether this is enough friction that folks don't continue with the sign up process.

[nknize]

This is a good point. The 2FA intent was to minimize Griefers / trolls. Maybe enabling it is premature at this point since we're just starting to build a vibrant community? I'm certainly not opposed starting w/o 2FA and enabling if slack bombing becomes a problem. Curious what others think.

[hyandell]

I don't think of it as minimizing malicious folk causing pain by trolling, I see it as stopping malicious folk impersonating others if they're only relying on a weak password.

[krisfreedain]

Wholeheartedly agree with 2FA on both the intent of minimizing trolls as well as a step to hopefully stop anyone from maliciously impersonating someone else. In a perfect scenario, we would be able to have people sign up with their GitHub accounts to truly identify who's who between the different area. (something I'm likely going to implement on the forum as an option)

[ke4qqq]

I'd encourage you to start with just #random and #general. Bifurcating where the community interacts prematurely impedes progress IMO. Wait until things are so busy that you need, and then slowly add channels as existing channels grow too busy and people complain.

[nknize]

We have pretty large activity on several OpenSearch repositories including a lot of dashboard communication which is abstracting the back-end from OpenSearch to accommodate other data providers. This was the idea behind separating channels for OpenSearch and Dashboards but not getting so crazy that we have a channel for every repository. On day 0 we're most certainly going to have a mix mash of discussions on #general with the existing opensearch and dashboard maintainers that I'm afraid will lead to back channeling to avoid noise.

Would a good compromise be to start with something smaller like #general, #core, #dashboards, #build, and a private #maintainers channel to discuss candidate maintainers?

[hyandell]

+1 to you both. Hesitate to plan your community, let it be organic, however if your community has already been organic in A.N.Other location, then mimicking the core of that makes sense.

[krisfreedain]

From a community standpoint, when starting out I would recommend the approach that less is more. Before I came over to the project - people would add a new category for every different plugin, etc - we now have 30+ categories on the forum, and people typically use about 5 of them. (and now I have a massive cleanup project to make it more functional)

[nknize]

Removing #maintainers and #project-build for now. We can add the build channel for buildbot failure notices later, and we can add a private #maintainers channel for new nominations later.

[wbeckler]

What about an #announcements channel that is expected to be low traffic, for major announcements such as new releases or significant deprecations or other important milestones? Given Slack's limitation of only one write-limited channel, this is one channel that needs to be set up out of the gate as an autosubscribe channel so as to avoid the need to ask people to subscribe to it in the future.

[nknize]

I like the announcements channel idea. I added it here.

[dblock]

Overall good, made a bunch of comments.

[dblock]

I would say "We kindly ask you to use your real name."

We can never enforce this, so I wouldn't bother.

[nknize]

Yeah I think this one was causing confusion so I'm going to remove it altogether. Slack administration settings allow configuring the workspace to use Full Name as the display name instead of a preferred shorter "Display Name". It's true this doesn't prevent someone from putting a bogus name in the Full Name but this is what was meant by "no anonymous display names are allowed." I don't think there's a problem using preferred shortened display names and if it becomes a problem we can discuss it then.

[krisfreedain]

We could also simply make the recommendation for people to use the same name they're already using on the forum or on GitHub. (also makes it easier to link people up between sites, which would be a good thing)

[dblock]

I feel like this is weird. Use whatever you want. Generally I don't love recommendations of what "not" to do, which is "don't use slack for technical support discussions".

Should this doc have a section on forums and their purpose as part of this PR?

[nknize]

Should this doc have a section on forums and their purpose as part of this PR?

I don't think so; that can be addressed in a separate PR.

Generally I don't love recommendations of what "not" to do, which is "don't use slack for technical support discussions".

I agree with this; the one wrinkle here is that the slack conversations are not searchable outside of the slack workspace. So if someone uses slack for technical support it will not be discoverable by the rest of the community. We can encourage folks to use the forum but if that's not documented somewher (like this "tips" section) it risks never being followed (just like forgetting to use slack threads to avoid the channel noise).

For now I reworded to explicitly mention this tip and encourage using the forum instead of making it sound like a policy.

[krisfreedain]

The community will likely see the forum recommendation as a good thing - when given direction of where / what to use, most will appreciate it.

[dblock]

This LGTM!

Could you please remove the auto-line-wrap at 80, none of the other markdown files in this repo have that and it doesn't matter to GitHub nor will anyone read these in a terminal because they are markdown, not text.

[dblock]

This needs a refresh/update/status of public slack, and discuss moving this into .github repo.

[dblock]

Let's revive this and move it to .github.

[wbeckler]

Should there be a section explaining who/how new channels get created?

[nknize]

This is just about ready to go. Maybe we time box to end of week? I can move it to .github after we agree and merge here. I don't want to close this and fragment the ongoing conversation history.

[nknize]

Should there be a section explaining who/how new channels get created?

I'm not sure we need that level of managing. I suspect people are going to create channels ad-hoc for side discussions based on rapidly moving features, and that's a good thing.

Keeping the PR here to retain history. We can move the doc to the correct repo after merge.

[dblock]

Looks good. Open a PR in .github and close this?

[nknize]

Thanks all!! I'm closing this PR and moving it to opensearch-project/.github#153. It will merge on approval.