[Summit topic] Increasing diversity & inclusion (transition to `main`, etc)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 13011 bytes --]

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 :)