This session was led by Johannes "Dscho" Schindelin. Supporting cast:
brian "Bmc" carlson, Jeff "Peff" King, Taylor Blau, CB Bailey, Ævar
Arnfjörð "Avarab" Bjarmason, Jonathan "Jrnieder" Nieder, Derrick Stolee,
Lessley Dennington, Glen Choo, Philip Oakley, Victoria Dye, and Jonathan
"Jonathantanmy" Tan.
Notes:
1. Dscho: Background. If you look into archives, I myself have made a change
in communication style. Used to do a lot of judgmental code reviews, but
noticed that interactions which are respectful and collaborative can be
much more productive and enjoyable. I learned this from management help at
$dayjob; it helps a lot to strengthen the team & product. Two people with
different points of view working together make a better result than one
person
2. Lately noticing more places Git can improve, for example default branch
name ‘master’, which has huge impact on a lot of population, esp. USA.
‘main’ is a very good alternative adopted by most hosters (GitLab, GitHub,
BitBucket, etc)
3. There is still work to do in documentation, other places. Some of these
changes can be wide-reaching so dscho trying to contribute them in a less
painful way; soon hopefully we can switch the default without this option
workaround. A lot of work, but the impact is worth it
4. Still, a tiny first step - let’s go further, both with Git the tool and
Git the community/list. Easy to forget there is someone on the other end
of the email address who could feel discouraged
5. Git the community is still overwhelmingly male, white - what can we do?
6. Bmc: the note about conversational tone is important. I’ve heard from
others, especially women that a confrontational review style is a turnoff;
that’s true for me too. No longer interested in a 20-email debate about
something. Let’s look for a more collaborative approach on list; when I
point this out I don’t see a bunch of help backing me up, usually.
7. Peff: I like that bmc points out when folks aren’t behaving well; I often
consciously don’t jump in to support you, because a pile-on is a bad
experience for someone who’s usually ok, and if it’s someone who’s truly
awful, I don’t want to feed the troll - they’re prone to escalate instead.
Understandable that you could wonder on your end how your pushback is
being received - we should be better about showing support.
8. Bmc: the goal is to make the list more positive; if I should do something
differently please tell me
9. Taylor: I’ve had conversations off-list with people who are speaking up
on-list. Stolee: +1, I reply (not reply-all) to say “yes thank you”
10. Dscho: Firstly, bmc, you’re a great example and I appreciate that you push
back when you do. When I see just bmc’s reply and nobody else, it seems
the offender is feeling validated and continues behaving that way (because
nobody agreed with bmc publicly).
11. Dscho: maybe we could be quicker to ask for a video chat when someone is
being harsh on list. Often when I point it out the quick response is “well
I thought it was fine” and escalates.
12. CB: I would be intimidated being invited into a private video call with
someone on the mailing list when I’m a brand new contributor. I have
experience helping moderate the #include<c++> discord which tries harder
to moderate aggressively and make inclusive environment. Moderation takes
a lot of load, but it might be a better alternative than instant dogpiling
from all the senior Gitters. Maybe a happy medium to coordinate off-list
first before everybody jumps on someone communicating rudely.
13. Avarab: there are some instructions in the CoC about
enforcement/escalation. We tend to take these reports off-list, so
something does happen but it’s not so visible. Usually these resolve
happily, but the list is left hanging, so it’s easy to get the impression
that nothing happened. At the same time, there are negatives to making the
whole thing public.
14. Philip: often common words mean different things between nationalities,
this can get in the way
15. Dscho: Thank you for taking on the task to be on the escalation list, it’s
hard. It can be really soul-draining, e.g. the GfW “how can we make Git
more inclusion” issue. I had to stay away from the GfW fork entirely
because I was so tired from trolling on that issue. From my point of view,
the CoC is there to protect folks with less standing/representation. I
thought for sure the CoC would never be invoked by a white male, but we
saw it happen
16. Dscho: for this session, hoping to find strategies to turn the tone around
on list and avoid issues from the beginning, throughout the
project/community. Recently read Nonviolent Communication, has tips to
turn around the conversation even if it started poorly
17. Jrnieder: are you saying someone in a position of power should never make
use of the CoC? Dscho: I figured it was not there for me, it was there for
people who don’t have the privilege I do. Jrnieder: A few things - CoC
sets expectations regardless of who interactions are directed to;
somewhere unwelcoming to established contributors but welcoming to newbies
is still not an appealing place for some newcomers to invest in joining
because they know they will one day be an established contributor.
Secondly, if I have a dispute, having a guide for turning a potentially
problematic event into a productive event is really important. A process
that moves in that direction of nonviolent communication. Easier said than
done. But that’s part of making a friendly environment, and overall that
points to not treating the CoC as “only for some people”.
18. Bmc: the goal of the CoC is to produce and preserve the community we want
to have. It should produce a place where everybody can participate fully;
if we have an environment that’s unproductive or toxic we lose
contributors. I’ve left projects over a poor contributor experience
before, because it wasn’t worth my time to deal with the overhead.
Conversely, having a great and safe experience is a good way to attract
diverse contributor base.
19. Stolee: When we moved from MS to GH, we received quick feedback that we
weren’t communicating well - too direct and unemotional. Maybe Git
community communicates that way, but that’s not how most people interact;
that makes me think that our “efficient and effective” communication is
actually too aggressive, and easily interpreted as attacks on
contributors. Basically… let’s all lighten up? :)
20. Taylor: Yep, my “talking to GitHubbers at GitHub” voice is different from
my “talking to Gitters on Git list” voice. New contributors, are we on the
right track here?
21. Lessley: I made first contribution recently, and had been warned about the
list, papers about the Linux kernel, and that open source contribution
could be a little contentious. I was really nervous and put it off, but in
practice it was fine; I broke ‘seen’ which was embarrassing but was ok in
general. Maybe I’d have more input if I had a larger contribution. I do
wish I had gotten more review faster.
22. Glen: I’m also a pretty new contributor. The communication style is a lot
more direct than what I’m used to on the outside. But that doesn’t mean
it’s unhelpful or unconstructive… but it takes some getting used to. I had
to put in a lot of effort to trust that folks meant well and were trying
to help, and that’s just how we communicate here. But I could imagine it
being really intimidating if people aren’t used to that kind of review.
23. Taylor: To emphasize, I also remember when I started, I felt like people
were disappointed/upset by my contributions. Took me a while to
internalize that people were trying to help me make my contributions
better. So we should A) be careful to remember that new contributor
experience, and B) be careful to set an example even in reviews with
veteran contributors.
24. Philip: Often different nations have different writing style. “Thanks.” at
the end of the email means “Thanks but no thanks” in British English, but
that’s not usually how it’s meant on Git list. I also noticed it’s not
well explained why something is a problem. Reviewer thinks everybody knows
why they’re making some comment, but the person who proposed the patch
really didn’t see the issue and won’t understand. We should give a little
more background when pointing out an issue.
25. CB: We’re not the only project that won’t land things that aren’t
technically excellent. It’s important on my team too, or else the whole
company falls over next week. We’ve had lots of internal events and talks
about inclusive code reviews. The few extra sentences - “Thanks for
submitting, it looks great, the direction is good, I’ve got comments
because xyz” - go a really long way. We recently had a new team member’s
“good first issue” turn into a 2 week ordeal, and taking the extra time to
say “this is good progress, it’s shaping up well” was helpful to keep from
discouraging our new teammate.
26. Jrnieder: Chromium project has had a problem with this too, having very
high standards. So first Cr contribution would often just feel like a
hazing ritual. The focus should be on helpfulness, not “demonstrate how
much you care about the project by putting up with us”
27. https://chromium.googlesource.com/chromium/src/+/main/docs/cr_respect.md
28. ^ This covers a lot of what we were talking about; a good reference for
better/respectful code reviews. Timeframe, tone, stating
goals/expectations, etc. Should we adopt something similar in Git?
29. 26. Bmc: It can be frustrating to spend a lot of time on a series and then
immediately get a lot of technical feedback, without any assurance
that the direction is good. We should work harder to say “I’m glad to
see this patch, looking forward to seeing it land” instead of just
pointing out things to fix. Or “the way this patch looks vs. the last
version is really great”
30. Dscho: One thing my manager does well is to lead by asking, to give space
for me to reflect on what I just said and think about more perspectives.
This doesn’t put me on the defensive right away. I’ve made the mistake
before by assuming any reply at all implies “I’m interested in this
feature” - that’s not obvious, and instead my review comes out as “You’re
doing this wrong, go away” :( and I don’t know how many people felt that
and didn’t say anything, because they left.
31. Victoria: Given the unique nature of mailing list reviews, even though
there are a ton of resources on how to give respectful reviews, it’d be
useful to do a more specific guide for Git, discussing how to structure
review reply, how to follow up, etc.
32. Stolee: We have discussed a “guide to reviewing” in Documentation/, along
with SubmittingPatches and CodingGuidelines. We avoided it because it’s a
lot of work, and I’m also worried about the review of the review doc.
Would be a productive discussion….but a lot :)
33. Jonathantanmy: Yep, I’m thinking of doing one like that, hopefully in a
few weeks we can discuss it on list.
34. Avarab: I think it’s a good thing to work on; we need to be really careful
about what guidelines we pick and choose. Need to ensure an easy path for
new contributors so they don’t need to read hours of documentation for a
typo fix. Plus we need to ensure that this doc is accessible for folks who
have different first language than English.
35. Bmc: on git-lfs we have a contributor with very little English, so when we
did the review I’d offer an alternative text, and we would work together.
That process was useful to come up with readable documentation in a
helpful way. That is, proposing a solution instead of pointing out the
problem and saying “fix it” can help a lot in scenarios like this.
36. Dscho: Yep, this is important and will help us be more accessible to
contributors whose English is not super top notch Cambridge exam :)
