├── LICENSE ├── introduction.md └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | http://creativecommons.org/licenses/by-sa/4.0/legalcode -------------------------------------------------------------------------------- /introduction.md: -------------------------------------------------------------------------------- 1 | # Introducing DigitalOcean's Engineering Code of Conduct 2 | 3 | A code of conduct is designed to be a framework and a guide to, as the Recurse Center [eloquently phrased it](https://www.recurse.com/manual#sub-sec-social-rules), "help all of us build a pleasant, productive, and fearless community." The purpose of a code of conduct is not to burden an organization with a bunch of needless rules, or to provide a punishment mechanism for people being bad, or even to correct things that have been wrong in the past. The engineering team at DigitalOcean agreed that having a code of conduct would be a positive improvement because we strive 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 or are member of groups that often have a harder time in the workplace. 4 | 5 | Crafting documents such as these isn't to be taken lightly, so we started doing some research. While many conferences and meetups have codes of conduct, we found that they mostly protected against actions usually covered in a company's HR handbook, and we couldn't find many company codes of conduct online. Instead, we gained inspiration from other organizations’ codes of conduct and blog posts we’ve admired. In the spirit of open source, the building blocks of our code of conduct were borrowed (with attribution) from sources like these. 6 | 7 | In particular, Jenna, one our Engineering Managers, attended the Recurse Center (then known as Hacker School) in Fall 2012. Part of what makes that community so unique, impactful, and amazing is that it has a set of [social rules](https://www.recurse.com/manual#sub-sec-social-rules) that help guide people's interactions: no feigning surprise, no condescending _well-actually_'s, no backseat driving, and no subtle-isms. These rules address things that people, especially those of us who are technical, sometimes do or say that have the potential to discourage or marginalize others, often unintentionally. 8 | 9 | While Recurse Center’s rules themselves were a good precedent, enactment is a crucial factor when writing a code of conduct, too, and something we honestly struggled with writing about. This was especially delicate because we were introducing a code of conduct for an existing group of people who didn’t have a choice to opt into the community or event like with Recurse Center or a conference. Bumping up against the code of conduct once or twice is often unintentional or subtle, so we didn't want to treat it like an HR violation. Being able to discuss frictions that arise is important in a healthy engineering organization and therefore we wanted empower people to call out violations. However, this is often hard in the moment, and we acknowledge that it shouldn't be the sole responsibility of people who experience or witness code of conduct violations to help correct other people's behavior. 10 | 11 | Fortunately, the culture surrounding enactment at Recurse Center was inspiring, too; the response they encouraged to someone acting against a rule was to tell them nicely, and then move on. We really wanted our code of conduct to act and be enacted in the same manner. To that end, we built our code of conduct starting with the Recurse Center rules, then added details that support the life of a DigitalOcean engineer. 12 | 13 | There were some places we wanted to explain the essence of the rules with more of our own spin, like explaining microaggressions when warning against subtle-isms. Other sections of our code of conduct had less precedent within other codes, but we thought were important to discuss based on our specific team and company dynamics. For example, we have a lot of people working remotely at DigitalOcean, which often raises pain points that we're trying to ameliorate, so we wrote a section of our Code that addresses ways to more effectively work within our distributed team. 14 | 15 | We also included a section that provides guidelines for being kind when giving and receiving feedback, because healthy communication and feedback are important for a happy and healthy organization, but can be challenging in practice. This applies equally to work product or a working relationship. Focusing on giving "constructive, not critical feedback", as [Kate Heddleston wrote](https://kateheddleston.com/blog/criticism-and-ineffective-feedback), is fundamental to creating an environment conducive to long-term growth and positive relationships within teams. 16 | 17 | Overall, writing, refining, and discussing our code of conduct demonstrated just how hard it is to think about and create culture. The process of deciding what should or should not go into a code of conduct, and then how to word it, was quite challenging and emotional. However, we think it was integral to the healthy development of our growing team, and are looking forward to seeing how our organization grows with the guidance of our new Code. 18 | 19 | The engineering team is super excited about our Code of Conduct. We’ve made it [available on GitHub](http://digitalocean.github.io/engineering-code-of-conduct/), and hope that by doing so, we help other groups hoping to craft one for themselves. 20 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 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). 2 | 3 | # DigitalOcean's Engineering Code of Conduct 4 | 5 | ## Why have a Code of Conduct? 6 | 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. 7 | 8 | ## Social Rules [1](#footnotes) 9 | 10 | ### No feigning surprise 11 | 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." 12 | 13 | ### No condescending well-actually’s 14 | 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 …” 15 | 16 | ### No backseat driving 17 | 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. 18 | 19 | ### No subtle -isms 20 | 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. 21 | 22 | ## Time 23 | Be respectful of other people; their time, their location, and other considerations of a distributed team. 24 | 25 | Keep your calendar up-to-date, be on time to meetings, decline meetings you don’t plan to attend. 26 | 27 | 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. 28 | 29 | Resist the temptation to have local-only meetings when remote teammates should be involved - take them to Slack, Hangouts, etc. as appropriate. 30 | 31 | ## Giving and Receiving Feedback 32 | 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. 33 | 34 | 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. 35 | 36 | 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. 37 | 38 | 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. 39 | 40 | Be pragmatic, ask for context, don’t filibuster, don’t block on style not explicitly covered in DO’s style guides. 41 | 42 | 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. 43 | 44 | ## Enactment 45 | 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. 46 | 47 | 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. 48 | 49 | ## Footnotes 50 | 1. These Social Rules are borrowed from the [Recurse Center](https://www.recurse.com/manual#sec-environment) and included here for completeness. 51 | 2. http://geekfeminism.wikia.com/wiki/Microaggressions 52 | 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 53 | --------------------------------------------------------------------------------