Some of us in the web standards community have become concerned over the occasional lack of respectful and professional conduct in standards discussion. A set of Chrome team members set out to work with the community to develop the following insights, and we hope to encourage the broad adoption of more respectful interactions. If you have suggestions on how to improve this document, please file pull requests or issues on this repo.
We believe the development of successful, open standards for the web platform requires safe, inclusive and productive venues for discussion. In particular, standards discourse must include and be respectful of diverse perspectives. At all times, our interactions should be respectful, professional and constructive.
This document outlines guidelines that we believe are necessary to encourage constructive conversation, and ensure safety and inclusiveness for all involved. This is not an attempt to rewrite Codes of Conduct in venues; we are just indicating that we expect organizations to abide by their Codes of Conduct. We can have better, more inclusive outcomes for all if we improve the processes and interactions in standards groups.
*This is a standard of behavior we (the Chrome team) expect of ourselves, as well as of others, in our interactions in standards venues. We welcome input in refining these expectations of behavior, and expect to call out violations of these expectations as counter-productive (including if it is Chrome team members failing to meet these expectations).
We believe:
- Standards discussions should adhere to standards organizations’ Codes of Conduct
- Participants should follow some simple golden rules for standards discourse
- Be respectful, and recognize the validity of others’ points of view
- Don’t assume, ask for confirmation instead
- Look for (and communicate) basic requirements, clear use cases and problem statements
- Take actions that are constructive, and move towards consensus when possible
- Take responsibility for your own words, work to reduce hostility, and be intentionally welcoming and inclusive
In particular, we on the Chrome team will enforce these expectations for our own team members, and Chrome team members will be encouraged to exit discussions that persistently fail to adhere to these expectations. If violations persistently fail to be corrected, we will cease participation in the discussions until they are corrected.
In short, we want to have more professional, respectful and inclusive discussions. Codes of conduct have not been consistently applied, and we should all expect them to be - we all have a responsibility to ensure safe, respectful venues. If any behaviors do not meet these standards, we plan to call them out, and we expect to be asked to improve in turn if we fail to live up to these standards.
*If Googlers are failing to live up to these goals, we will provide support to correct that. We want to hear about it and make it better. For both of these purposes, we have established an external alias to ask for help: the web standards team ombuds (web-standards-ombuds@google.com). *
We intend to apply these conditions to any and all standards discussions in which Chrome team members participate, and expect everyone participating to meet these standards, regardless of whether they work for Google. If any behaviors do not meet these standards, we plan to call them out, and we would expect them to call us out if our behavior does not meet these standards. If violations persistently fail to be corrected, we will cease participation in the discussion, and will not consider the discussion points raised during that violation. Our own teams are also expected to adhere to these standards of behavior, and be open to working together to improve.
The conditions are:
- Adhere to the Code of Conduct for the relevant standards body (e.g. the W3C’s CEPC or the IETF's BCP 54)
- Adhere to the golden rules for standards discourse:
- Be respectful, and recognize the validity of others’ points of view
- Don’t assume, ask for confirmation instead
- Look for (and communicate) basic requirements, clear use cases and problem statements
- Take actions that are constructive, and move towards consensus when possible
- Take responsibility for your own words, work to reduce hostility, and be intentionally welcoming and inclusive
A standards discussion is a technical discussion for the purpose of designing an open, interoperable API that will over time become standardized through an appropriate standards body such as the W3C, IETF, Ecma, etc. These may happen in places such as an IETF group, W3C mailing list for a Working Group or Community Group, or may even be an exchange of comments in a Github-hosted repository for one of these types of groups.
A: If someone thinks P is more important than Q and you think Q is more important than P, recognize that their prioritization may be valid (particularly from their perspective), and try to understand their chain of reasoning. If someone thinks X needs to be fixed before consensus, try your best to fix X, or come up with constructive (see rule C) reasons why that is difficult, or simpler alternatives that may satisfy the same need.
A: Don’t make assumptions about what others think that they did not explicitly state. Instead, ask questions to help clarify. For example, rather than assuming X means Y, ask: “when you said X is not a problem, are you also saying that Y is not a problem?” or “Can you tell me more about why you believe X is an important problem? Is there a use case I’m not considering?” Also understand that a common anti-pattern is “Well, since you agree with V, obviously you must agree with W.” When V and W are not absolutely and directly related, this is a form of unfounded assumption. Ask instead - “I think W follows from V, which I think you agree with. Do you agree?”
Q: What are some examples of golden rule C? (Take actions that are constructive, and move towards consensus when possible)
A: If your proposal and another both have merit, then try to objectively review both, and see if the merits of both can be combined. If someone comes up with a reasonable idea to enhance a feature, you should accept it as long as it doesn’t conflict with your underlying goal. Bias towards providing constructive, actionable feedback, and not objecting to proposed changes if you don’t have a good reason to object. If you can see a problem with someone’s idea, don’t just state the problem but brainstorm ideas on how it might be fixed from your perspective. If someone asks for help, try to give it. Don’t say “no” - say “this is why I think this idea concerns you, and an idea to address the concern is X”. Don’t say ideas are “bad”; instead, explain the concerns you have with them.
A: It is important to call out that best practice is to "admonish in private, praise in public." If you feel comfortable, try to address the behavior in the discussion: try addressing problematic behavior by explaining their misstep with compassion and patience (*), rather than simply calling out the behavior aggressively; give an opportunity for the behavior to be addressed, ideally in a way that helps everyone save face. If you must admonish someone for their behavior, it is best to do it privately rather than in front of others. If it is not fixed or acknowledged, or you do not feel comfortable raising the concern directly, disengage with the discussion, and escalate the issue to the next level you feel safe - to the relevant Working Group or Community Group chair, for example, or the W3C Staff contact or similar staffer. (If either side of the disagreement works at Alphabet, you can email web-standards-ombuds@ to ask for assistance.)
(*) For example: “This comment is not constructive/does not help us work toward consensus/makes an incorrect assumption/is not actionable. Could you please re-state or rephrase your comments accordingly?”
A: Of course, start with the above - if you are comfortable, raise the issue directly like any other. If this does not work, or you are seeing a repeating pattern, or for any other reason, you can raise the issue with the web standards team ombuds at Google (web-standards-ombuds@google.com). (This function is currently performed by Chris Wilson and Jeffrey Yasskin; we are seeking other Googlers to assist in providing a diverse set of ombuds.)
Q: Doesn’t this mean Chrome is trying to dictate how everyone else behaves in standards discussions? Why is that fair?
A: This does not mean that Chrome dictates everyone’s behavior. It does mean that the Chrome team plans to holds its own team members accountable to this standard. It also means that Chrome isn't willing to ask our team members to participate in discussions that persistently do not meet the standards described here; we believe Chrome team members deserve safety and inclusion, too.
We are open to discussion and stewardship of these guidelines as well. Where appropriate, we think it would be great for these standards of behavior to be integrated into the codes of conduct for standards bodies.
Q: What if someone says “you should do a lot of work to get up to speed on everything before I am willing to engage", especially when the topic is indeed complex or seemingly complex? Does that count as not being constructive?
A: First of all, you should recognize and acknowledge that if you’re not already up to speed on the topic, then asking an expert to weigh in is often implicitly asking them to teach you about the topic. If you haven’t already, then saying this point out loud in an appreciative tone is a good idea. Second, in order for new people to gain knowledge about an area they have to start somewhere. Asking the experts for help is often necessary, and you shouldn’t feel bad about needing to do so. One way to phrase this need is to ask for “suggested next steps” or “documents to read to learn more”. This is basically another way of telling the other person that they need to be constructive, in the form of a humble inquiry question. Also, if the document in question does not exist or is incomplete (a common situation), this will help them face up to the need to put in time to improve it and be constructive in another way.
Q: What if you can think of a flaw, but honestly don’t have time to think through constructive next steps?
A: The bare minimum should be to, along with pointing out the flaw, acknowledge politely that ideally there would be a constructive next step but you don’t have time right now to think of one. However, you should challenge yourself to spend at least a couple of minutes thinking of something. It sometimes only takes that much time to come up with some guesses or thoughts that might be helpful. It is not the responsibility of an objector to repair the problem; but it is their responsibility to explain the root of their objection. Saying “No, this is bad” with no further explanation is not constructive, and will likely be ignored or make the other person feel put down; saying “due to the added fingerprinting surface area, I am concerned this feature is not worth the cost in user privacy” is much more actionable.
A: There is a pattern of interaction that fails to recognize the time/opportunity cost of others participation - that is, that every interaction costs the entire group time and attention, and some people have more time to spend on a task than others. It is important to be concise and structured in your communications; it is respectful and constructive to ask others to be so, as well. If someone repeatedly authors walls of text in response to someone else, it is a respectful answer for everyone to politely ask them to summarize their point (example “I’m having trouble figuring out what you’re saying, can you summarize what you want to happen?”.
A: Fundamentally, an accusation of hypocrisy is a form of personal or group attack. (*) It’s almost never an honest critique of the quality of logical reasoning on the part of the other party. One of the most common forms of accusations of hypocrisy in standards is to say that your position on question A is inconsistent with “your organization’s positions” for other questions B or C. This accusation is not ok for multiple reasons, but first let’s note that it violates golden rules 2a, 2b and 2c! In particular, by conflating you with your organization, it does not recognize fully the validity of your points of view, and also assumes such conflation rather than asking. Finally, it’s of course not constructive.
A good response to such accusations is to simply state that it’s not constructive to say such things in generalities, remind them that organizations are inherently complex and do not speak with a “single, coherent voice”, and that you do not presume any control over others and are just trying to figure out question A. Then follow up by asking them to instead focus on concrete aspects of question A rather than un-actionable generalities.
(*) Wikipedia has an interesting article about personal attacks in the context of the Wikipedia discussion and comments system.
A: It is important to provide clear reasoning for disengagement, and to do so politely. It’s also best to make sure that you are not being disrespectful yourself. The best way to do this is to summarize how you see the situation, with clear statements of both sides, and why you believe the discussion is not productive. It is VERY important to roll the conversation back to the use cases you are trying to address; a common anti-pattern is getting caught up in someone saying “this is a bad API” when what they probably really mean is “I don’t understand the use cases, or don’t agree that they are important”. If you can gain agreement that the use cases are valid, and work through the constraints to that solution design, then the rest is usually bikeshedding. If you feel a brick wall response from someone else, first try the approach of saying “I think this conversation is becoming unconstructive. What approach can we take to make it more constructive?”; if they continue to engage only destructively (that is, trying to make the whole discussion go away), then simply say “we don’t seem to be able to have a constructive conversation, so I’m going to have to disengage.” Always leave open the possibility that you might re-engage if there are reasons to do so.
If you need assistance in these situations, you can contact the web standards team ombuds at Google (web-standards-ombuds@google.com).
A: In the Chrome team, we encourage the use of “I” whenever possible. This is first of all the most honest policy, since one person is rarely in control of everyone on the Chrome team, let alone Google. “We” should be reserved for situations where there really is a consensus policy from the organization and you are confidently stating it on their behalf.
The second reason to use “I” is emotional. It humanizes the discussion, avoids giving the impression that you are trying to intimidate the other person, discourages accusations of hypocrisy or comparison to others’ statements or work, and allows other members of the discussion from your own organization who may have good thoughts (that are different) to add to say so without thinking they are stepping out of line or upsetting you.
If you do use “we”, be careful to define who “we” is - for Chrome team members, for example, you may be definitively speaking for the Chrome team, but you may not be speaking for all of Google.
Q: What about statements such as "this is a show-stopper" or "We are not going to change our mind”? Are these acceptable? What should we do about it?
A: There are multiple situations in which these phrases could occur. Sometimes it is just rhetoric (particularly when saying “this is a show-stopper”); in that case, it’s important to ask for an explanation of the reasoning. When someone says “we are not going to change our mind,” it can be for fundamental reasons - and in this case, it’s important to define if the problem is the use case. If someone says “we are not going to change our mind” about a design, not the use case, then the discussion is no longer constructive: see “respectful disengagement” above.
These kinds of phrases are symptomatic of a brick wall response; you should likewise be very, very cautious about using such phrases yourself.
WebAssembly Constructive CG Discussions (credit to Deepti Gandluri and Thomas Lively)
The undersigned agree with this policy. Feel free to add yourself via PR.
- Ben Goodger and Parisa Tabriz on behalf of the Google Chrome team
- The editors of this document (Chris Wilson, Chris Harrelson, Jeffrey Yasskin)
- Mike Taylor
- You?