Document guidelines for accountability expectations for all members of the TSC and CommComm

[mhdawson]

This issue is to discuss/document the expectations that we have on our TSC, CTC and
ComCom members in addition to those outlined in the existing
code of conduct.

It is important that members of these groups act in a way that not only complies with the code of conduct but in a way that both demonstrates support and strives to avoid potential impression that those helping to lead the efforts of these groups and Node.js community feel otherwise.

It is important that we document these expectations so that they can be communicated to members as they join these groups.

I received a good suggestion that the board may have a doc that could provide a starting point. I looked and found nodejs/board#50 but I'll keep looking in case there is something more.

So which might apply include (adjusted of course to apply to TSC, CTC and ComCom):

+## Support of Board Decisions
+
+A Director must accept and publicly support Board decisions. A Director is encouraged to be an ambassador of the Foundation and, subject to the Director’s confidentiality and other obligations under this Code of Conduct, to promote the activities and actions of the Board with the Foundation membership and publicly. In doing so, a Director must stay faithful to the intent of the Board as expressed in its official statements, and should not reinterpret or re-characterize the Board’s actions to reflect the Director’s own view.
+
+While a Director has the right and responsibility to exercise independent judgment and to express dissenting opinions during Board deliberations, a Director also has the obligation outside the Boardroom to respect and support decisions of the majority, even when the Director dissented from the majority view. A Director who does not support a Board decision may express the Director’s opposition within the Board in an appropriate manner, but must not take actions publicly or with respect to the Foundation membership that have the purpose or result of undermining the decisions or actions of the Board. Acting otherwise may be in violation of a Director’s fiduciary and loyalty duties. Accordingly, a Director who intends to publicly oppose a Board action should resign the Director’s position on the Board before doing so.
+

Over the next few days I'm hoping we can work through some ideas and put together a draft of the proposed text.

@nodejs/collaborators

[stephenburgess8]

It is important that we document these expectations so that they can be communicated to members as they join these groups.

I wrote up my idea for a proposal that would provide a documented mechanic or standard by which issues relating to members breaking policy could be handled. In short, TSC members could issue censures and limit the responsibilities of other TSC members.

TSC is already able to do the things that I outlined in my proposal. However, I'm not sure it's common knowledge that that's the case.

The only place I can identify as being appropriate to document a method of handling disputes related to breaking policy would be in the Charter in Section XI: Escalation of Disputes and Code of Conduct Violations. I don't see another appropriate place for this, personally, unless another document were created to handle this specifically. Maybe that's what this issue is meant to address. If another document were created, what else would it address besides this issue, if anything?

I'm unclear on the standard of inclusion for the Charter. If it makes sense to outline how to select a mediator in the Charter, doesn't it make sense to include mechanism for holding TSC members accountable for following Node policies. And if it truly doesn't belong there, wouldn't it make sense to include it somewhere else? As always, thanks.

[mhdawson]

@stephenburgess8 thanks for the comments. I've not thought about where the content might go yet, more wanted to figure out how to document any additional expectations beyond following the CoC and how we'd deal with cases where those expectations were not met.

I think some of what you have in #318 (comment) is as starting point for what we might do if expectations were not met, but I think we need to document what those expectations are:

[stephenburgess8]

@mhdawson Thanks for the response. I have some context to provide as someone who has sat on non-profit committees and sat on a disciplinary hearing appeals board for over two years. If it's useful to you, please consider it. Otherwise, feel free to disregard. It includes my background, what I see as the problem domain, and what I see as the solution domain (in this case, what items could be addressed).

Read More

My Background

I've worked in several decentralized decision-making bodies and committees outside of tech. I was on the finance committee for a housing non-profit for a year. I was one of three members on my college's disciplinary appeals board and heard dozens of appeals of disciplinary cases over two years. I was on the college's Strategic Planning Committee. I was also a student government representative (senator) and on the elections committee there, and we handled cases where the elections bylaws were violated.

Problem Domain

Whenever a large group of people organize around a common goal, interpersonal issues will naturally arise. That's fine and normal. In hierarchical organizations, resolution is easy because it's simply an appeal to whomever is higher up. In decentralized groups that's not an option. Orgs usually have some small committee for these sorts of issues.

Appealing to mediation looks for a similar solution as in the hierarchical model. It seeks some sort of authority whose judgement cannot be questioned, but really that doesn't fit with a decentralized system like Node and OSS in general. Who qualifies to be a mediator? What if you don't agree with what they decide? How could an outsider have any better perspective to decide consequences when interpersonal problems arise than people knowledgable about the context?

Solution Domain

Define procedure for what happens in cases where interpersonal problems arise.

1. What are reasons that the question of accountability would come up (this is mostly the CoC, but there may be additional questions not covered in there. For instance, what happens when a member doesn't follow the Moderation Guidelines? That's outside of the scope of the CoC)
2. How can someone request that a case is heard?
3. What criteria does a complaint need to meet for it to be considered? What are some reasons why a complaint won't be heard?
4. If a matter is going to be debated, who/how many people will be involved in debating it?
5. If someone is found to have violated a rule, what kind of disciplinary action could they expect? It can help (a lot) to have different ranges of action that could be taken. If something small happened, the response could just be a written warning. If something significant happened, there could be some sort of probation. For really serious matters, then someone could expect to be asked to leave.
6. To whom can someone appeal if they don't agree with the decision?
7. How are both someone making a complaint and someone defending themselves protected from retaliation?
8. What happens when there's a conflict of interest, such as someone in the position of deciding being friends with a person?

