Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/digitalocean/engineering-code-of-conduct

Code of Conduct for DigitalOcean's Engineering Team
https://github.com/digitalocean/engineering-code-of-conduct

Last synced: 7 days ago
JSON representation

Code of Conduct for DigitalOcean's Engineering Team

Awesome Lists containing this project

README 

        
For some context on why we think having a code of conduct for our organization is important and the process surrounding its development, check out [this introduction](./introduction.md).



# DigitalOcean's Engineering 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 engineering team a great group of people to work with, especially for those people who have faced more adverse working environments in the past.



## Social Rules [1](#footnotes)



### No feigning surprise

The first rule means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! 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 has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect. As you've probably already guessed, 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 condescending well-actually’s

A well-actually happens when someone says something that's almost— but not entirely— correct, and you say, "well, actually…" and then give a minor correction. Even in complicated environments where small details and edge-cases can be forgotten, unless they are critical, they should not be interjected. If they are critical to the conversation phrasing can be the difference between a valuable clarification and condescension e.g. instead of “well actually …” a simple change to “don’t forget …” or “it’s easy to forget …”



### No backseat driving

If you overhear people working through a problem, you shouldn't intermittently lob advice across the room. This can lead to the "too many cooks" problem, but more important, it can be rude and disruptive to half-participate in a conversation. This is particularly true in a distributed environment involving conversations in Slack. The occasional interjection to an on-going conversation, particularly based on backscroll, can be very disruptive. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just interject sporadically.



### No subtle -isms

Subtle -isms, also called microaggressions[2](#footnotes), are small things that make others feel uncomfortable, for example, saying "It's so easy my grandmother could do it" is a subtle -ism, as it is both subtly sexist and ageist. The "subtle" in "subtle -isms" means that it's probably not obvious to everyone right away what was wrong with the comment, even people in the group otherwise affected by the comment. And, even though they are subtle, might seem insignificant, and are often unintentional, a steady stream of them compounds to make people in under-represented groups feel less welcome.



## Time

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



Keep your calendar up-to-date, be on time to meetings, decline meetings you don’t plan to attend.



Denote [working hours](https://support.google.com/calendar/answer/83117?hl=en#working_hours) in Calendar if you want people to constrain your meetings to them.



Resist the temptation to have local-only meetings when remote teammates should be involved - take them to Slack, Hangouts, etc. as appropriate.



## Giving and Receiving Feedback

Give constructive, not critical feedback[3](#footnotes). Feedback is negatively critical when it surfaces 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 judgemental" 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.



Code, configurations, and their reviews are also mechanisms for communication. Just as you shouldn't interact with people poorly in person, do not interact poorly through code or code review.



You are not your products. Technical critiques are integral, and should be hard on the product, not on the producer. While it is important to care about your work and producing the best thing you can, this can make review difficult. 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.



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.



Be pragmatic, ask for context, don’t filibuster, don’t block on style not explicitly covered in DO’s style guides.



Code, configurations, architecture, platforms, frameworks will need to be changed. Fight for your way if you think it’s right, but not only to be right.



## 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. Don't get defensive; even if you didn't intend to offend, accept responsibility, consider apologizing, and work with the other party to fix the situation. A mistake is a chance to learn and/or teach. Use the opportunity to better the company and 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. The Code of Conduct Guild is available to help moderate, address concerns, and solve violations. For repeated, more severe, or unresolved violations employees should reach upward in their management chain for resolution.



## Footnotes

1. These Social Rules are borrowed from the [Recurse Center](https://www.recurse.com/manual#sec-environment) and included here for completeness.

2. http://geekfeminism.wikia.com/wiki/Microaggressions

3. This point is paraphrased from a larger article called [“Criticism and Ineffective Feedback”](https://kateheddleston.com/blog/criticism-and-ineffective-feedback) by Kate Heddleston