summaryrefslogtreecommitdiff
path: root/code-of-conduct.txt
blob: 781e16f11be37f14de4e2a5bbb547b46fd28e2b1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
SIPB Social Principles

SIPB is an awesome place for interacting with computers, but there are
people here too! Sometimes, we blur the mental line between these and
end up interacting with people as if they are machines. This
inevitably results in an unpleasant experience for all parties
involved. To help keep the line intact, we've come up with a set of
important core principles to keep in mind when interacting with our
mortal counterparts:

1) People don't remember what you tell them; they remember how you
make them feel.

2) Be sincere.

3) Don't be a jerk.

4) Pay special attention to (1) through (3) when interacting online:
email, Zephyr, etc. Intervening computers have a knack for making
human interactions less than human.

Unfortunately, this isn't quite as easy as it sounds. While most
people behave empathetically, sincerely, and friendly most of the
time, nobody can do so all of the time--unlike computers, we're not
perfect. To concretize these principles, we've also collected some
guidelines describing specific behaviors we'd like to promote.
They're not comprehensive, but we think they catch the most common
pitfalls.

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 enough. Obviously, this
means that you shouldn't publicly chastise SIPB affiliates for making
mistakes. This applies even if the affiliate in question "should know
better"--prospectives are listening (in the office, on Zephyr, on
email lists, etc.), and if they see you spouting nonconstructive
criticism, they will fear their own errors as harbingers of mockery
and exclusion.

Please give people suggestions on how to do better--but please don't
do in ways that suggest that someone is a bad person for making a
mistake, that we expect better, or that their contribution was
worthless.

Be careful expressing surprise

Don't act surprised by someone else's lack of knowledge. This applies
to both technical topics ("What?! I can't believe you don't know what
Hesiod is!") and non-technical ones ("What?!  You don't know who RMS
is?!"). You may be genuinely surprised when you discover that others
don't know everything you take for granted, but keep your surprise to
yourself: It's hard to admit you don't know something, and having
others blow that lack of knowledge way out of proportion is quite
unpleasant. You may not want to upset someone, but reminding them of
what they don't know is virtually guaranteed to produce that end
result.

We want SIPB to be a place where people feel safe saying "I don't
know" or "I don't understand". Only by discovering what you don't know
can you start the real learning process. We don't want SIPB to become
an environment where people don't feel like a "real" SIPB affiliate
because they don't know what wget(1) or nc(1) is.

Avoid over-correcting others ("Well, actually...")

The urge to demonstrate your knowledge can be strong, and SIPB is as
much as place for teaching as it is a place for learning. However,
it's off-putting when the urge to teach manifests itself as
over-correction or pointing out some subtle technicality. Fortunately,
instances of this pathology are easy to spot--they almost always start
with the words "Well, actually..." or "It turns out...". While these
phrases may be appropriate when presenting a major correction or
preventing someone from making a dangerous mistake, consider finding a
different way to say what you're trying to get across.  Remember,
people don't remember what you tell them, they remember how you make
them feel.

Back-seat driving is disruptive

If you overhear people working through a problem, avoid lobbing advice
across the room. Doing so can lead to the "too many cooks" problem,
but more importantly, half-participation is rude and disruptive. If
you want to help, then by all means, offer advice or join in the
conversation--but be sure you're fully engaged and not just butting in
sporadically.

Similarly, when someone is explaining a tool or concept, they often
have a hidden plan to introduce concepts in a specific order. It's
disruptive to have somebody interject with something you weren't
planning to cover until later.  Don't do it!

No subtle sexism, racism, or other bigotry

We try to avoid subtle sexism, racism, homophobia, etc. (Overt
prejudice is, of course, right out.) This guideline is a bit different
from the others--it's often not a specific, observable phenomenon, as
opposed to, say, a "well-actually". It also may not be directed at a
specific individual.

If you observe bigoted behavior, talk to the people involved! Tell
them that whey they did was not cool.  If you don't feel comfortable
talking to the people involved, talk to somebody on the EC.  On the
other hand, if someone calls you out on discriminatory behavior,
please don't start a debate with them; doing so invalidates their
feelings and lowers the quality of the SIPB environment. Instead,
apologize and move on. If, after reflecting on your comment, you
believe you've been misunderstood--i.e., your behavior wasn't actually
bigoted--contact an EC member to discuss the situation further.

The most sincere apologies consist of "I'm sorry"

An apology is a sincere expression of sadness for the sadness of
others. If you apologize but qualify your apology with "...that",
"...if", or "...but", you risk introducing a harmful subtext--that the
recipient shares some of the blame for the incident. It won't feel
like an apology to them.

Often, people say "I'm sorry, but..." during the course of an
argument. This sort of "I'm sorry" isn't really an apology--it's a
refusal to concede a point, and it's an insincere use of the words.
Feeling sorry for someone else's pain doesn't mean that you agree with
them; it means that you recognize that they're upset and sincerely
wish that weren't the case.

What happens if someone violates these principles?

We strive to live by our social principles and clarifying guidelines,
but inevitably, we make mistakes.  When mistakes come up, it's not
acceptable to use the principles and guidelines to beat people for
"being bad". It is, however, acceptable--and important--to improve the
environment when you see something you think is destructive.

If someone has contributed negatively to a SIPB social environment
(e.g., the office, a SIPB email list, our Zephyr classes), privately
reach out to that person (or their target) and discuss your thoughts
with them. Use caution when publicly calling somebody out--doing so is
generally unwise in electronic media, because it tends to start a
distracting and toxic argument.  On the other hand, if you choose to
call someone out in person, focus on what they said or did, and not on
the person themselves.  Remember, even the best of us can't do right
all the time.

Finally, if you yourself realize that you violated these principles,
call yourself out on it and apologize.  Doing so will remind others
that these issues are important to the community and may empower
others to speak up.  It doesn't mean you're a bad person, or even a
bad SIPB affiliate.

Above all, you should *always* feel welcome to talk the Chair or any
EC member, especially if someone's behavior or speech is making you
uncomfortable or unwelcome and you're hesitant to approach that person
yourself.