Ultimately, the question should come down to people who use human judgment and knowledge of the context to make a decision, barring conflict of interest (friendship with a person). Developing a way to resolve minor problems prevents them from becoming large problems.

Maybe something like this seems like overkill. After all, the Node project is about coding. Well, setting culture from the onset is the only way to ensure that there's a good foundation for culture in the future. Who knows where Node will go, but it will definitely continue to grow and be an integral part of web development for years and years to come. Anticipate greater demands on your organization in regards to accountability. When it inevitably happens again it won't end up being a distraction for all the people who just want to code. Don't put process over people, but having some processes can head of problems before they arise.

When there's criticism coming from outside your group that accountability is lacking, a really powerful gesture of good faith could be addressing that. One way you could do that would be by developing process for TSC to handle questions of accountability. It's not an expectation beyond following the CoC but is the expectation of respecting the CoC.

I hope these considerations are useful to you as you make decisions in the coming weeks.

EDIT: Added details

[mhdawson]

@stephenburgess8 thanks for the insight. I believe (as I think you are suggesting) that if we can better document expectations, process and potential outcomes it will help everybody when the situation occurs.

I'm wondering if you can point us to the examples of other groups that have this documentation in place (if they are public) so that we can take a look at what has worked for them and potentially "borrow" what makes sense for us.

[stephenburgess8]

Sure. As I mentioned I heard appeals of disciplinary action at a university. Every university is going to have these processes and they'll be widely available. Your needs should be much simpler than these as your liability is way less than a university's. Still, the needs have gone beyond The Contributor Covenant and the conference code of conduct. I think this is a chance for Node to innovate and find a solution that others could also use. You could pull from other arenas to form a policy that is simple and effective and that others could replicate.

Stanford judicial process guidelines
MIT Committee on Discipline
Harvard student conduct
UW-Madison

Mozilla also has an excellent policy document here
Chromium

[hackygolucky]

excellent resources @stephenburgess8! I think there are a number of steps that need to be explicitly added to the Moderation-Policy in the form of a handbook–what the moderators are to do step-by-step so that folks feel comfortable and trust that a standard process is being followed. What great models to pull from.

As for leadership, which I take to mean the top-level committee members(all members of the TSC and CommComm), I believe that @mhdawson has a good start here but we need to address more than just directors.

An example of this set of guidelines for all leaders:

• Serve as ambassadors of the vision, mission and operating principles of the Node.js project.
• Treat all community members as professionals– with respect, consideration, and valuing a diversity of views and opinions. Strive to avoid preferential treatment, and hold everyone (including ourselves) accountable to the same set of standards. Everyone gets to speak up.
• Deal with issues directly with the person in question. Resist complaining about others in the project in a public sphere.
• Keep your promises. Your word is your bond. Commit to anything you can deliver upon.
• Be the model of accountability and leadership. Provide the example of ownership and stewardship that everyone can follow to success.
• Commit to ongoing development and learning best practices for governing.
• Critique ideas rather than individuals, discussing any concerns in person whenever possible, and taking responsibility for our statements by speaking as much as possible in the first person (“I” statements) rather than in the third person.
• We collectively and as individuals serve as role models to demonstrate the highest standards of ethical conduct.
• Remediate quickly when you realize you made a mistake. We should accept leaders are human, and they will make mistakes - however they should act swiftly to correct themselves. Most of the issues are fixable.

[mcollina]

@hackygolucky good list. I think we should add something among these lines: "Remediate quickly when you realize you made a mistake". We should accept leaders are human, and they will make mistakes - however they should act swiftly to correct themselves. Most of the issues are fixable.

[hackygolucky]

ah, love it. Amending @mcollina!

[mhdawson]

@hackygolucky great list !

[mhdawson]

Ok unless people have more suggestions I'll take what we have and submit a PR. I suspect there will be active debate but a PR is likely a good place for that to happen.

Since this applies to both TSC and CommComm, maybe the admin repo is the right place, either that or the moderation repo. Thoughts ?

[mhdawson]

Initial PR #339. Probably not the right place since it applies more broadly than the TSC, but still wanted to have a place where the discussion can continue.

[MylesBorins]

Adding TSC-agenda label so we can discuss this a bit more. Not sure if we have sufficiently accomplished this and we should discuss next steps.

[mhdawson]

For easy access, this is what has landed so far: nodejs/admin#12

[rvagg]

Can someone post a summary here of where we're at and a proposal of what they think the next steps should be? Seems like something that could lead to open-ended discussion in a meeting unless someone is prepared enough to present something; plus perhaps we could do a lot of it here anyway?

[Trott]

Can someone post a summary here of where we're at and a proposal of what they think the next steps should be?

Ping @MylesBorins!

Based on TSC conversation today, I think the main concrete thing right now is figuring out what (if anything) more needs to be done to detail moderation policy as it applies to TSC/CommComm folks. I'd guess that there won't be any desire for rules to be different for TSC/CommComm folks than it is for Collaborators. But I could be very wrong. Also, I could be slightly or greatly misrepresenting Myles's request, so his clarification/affirmation would be welcome.

[Trott]

(By the way, I've basically posted this question to the Moderation Team Slack and will report back when there is consensus around a response.)

[Trott]

Update (or non-update): I pinged the Moderation Team last week about whether the team wanted to propose what (if anything) more needs to be done to detail moderation policy as it applies to TSC and CommComm. No conclusions have been reached yet, but I'll keep trying to facilitate the conversation. More to come soon, hopefully.

[jasnell]

This appears to have stalled. Is there a next step or can this be closed?

[fhinkel]

Closing, feel free to reopen if needed.