summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Jonathan Reed <jdreed@mit.edu>2014-02-11 01:23:30 -0500
committerGravatar Jonathan Reed <jdreed@mit.edu>2014-02-11 01:23:30 -0500
commit124ae2c6b4e5017e200b93d720a3656e04278bb4 (patch)
tree7a66179384d553239b5b940cee71c9f4c05f4e9e
parent581600855b07ff487d17a97f50ec579e7e1b0f4b (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.txt32
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