Slack lacks transparency

[williamkapke]

The Website WG appears to be using Slack to communicate (several references in their GOVERNANCE.md). While I am a HUGE fan of Slack and its productivity... it has a problem- lack of transparency.

See: Node.js Foundation's Guiding Principle

Slack allows for exporting logs- so something could be automated using that. However, you cannot get private rooms unless they are for compliance. See: https://get.slack.help/hc/en-us/articles/204897248

IRC logs, on the other hand, are archived for the Node.js channels @ http://logs.nodejs.org

/cc @chrisdickinson EDIT: I should have originally mentioned: I have no reason to believe any WGs are intentionally closing their communication.

[chrisdickinson]

The items listed in the first line of the linked guiding principles — "Project proposals, timelines, and status" — of the Docs WG are open. Sign-up is similarly open (though I admittedly need to do another onboarding run.) I'm happy to make historical logs available by request, or if you would like to set up automated logging of the Docs WG Slack that would be very helpful.

I note that the linked document does not make any recommendations with regards to tooling, and indeed does not prescribe that all communications happen in public venues (that is to say, the charter does not recommend "radical transparency," nor does it appear to require that WGs adopt such an approach.)

However, you cannot get private rooms unless they are for compliance. See: https://get.slack.help/hc/en-us/articles/204897248

FWIW, DMs via IRC are similarly hard to obtain records of.

[nebrius]

FWIW the inclusivity WG has a private slack channel as well. Our goal is to set up a mechanism so anyone can join the inclusivity slack, possibly via an automated mechanism, although some channels will always remain private.

The unfortunate truth is that it is better for the project for certain things to be discussed in private. A classic example of when we should keep things private is security disclosures, which there is a private communication mechanism for already. Transparency for transparency's sake in all cases has led to problems in the past, including a targeted harassment campaign by 8chan and KiA last November-ish.

That said, I think it's important to be as transparent about as much as possible, and any time we have a lack of transparency, there needs to be a very good reason for that lack of transparency.

[williamkapke]

@chrisdickinson Obviously people will chat via non-endorsed channels and there is nothing wrong with that. The problem is when an organization within the Node.js Foundation very openly displays there is private (non-legally required) discussions that ultimately cause product decisions.

It's a slippery slope back to the days of Joyent's Node.js.

[Starefossen]

As long as decisions stays in the open (eg. issues) I see no problem using Slack. Slack has been suggested multiple times as a means of communication throughout Node.

Also, your tone here is not most diplomatic and I think you could retain from your last sentence @williamkapke - everyone are doing awesome work here! Please keep in mind that your are not the one enforcing the rules put in place by the TSC.

[williamkapke]

@Starefossen I apologize if it seemed harsh. I was at a meetup in Mountain View last night and it was something that was brought up to me as I was championing people to try to get them involved again.

[Starefossen]

Thanks for the backstory on this! If the public perception is that some WGs are becoming less open in their communication we should definitely look into what may be the causing of that to happen. I have no reason to be leave any WGs are intentionally closing their communication.

While I as an engineer is very comfortable with IRC - I know that many others are not. I definitely see the convenience of Slack which its friendly UI, mobile apps and many plug and play integrations.

There are the notion of "public" Slacks where anyone can sign up, maybe that could put that in place for a cannon Slack organization for Node. Also, if we have one Slack org for Node we could make an automate a chat log export similar to the IRC-slurp bot for better transparency.

[williamkapke]

I have no reason to be leave any WGs are intentionally closing their communication.

Oh gosh! I actually really should have said that in my OP. 100% agree. I'll add an edit.

There IS an open Node.js slack community. I (also @ljharb) participate there and I even referred to someone that asked in the help repo. The big key difference, IMO, is that it is not under the control of the Node.js Foundation.

[rvagg]

I personally don't like Slack for use in our work around here, probably for the same reasons as you @williamkapke, there's a barrier to entry and it also has a strong sense of a walled garden and even if there's an "open signup", the signup process itself is still a barrier and requires a higher level of initial commitment for someone to dive in and find out what it's all about, at least on IRC you can drive-by and GitHub is even better because it's completely open.

But, we also want to make sure our working groups have a lot of autonomy and it's important that we allow for diversity in approaches to everything we do in order to discover the most optimal tools and processes. Perhaps Slack will win out in the end with some new open-view feature they end and it'll make sense for the work we do, or perhaps the groups that use Slack struggle to maintain a steady intake of new folks and suffer from slow attrition.

So for now, since Slack isn't strictly closed and it is possible to be "transparent" to a degree, it's not something the TSC can really ask working groups not to use if they are finding it a useful tool.

[mikeal]

Wait, the website uses Slack? Since when?

[MylesBorins]

@mikeal not the website, the documentation WG

[williamkapke]

I hope "radical transparency" doesn't sound like the goal- and I hope "radical autonomy" doesn't either. I agree that groups/committees should have autonomy... to the extent that the board & TSC allows.

So, when would the TSC step in? I mean what if, for example, a group wants to move to Bitbucket? I mean, maybe it would be a better tool for them... but it wouldn't be pleasant for the community. There are some things that are assumed- but not required.

I propose that the TSC should have some guidelines for committees/groups to follow to ensure the Technical side of the Foundation:

• Satisfactorily meets the requirements of the Governing Documents, and
• Offers assurance of 'operating transparently, openly, collaboratively' to the community

[jasnell]

Closing given that there's been no further discussion in nearly a year. Any further discussion on this should likely be directed to the Community Committee