Cognitive biases, blindspots and inclusion
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47301 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Vertex (graph theory)WeightInclusion mapCognitionInclusion mapWeightInformation securityMultiplication signComputer animation
00:59
Point (geometry)Computer animation
02:31
Context awarenessOpen sourceDivisorTrailOpen setPairwise comparisonOpen sourceThermal conductivityInclusion mapCodeSoftware maintenanceDecision theoryDifferent (Kate Ryan album)Position operatorPatch (Unix)Computer animation
04:19
CodeCodeLogicOpen sourceKeyboard shortcutProjective planeThermal conductivitySlide ruleVapor barrierDependent and independent variablesCore dumpQuicksortParameter (computer programming)CodeComputer animation
07:43
Web pageExecution unitMultiplication signOrder (biology)Vapor barrierProgramming languageProcedural programmingPatch (Unix)Parameter (computer programming)Interactive televisionProjective planeCASE <Informatik>INTEGRALFormal languageMereologyElectronic mailing listCodeEmailComputer animation
10:05
Formal languageSynchronizationMultiplication signWordProjective planeTelecommunicationFormal languageType theoryElectronic mailing listOpen sourceEmailSystem callOnline chatComputer animation
13:06
World Wide Web ConsortiumScheduling (computing)Different (Kate Ryan album)Multiplication signFeedbackPoint (geometry)Projective planeDatabasePhysical systemSlide rulePatch (Unix)Ferry CorstenTelecommunicationTime zoneComputer animation
16:18
DialectOpen setInformation securityMereologyPhysical systemKeyboard shortcutTelecommunicationOpen sourceSource codeComputer animation
18:45
Address spaceDifferent (Kate Ryan album)DemosceneInformation securityProgram flowchart
20:43
Execution unitInfinityPatch (Unix)CodeRoundness (object)Multiplication signProcess (computing)Software maintenanceArithmetic meanStress (mechanics)Point (geometry)View (database)Hash functionMereologyEstimatorFood energyCASE <Informatik>MathematicsStructural loadCognitionLine (geometry)Different (Kate Ryan album)Modal logicFormal languageOpen sourceProjective planeFeedbackComputer animation
26:56
Open sourcePoint cloudComputer animation
Transcript: English(auto-generated)
00:05
I learned that the first year. We make new and better mistakes in the community dev room every day. Alan, welcome. Thank you.
00:24
Should have set this up earlier. Sorry. You live and you learn. So, welcome. My name is Alan, and I work for, wow, lots of you, sorry, jitters. I work for Synopsys, where I manage the Node.js and .NET agents for Seeker.
00:44
If you haven't heard about Seeker yet, it's probably the best IS tool out there. But this is not a security track, so this is the last time I'm going to mention Seeker or security or Synopsys. Instead, I want to talk about inclusion.
01:02
But before talking about inclusion, I kind of have to address the elephant in the room. See, some of you that I know here, some of you know that I used to be a DBA. Don't worry. I'm not about to talk about Postgres. The elephant in the room here is me.
01:21
So why is a privileged, straight, white dude standing up here talking about inclusion? Well, first of all, I think it's critical for us to recognize our privileges. I definitely recognize how privileged I am to be here today, to be accepted.
01:41
Thank you, session chairs. How privileged I am to work for a great company like Synopsys that will pay for this, and how privileged I've been throughout my career to get to this point. And I think that if we can recognize our privileges, it's our duty to use them to
02:01
help include others that might not have these privileges. Think if you do not do this, you're not exercising your privilege, you are wasting it. And if none of this resonates with you and no other reason works, just remember that as easily as privilege is given, it can be taken away.
02:23
So those of us with privilege should make the world more inclusive, not more appropriate for us. And if you didn't believe that, just ask my ancestors. So what does all of this have to do with open source? Why am I even talking about inclusion in open source?
02:43
I mean, open source is open, it's in the name, right? Everyone can submit a patch, everyone can participate. Why am I even here? Well, I unfortunately do not believe that is true. I won't go as far as saying this is true for all open source communities.
03:04
But for a lot of open source communities, there's a very distinct, very obvious, unofficial, undocumented divide between everyone can submit a patch and those who can actually make decisions,
03:22
those who can actually affect the project, those who can actually change things. And I do not mean the difference between maintainers and non-maintainers. I think it's fine to recognize people's track record, I think it's fine to recognize
03:40
people's commitment, I think it's fine to recognize people's ability. But if you have two people with comparable abilities, comparable track records, comparable involvement in the project, and one of them is in a position to make decisions and the other is not, you have an inclusion problem.
04:04
And this is what I want to address today. So kind of before we even start, before we even start talking about inclusion, I think step one is having a code of conduct.
04:23
Now this, for some reasons, for some reason in some places where I suggest this, this is a controversial suggestion. I hear all sorts of comments like, but we don't need a code of conduct, right? Well, wrong. This is like a completely wrong response and don't think it's just wrong, it's biased.
04:47
Okay, so I kind of mentioned that a slide later than I intended to, so let's just talk about biases for a minute. Biases are these small mental shortcuts our brains make that help us process the world
05:04
around us. I see some of you kind of nodding, probably some of you kind of thinking, wow, that's horrible, that's horrible for the people who have these. Luckily, I don't have these, right? I'm logical and impartial, right?
05:20
Well, wrong. For most of you, at least, wrong. There's actually a well-documented, well-researched bias called the bias blind spot, which is a bias where you believe that everyone around you suffers from biases except yourself. So how do these tie into this argument about codes of conduct?
05:44
Well, we don't need a code of conduct because everyone here gets along, right? Wrong. There are at least two biases here. The first one is a survivor bias. Well, everyone here gets along because everyone who doesn't just left.
06:01
So if we only look at the people who decided to stay, we don't need a code of conduct by definition, but this isn't really what open source should be about, right? It should be about inviting more people in. The second more serious bias here is a bias called false consensus.
06:21
False consensus is a bias where you wrongly believe that your own traits, attributes, core beliefs are universally common. Chances are, in reality, they are not. So if everyone is just like me, I don't need a code of conduct because I get along
06:42
just fine with myself, right? Most people are not just like me. Most people are different amongst themselves. And if people are different and have different ideas on what is appropriate or inappropriate behavior, we might need something to explicitly state how we want to interact.
07:05
I think this false consensus bias is the core issue to a lot of the inclusiveness, inclusivity, inclusiveness issues we have in open source.
07:20
And this is the focus, actually, of my talk. And throughout the next couple of minutes, I'm going to show a couple of ways how this bias brings up barriers that prevents our open source project or community to be as inclusive as we may want it to be.
07:43
The first barrier is a knowledge barrier. And I do not mean technical knowledge. I think it's fair enough to say that if I have a project in, for argument's sake, JavaScript, you need to know JavaScript in order to contribute code.
08:02
That kind of makes sense, right? If you don't know JavaScript, there's a whole lot of other ways you can contribute, but if you want to contribute code, you need to know the programming language we are using. There's a whole other world of knowledge out there. There's a whole lot of kind of procedural knowledge of how I do things.
08:26
How do I actually become a part of this community? How do I interact with it? Some communities, patches are welcome, right? Just send a patch. Sometimes I'm expected to go on the mailing list and introduce myself and say,
08:42
hey, here's my great idea. What do you think about it? Some communities need a blueprint or a Jira ticket. We need to have this Jira ticket approved by someone and then targeted for the right sprint. And even once I've passed all of that, what does my PR need to include?
09:03
Do I need to sign a contributor agreement? Do I need to have unit tests, integration tests, performance tests? What is the code style? Well, we never document all of these because everyone knows us, right?
09:20
It's self-obvious. Well, it is not. It obviously isn't because I'm out here asking these questions. Do yourself a favor. Document all of these. Document everything. There is no such thing as over-documenting. You cannot be too explicit.
09:41
Worst case scenario, you wasted 20 minutes on writing a contributing MD that no one will read? Not too bad. If you made it easier for at least one person to interact with your community, time well spent. The second barrier we sometimes put up inadvertently is language barrier.
10:08
And again, I do not mean JavaScript. I mean English. Okay, so who here speaks English by a raise of hand? Probably all of you.
10:20
Who here speaks English as their second language? Most of you. Third? Fourth? For those of us who do not speak English as our first language, we sometimes find it much harder to interact with communities who kind of jumped on the technology bandwagon.
10:47
We all started out with mailing lists which are kind of old school, but then we discovered synchronous communication. We have these new technologies called IRC back from the 70s, 60s.
11:01
No idea. Or Slack or Discord. What are cool kids using today? I'm asking because I'm profoundly uncool if you did not notice. And then you can go further. There's all these new technologies, things I call these telephones.
11:23
There's these technologies where you can actually communicate with other people remotely by speaking instead of typing. Again, crazy new stuff. These are great, right? Open source was built on communication and when we get better tools to communicate, we want to adopt them.
11:42
We need to stop and think how are these tools affecting those of us who use English or whatever language your project is built on. As a second, third, fourth language. For those of us who don't have this as a first language, it's often quite considerably easier for us to communicate asynchronously.
12:06
When you're writing an email, you can pause, you can reread it, you can look up words you don't understand, you can ask your mom to review it. Mom, if you're watching this, thank you. Much appreciated.
12:22
And you can't always do these things in synchronous chats. If you go further to voice communication, now I need to start thinking about my accent, which I know is horrible. I can see all of your faces. Or I need to start thinking if I can understand other people's accents because there are other people like me on this call.
12:43
And it just becomes considerably harder for people who do not speak English as a first language. So as much as we like effective communication, are we building up words here that we might not need or not want?
13:02
This kind of ties into my third point, third barrier, time and time sensibility. This may come as a shock to some people. There are different time zones in the world. Someone earlier here, I do not remember her name, shared a slide of the 40 different time zones.
13:25
Even if all of your community is in the same time zone, time is still an issue. Different people have different schedules. In my own small team of five people, I have people who start their workday at 7 a.m. after dropping the kids off to school.
13:45
And I have people who go out every night and start their workday at 11.30. Different time, time sensibilities. That becomes much more complicated when you exit the corporate world.
14:01
Especially if your community has a lot of unpaid volunteers. Some people work on weekends, some people work on their night off or in the evening. If you do not recognize this, if you expect everyone to have the same time sensibilities, you are inadvertently excluding people.
14:25
How many of you have reviewed a pull request? A lot of you. How many of you have merged a pull request within 10 or 20 minutes?
14:41
Quite a few. How many of you have stopped to consider, am I merging this too fast? Am I leaving anyone out? Because fast feedback is great. I am the last person to say it isn't. In fact, I have a whole big talk about giving fast feedback.
15:05
Leslie, for next year. Just saying. Awesome. But there's a big difference between giving fast feedback and closing up communication lines. Just as easily as I can merge a patch in 20 minutes, I can respond within 20 minutes and say,
15:25
great idea, I love your patch, thank you for contributing. I'm leaving this open until next Monday so everyone else who might be interested can weigh in. And again, of course, you need to scale this appropriately.
15:40
If someone is fixing a typo, just merge it. If someone is redesigning the entire system and moving from an SQL database to a NoSQL database and rewriting half the project in Groovy, true story. True story. Maybe don't wait until next Monday, maybe leave this open for a couple of weeks.
16:03
I assume some people will have quite a lot to say about this. And this kind of automatically ties into the final point I want to make here. Keep your communication open.
16:22
If it's not open, it didn't happen. How many of you have ever seen a pull request which opened, had some comment, had some response, had some comment, two days of silence, final comment, discussed with David face to face, understood my comment, merging. How many of you saw this? Way too many.
16:44
Now, this is great, right? It's really effective communication. I talked to David, he explained everything that I didn't understand. We didn't have to write in English because English is difficult. But no one else can be a part of this.
17:03
Just putting your source code out there in GitHub is not being open. Any communication you have that isn't done out here and is open might as well could not have happened. If you want to be open, if you want to be inclusive, you need to always assume that everything has to happen in this open medium
17:31
and not everyone can take the same shortcuts you can. Not everyone can walk over to the next room and ask David, what the hell are you doing?
17:43
Why are you rewriting my system in Groovy? Again, true story. Names change to protect the innocent. Especially if you're working for some corporate funded open source, you need to assume that not everyone can do this.
18:05
And while this may seem really effective to you, it is the opposite of inclusivity. And this pretty much assures that your work on this corporate funded open source will always remain this corporate funded open source and will never go past it.
18:26
Because anyone who isn't part of this will never be an equal contributor. And even if you can't, there's a whole lot of looks here saying you're right with IP and you're right with security.
18:42
True. Fair enough. This happens. So if you can't be open, at least be transparent about it. Please be able to say we did this, we are not discussing this in the open because of blah blah blah security consideration. So at the very least, you put yourself out there and explain yourself instead of just arbitrarily saying, well, I really want to do this feature.
19:09
I really don't want all those annoying people in the community nagging me about it. So I'll just merge it myself kind of behind the scenes. And if you do not do this, this is exactly what people will assume you're doing.
19:23
So be open as possible and when you cannot, be transparent. I guess I have a couple of minutes. I talk really fast when I'm nervous if you did not notice.
19:41
So I just want to wrap this up. I think a lot of communities have problems in inclusivity. A lot of communities can be more inclusive. And I think it's more often than not, this isn't done by any bad will or bad intent. More often than not, these are just done by lack of attention, by these cognitive biases that prevent us from seeing differences in other people.
20:14
The good news are that humans are generally pretty smart animals and we can learn. So once confronted with contradicting data, once confronted with a fact, says, hey, what you're doing here is uninclusive.
20:29
By doing this, you're leaving something, someone, sorry, out. We can amend our behavior. We can't learn. We can learn. So if you take nothing else from this talk, please take this.
20:42
And with that, I'll address any questions.
21:01
There's someone up there. I don't know if we're still running mics. Thanks for the talk. What are your thoughts on the language used in the communication, even if we assume we all understand English very well?
21:23
Even if that's the assumption. I see in a lot of cases, the maintainers, they may end up being very direct, at least with one another. And it may sound really harsh. And to a new contributor, that may sound really harsh. But if you ask maintainers to be always really considerate, then they may not be,
21:45
it takes a lot of cognitive load for them to rephrase what they want to say. So if I rephrase the question, for maintainers, it takes a lot of energy to always be considerate and do we want to go that way?
22:05
Well, I have to apologize, but I completely disagree with the premise here. A maintainer's job is not to merge code. A maintainer's job is not to merge code. A maintainer's job is to grow his community, his or her community, of course.
22:24
There is absolutely no necessity that giving a harsh review on the code equates giving a harsh review to the person.
22:41
My first open source contribution, I won't name in shame, but was a three or four line patch. I optimized some hash function in some project. The following day I got an answer saying, well, it looks okay, but you haven't mathematically proved this is really faster. People like you should not be writing code.
23:04
Again, true story. Well, okay, I'm sorry I offended you with my lack of mathematical proof, but I've been doing this for 20 years and empirically this is 15 times faster. So, I don't know, take it or leave it.
23:23
Part of the maintainer's job is to give critical review on the code and absolutely no critical judgment on the contributor. If you can't do this, you frankly should not be a maintainer.
23:40
Yes, thank you. So, the story you mentioned about David, right? So, the hypothetical situation where he migrated everything to NoSQL and you leave the merge request sitting for a couple of weeks, right? So, how do you deal with something like this as a reviewer and as a reviewee as well, right? Because there's three weeks or a couple of weeks so much communication, right?
24:02
Or some people stop communicating at all, right? So, yeah. So, the question was about the speed of the review and keeping contributors involved. So, maybe I didn't stress this enough. I by no means intended to say give slow feedback.
24:23
The faster the feedback you can give, the better, okay? If you have this huge patch and you can review it within an hour, by all means, review it. The difference is saying, okay, you can even go as far as saying, okay, I've reviewed this, I have approved this, this patch looks fine, but I'm explicitly not merging it if someone else has any comments in the next week, two weeks, however long it takes.
24:49
So, you have given very fast feedback. You did not alienate your contributor. You're just leaving it open for other opinions. We have time for one more question.
25:01
I'd like to call on someone else. Can we pass this away? Sure. Excellent. I'll be here all day. You can find me by the only person with a synopsis day shirt. Thank you very much for your talk. Your remark about not explaining the final steps discussed offline on a peer, on
25:27
the pull request, made me think a lot, but in my case and my experience, a lot of pull request comments are, I don't estimate they have a lot of value in my point of view. Often, they are often sometimes jokes with teammates.
25:43
We have a practice to document design decisions, but I was curious about how you think all comments on pull requests matters. I'm a bit curious about your point of view on that. So, I'm not sure I got all of that, but the question was basically how do I feel about all comments on pull requests and do they all matter?
26:07
So, I'm all for communication, but I think you always need to remember who you are communicating with. And some projects do this really nicely. They have an acronym or emoji or whatever for inside jokes.
26:23
So, you can comment slash slash joke. Great idea. Better than Mongo or whatever. But going to make it very visibly clear, you're just joking and just building a community here. I don't know if that really answers your question, but I think I'm running out of time.
26:45
Wonderful, folks. If we could have a round of applause for Alan again, please. I know we had some unanswered questions. Our speaker has graciously agreed to take questions in the hall if you need to do that.