Establishing a communication channel for embargoed communication

[refack]

From time to time we wish to discuss information that is embargoed for various reasons.
At the moment we have a "constitutional crisis" since neither our Charter or our Governance document have provisions for that. As a result we have been in violation of our own policy, and IMHO have a sub par communication on the way.

Charter 4.7

The CommComm shall meet regularly using tools that enable participation by the community (e.g. weekly on a Google Hangout On Air, or through any other appropriate means selected by the CommComm). The meeting shall be directed by the Individual Membership Directors. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.

We need to remedy that ASAP, and it seems like the solution is to establish a communication channel that is as good as GitHub, but allows embargoing certain conversations, until we can publish them.

As I see it the requirements are:

1. opt-in / opt-out of online communication.
2. Archiving so that it's possible to opt-in to offline communication, and have reference for newcomers.
3. Ability to publish conversations after an embargo is lifted, as thus fulfill our obligation to the community.

I have limited ideas for a solution myself:

• We can't use a private channel on https://node-js.slack.com, since the operators and admins have access to that, and they are not bound by the same policy we are.
• We could provision our own slack workspace (or cohabitate with other channels in a node.org managed stack).
• We could use a "google group" as it has an archive, so that newcomers can catch up on prior communication, and we can un-private conversations

If anyone has ideas please help!

[refack]

/CC @hackygolucky do you have ideas?

[Trott]

I'm not sure what exactly raised this issue on the CommComm side, but since this is also labeled tsc-agenda: Is there a problem using the private email lists for conversations that should not be public?

[hackygolucky]

Yeah, my understanding is that we already do this via our private email groups when necessary. I don't know how helpful it is for us to build our -more- mechanisms that encourage private conversation just be existing, as we have a private session in CommComm meetings when needed and the email list, and we try to encourage all other conversations to be public, right? I relate to the outcome that you want, but I think we already get this via email. Am I missing something here? Having a slack is great for more realtime conversations. If the discussion becomes something that needs to be discussed privately due to a sensitive nature(should be rarely and tends to be related to fiduciary concerns), then take it to email. Otherwise, CommComm members chatting in slack is great. Just be wary of what you should and shouldn't be discussing and on that rare occasion be helpful to remind others if that needs to happen in private. Separately, I'm not sure what you mean by "constitutional crisis", as we try to have a very lean charter, as that requires say and approval by the Board. Choices such as what tooling or medium we use for communications is definitely outside of the scope of the Board's perview and should be flexible for us to be able to change as needed. Understanding the scope of where we should be communicating sensitive information(i.e. we have been asked to not communicate publicly information disclosed by another party) makes sense to document as a best practice. Is that what you are referring to? Do you mean having rules similar to the Moderation repo that define scope of communications in certain situations?

…

On Tue, Oct 2, 2018 at 12:53 AM Rich Trott ***@***.***> wrote: I'm not sure what exactly raised this issue on the CommComm side, but since this is also labeled tsc-agenda: Is there a problem using the private email lists for conversations that should not be public? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#382 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB46oK6jZWbjJN3oDtvme2cAiWjTscwXks5ugvFcgaJpZM4W3kWC> .

[amiller-gh]

Agreed on all points above. I think email lists and private sessions fulfill our needs well and adding additional tools will only complicate things.

[mhdawson]

I'll also add that even if it is a bit more work with what we have, we don't actually want to make it too easy to communicate privately as we only want to do it when absolutely necessary.