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