Nengo Code of Conduct

Why have a code of conduct?

This Code of Conduct is designed to help all of us build a pleasant, productive, and fearless community. The purpose of the Code of Conduct is not to burden the team with a bunch of needless rules, or to give us a punishment mechanism for people “being bad,” or even to correct things that have been wrong in the past. We are striving to make our team a great group of people to work with, especially for those people who have faced more adverse working environments in the past.

No feigning surprise

Don’t act surprised when people say they don’t know something, or ask a question that has what you feel is an “obvious” answer. This applies to both technical things (“I can’t believe you don’t know what the stack is!”) and non-technical things (“You don’t know who RMS is?!”). Feigning surprise or pointing out the “obviousness” of something has no social or educational benefit; these reactions are usually an attempt to make the writer feel better about themselves and the reader feel worse. Even when that’s not the intention, it’s almost always the effect. This rule is tightly coupled to our belief in the importance of people feeling comfortable saying “I don’t know” and “I don’t understand.”

No backseat driving

If a thread is working through a problem, you shouldn’t join the thread, drop an advice bomb, then leave. This can lead to the “too many cooks” problem, but more importantly, it can be rude and disruptive to half-participate in a conversation. This isn’t to say you shouldn’t help, offer advice, or join conversations—on the contrary, we encourage all those things. Rather, it means that when you want to help out or work with others, you should fully engage and not just interject sporadically. If you want to show support for an idea presented in a thread, consider using a simple thumbs up emoji reaction rather than stating the same point a different way. If you feel that there is a different approach that could be taken, but you do not have the time or motivation to implement that approach yourself, make a note to yourself to explore that approach when you have time instead of putting that burden on someone else.

Time

Be respectful of other people: their time, their location, and other considerations of a distributed team.

Be on time to meetings. Read the meeting agenda ahead of time, and if something requires your input and you cannot make the meeting, tell the meeting organizer.

Resist the temptation to have local-only meetings when remote teammates should be involved. Take the discussion to the forum, a group hangout, Github issue, or dev meeting as appropriate.

Keep in mind that what you write once will be read by several people. Writing a short message means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary. Try to bring new arguments to a conversation so that each message adds something unique to the thread, keeping in mind that the rest of the thread sill contains the other messages that have already been made.

Try to stay on topic, especially in discussions that are already fairly large. If a discussion brings to mind some related but separate issue, please start a separate discussion for it. Everyone that is participating in an existing discussion will naturally wish to respond to your comment. If it is a separate discussion, each person can choose to join that discussion or spend their time some other way.

Giving feedback

Give constructive, not critical feedback. Feedback is negatively critical when it focuses on something wrong with someone or something they produced, especially without any mention of ways to make their behavior or their product better. Critical feedback on work often looks like “you don’t write enough tests” or “your code quality isn’t good enough.” Personal criticism can be more severe and often looks like “you should be less judgmental” or “you are a burden because you ask too many questions.”

Constructive feedback is more about how a person can do better rather than what they are doing wrong. If you want someone to do something better, you should tell them what better looks like. Ask a question to get a discussion rolling, to gain context, and then if you see room for improvement give declarative feedback to that effect. This creates an environment where people understand what success looks like instead of just feeling like they are unsuccessful.

Just as you shouldn’t interact with people poorly in person, do not interact poorly through code or code review. Assume that the other person is smart and capable, even if they don’t have the same expertise as you. Go about your review under the assumption that the decisions were made for a reason, not in a vacuum. Ask about circumstances if you’re confused or uncertain. Be pragmatic, ask for context, don’t filibuster, don’t block on style not explicitly covered in our style guides. Fight for your way if you think it’s right, but not only to be right.

Receiving feedback

While the reviewer must do their best to be constructive in their feedback, so must the reader do their best to read a comment as attempting to be constructive and not personally critical—as hard as this may be when you are passionate about what you do. Assume that the reviewer is trying to help and is not trying to make you feel bad.

You are not your products. It is important to realize that it’s better to find errors in review than in production and recognize that your work fits into a larger whole.

A review is not a test that you must pass to be accepted by the community. By creating something to be reviewed, you are already a member of our community.

Enactment

If somebody requests that you stop a certain behavior (even if said behavior is not explicitly covered in this document), you are expected to comply immediately. Complying is not an admission of guilt or of a transgression; rather, it is an acknowledgment that further discussion of what caused the request is probably a good idea. Work with the other party to fix the situation. If the miscommunication happened in writing, move the discussion to a richer medium like a video chat. Use the opportunity to build stronger relationships and better the team.

Enforcement of the Code of Conduct is essential. If there is no enforcement, then the Code of Conduct becomes a feel-good document without value. Individuals should feel empowered to call out violations publicly or privately. Maintainers of Nengo projects are available to help moderate, address concerns, and solve violations.

Notes

This Code of Conduct is primarily based on the DigitalOcean engineering code of conduct. Their Code of Conduct is licensed under a CC BY-SA 4.0 license, so to comply with those terms, this document is available under the same CC BY-SA 4.0 license.

DigitalOcean’s Code of Conduct and our changes are inspired by several other publicly available Codes of Conduct, blog posts, and other resources. Anyone interested in understanding the motivations behind this document should start by reading these other resources.