doc: doc expectations on TSC and CommComm members

[mhdawson]

Moved over from https://github.com/nodejs/TSC/pull/339/files

[mhdawson]

@nodejs/tsc @nodejs/community-committee please review/comment.

[Fishrock123]

As posted in nodejs/TSC#339

I don't really this has significant value at the current time because neither of the following things actually exist...

• a Node "vision" / "mission"
• any set of "Node values"

IMO, it would be useful to actually have "Node values" first.

[mhdawson]

@Fishrock123 I agree getting those in place makes but I don't think blocking this on those makes sense.

[mhdawson]

adding to agendas for TSC and CommComm for discussion since github discussion seems to have tailed off and we need members to be comfortable with theses expectations.

[mhdawson]

@MylesBorins had volunteered to take a first cut at the values statement, and has asked that we have some time in the TSC meeting this week to discuss as well. I'd suggest we start with that as the basis for the "values" document.

[MylesBorins]

There is also a core values session being planned for the collaborator summit
https://github.com/nodejs/summit/blob/master/2017-10/agenda.md#2017-10-07-day-two

[rvagg]

That last paragraph doesn't seem to add anything helpful other than some vague suggestions that could potentially be interpreted in a very broad manner. We should avoid where possible laying down rules that are open to broad interpretation and just say clearly what is intended. The final paragraph seems to be trying to say something similar to the rest of the doc but just restating it in a very handwavy way. I could imagine it being used against members in ways that stray far from original intent. Plus, it's just unnecessary.

[rvagg]

A couple more thoughts:

• Needs definition of "leadership groups", perhaps just list what it's referring to?
• Probably needs some clarity around how this thing is administered; are the "leadership groups" themselves responsible for keeping each other in check? I'm not sure I can support this if it's just put in the hands of the Moderation team—taking on an enforcement role directly against leadership with such broad terms on top of what we already have seems quite risky and I'd personally prefer that leadership are corrected by, and held accountable to their peers.

[mhdawson]

At list point leadership groups are TSC and CommComm, I can clarify that.

[mhdawson]

@rvagg I think we'd want to leverage the moderation process for raising concerns, were discussion should happen etc but I think the current moderation governance indicates that the TSC and CommComm are the final decision makers outside of consensus. In this case I could see the moderation team making a recommendation (potentially with input from TSC/CommComm members of course) and then team in which the member making the decision to accept that recommendation or not.

[mhdawson]

Will look to update with recent comments soon.

[mhdawson]

Pushed update to incorporate latest suggestions.

Also I'd like us to discuss if we need to wait on the values to land this. The discussion was started in the collaborator summit but I get the feeling it may take a few months to close on that effort and I don't think its good for this to wait that long.

[mhdawson]

@jasnell @MylesBorins @williamkapke please take a look.

[dshaw]

@mhdawson This is looking good.

[mhdawson]

Pushed commit to address comments from @Trott

[refack]

/cc @nodejs/moderation - do we want to adopt this as well:

It is important that members of our leadership groups (TSC, CommComm), and
teams entrusted with public interaction (Moderation), act in a way that not only
complies with the...

[bnb]

@refack I definitely think it would be good for the Moderation Team to be added in this doc, but I think there's not a compelling enough reason to take the time to get +1 from everyone on the Moderation Team + make the change before shipping (we're essentially at consensus now, pending any -1 or requests to change).

I'd like to ask that we, the moderation team, take an action item of reviewing and PRing ourselves into this doc once it has formally been shipped 👍

[rvagg]

I have to record an abstention on this one unfortunately.

I genuinely like the intent behind this and it outlines what I think are good guidelines. However, I don't think it's a good idea for us to expand the amount of this type of enforceable conduct policy text without it being considerably more formally defined. There's a reason why "legaliese" is a thing
distinct to ordinary prose—because it has to be very precise so when it's applied it sticks as close as possible to original intent and spirit as possible. Leaving wide open the possibilities of interpretation could, at worst, lead to abuse and "weaponisation", and at best I fear will have both a dampening effect on open and honest communication and diminish our ability to attract and retain quality leadership.

