diff options
author | Jonathan Reed <jdreed@mit.edu> | 2014-02-11 01:23:30 -0500 |
---|---|---|
committer | Jonathan Reed <jdreed@mit.edu> | 2014-02-11 01:23:30 -0500 |
commit | 124ae2c6b4e5017e200b93d720a3656e04278bb4 (patch) | |
tree | 7a66179384d553239b5b940cee71c9f4c05f4e9e | |
parent | 581600855b07ff487d17a97f50ec579e7e1b0f4b (diff) |
Move "perfection not required" paragraph to the beginning
I feel this sets a good tone for the document, which is that we're all imperfect.
It also no longer begins the document with a "No...." principle
-rw-r--r-- | code-of-conduct.txt | 32 |
1 files changed, 15 insertions, 17 deletions
diff --git a/code-of-conduct.txt b/code-of-conduct.txt index a3050a0..12192bd 100644 --- a/code-of-conduct.txt +++ b/code-of-conduct.txt @@ -9,6 +9,21 @@ on individual empowerment and making SIPB a supportive, productive, and fun learning environment, where people feel comfortable making mistakes and learning from them. +Perfection is not required for participation + +We want people to participate in SIPB projects without feeling like +they're going to get flamed for not knowing very much. Obviously, this +means that you shouldn't be chastising prospectives for making +mistakes. Less obviously, you shouldn't be chastising people who +"should know better" in public, either. Remember that prospectives +are listening (in the office, on zephyr, on email lists, etc.) and +might think that such criticism might be directed at them if they make +an error. + +This doesn't mean you can't give people suggestions on how to do +better, but please don't do so in a way that suggests that they're bad +person for doing what they did, that they should have done better, or +that their contribution wasn't worth making. No feigning surprise @@ -101,23 +116,6 @@ they're upset and wish that weren't the case. This is an opportunity to think about how to better word your point in order to avoid upsetting others in the future. -Don't act like people need to be perfect to participate - -We want people to participate in SIPB projects without feeling like -they're going to get flamed for not knowing very much. Obviously, this -means that you shouldn't be chastising prospectives for making -mistakes. Less obviously, you shouldn't be chastising people who -"should know better" in public, either. Remember that prospectives -are listening (in the office, on zephyr, on email lists, etc.) and -might think that such criticism might be directed at them if they make -an error. - -This doesn't mean you can't give people suggestions on how to do -better, but please don't do so in a way that suggests that they're bad -person for doing what they did, that they should have done better, or -that their contribution wasn't worth making. - - Why have these principles? The goal isn't to burden SIPB with a bunch of annoying rules, nor to |