Some examples of where this doc might be interpreted very differently depending on the who it was applied by and when (ignore what you think the original intent of these words is and consider a future detached from your original intent, perhaps long after you've moved on):

• "obligation to protect and be respectful of both the project and all other contributors". What does "protect" mean here? Who gets to decide what "respectful" is? Even the scope "contributors" is up for grabs here.
• The use of "external" and "within". This could imply some form of closed vs open space? Perhaps GitHub is "within" and Twitter "external". Or perhaps private communications is "within" and GitHub communication with non-leadership people is "external"? This is a window that could shift very easily depending on how you want to apply it.
• "highest standards of ethical conduct" Who gets to decide that? Can an accused claim ignorance of the particular definition of "ethical" being applied to them? What about the large disparity in cultural norms that feed into "ethics" given that we're a culturally diverse team?
• "Aim to remediate first and then discuss. If other members of the team express concerns about actions, acknowledge their concerns by stopping the actions in question and then discuss within the team to come to a common agreement." Could this be used as a tool to prematurely shut down discussion? Does it matter what "concerns" are expressed and what "actions" they refer to? It seems like any concern about any action could be raised and if the accuser in question doesn't immediately stop then they could be found in contravention of this policy? This could be an easy one to apply retrospectively if you were out to find guilt in someone you're looking to damage.

I know it's tempting to assume positive intent when thinking about how these things are applied, but I believe that's naive and experience both here and in other open source projects should make us be more cautious.

To be honest I don't even believe it's clear in this document whether it's even enforceable, which is a concern of itself: it says that leaders "must conduct themselves in a professional and respectful manner", but then uses the term "guidelines" to talk about the specifics. It then refers to its "guidelines" as "expectations". At the end it links itself to moderation enforcement and refers to itself as "policy". Are they guidelines or enforceable expectations? Is the list exhaustive for enforceable "professional and respectful" behaviour or could there be more that's determined by the enforcer(s)?

If this were framed strictly as "guidance" to leaders then I'd be an enthusiastic +1. Perhaps if we left it as "guidance" then parts of it could be formalised over time if and when we run into problems where simple "guidance" fails?

[mhdawson]

I'm going to go ahead and land with the @rvagg abstention noted and a minor tweak to add meetings as requested by @bnb.

[mhdawson]

Landed as c4eef09

[minexew]

Have the concerns voiced by @rvagg ever been responded to or addressed?

[keywordnew]

@minexew I'm sorry, I do not know. Possibly someone involved in this at the time would.

[Trott]

Have the concerns voiced by @rvagg ever been responded to or addressed?

@minexew I'm sorry, I do not know. Possibly someone involved in this at the time would.

You might need to be a lot more specific than "concerns voiced by @rvagg". Rod has five comments in this issue totaling over 1000 words. (That's a statement of fact, not a criticism. If someone has a lot of important stuff to say about an important topic, then saying it is the right thing to do. And I've certainly posted a lot more than 1000 words in plenty of issues.)

People would likely be more inclined to answer a more specific question.

[jakeNiemiec]

You might need to be a lot more specific than "concerns voiced by @rvagg".

Perhaps they are referring to the bullet pointed list of questions. Here are two of them:

• "obligation to protect [...] the project and all other contributors". What does "protect" mean here?

• "highest standards of ethical conduct" Who gets to decide that? Can an accused claim ignorance of the particular definition of "ethical" being applied to them? What about the large disparity in cultural norms that feed into "ethics" given that we're a culturally diverse team?

Added speculation to why this is being brought up now

[The issue that this PR stems from](https://github.com/nodejs/community-committee/issues/111) was recently brought up in several places in regards to [this](http://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html).

Despite that, I think the project is in a much better place due to efforts such as this PR.

[Trott]

I agree that the "protect" language can stand a little improvement and have opened pull request with a proposal. #129

I am not bothered by "highest standards of ethical conduct" although I wouldn't object if someone found better language than that.

It's worth noting that the "highest standards of ethical conduct" text is in a list of "general guidelines". To me, that suggests that it is aspirational ("We aspire to the highest standards of ethical conduct") and not prescriptive ("You will meet the highest standards of ethical conduct. If you do not, the following things will happen: ...") Perhaps that can be clarified (especially if I'm wrong about that!).

[rvagg]

I recorded an abstention, not a negative vote, so my concerns don't need to be addressed for this to move forward. This is not an area I'm interested in investing too much time on right now, particularly as I appear to be mostly alone in expressing concerns, so I'm happy to roll with the majority of the TSC who have voted for the adoption of this and see how it turns out.

I've recorded my fears and concerns, these are things that I believe are worth watching out for. Some of them are consequences that we should be able identify and remediate when they occur (and we agree are an unwelcome outcome).

There is possibility that introducing even more vague guidelines on top of what we already have will lead to consequences that we can't even measure. It's the lack of specifics that I'm mostly concerned about—enforcement of documents like this that don't deal in specifics can lead to abuse or simply flip-flopping depending on the current cultural mood or social media pressure. For instance, will it quell discussion on important topics? Will it hinder inclusion of certain types of people (personality, cultural background, language skill, etc.)? These are the areas that we have to be more proactive in considering.

These kinds of discussion is going to require a lot of maturity from us all (yep, including me), we've clearly not figured out how to do this yet but I personally feel more positive about where we are today in this regard. I hope that if people come from inside or out with concerns to express on these topics that they'll be delivered in the spirit of wanting to make meaningful improvements, and received in a spirit of openness to consider alternative viewpoints.