Are we being inclusive with our community recognitions?
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 39 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/67217 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 202228 / 39
2
9
11
15
26
30
36
37
00:00
QuellcodeWürfelSchreib-Lese-KopfQuick-SortRepository <Informatik>SchriftzeichenerkennungProjektive EbeneProzess <Informatik>MultiplikationsoperatorMereologieSelbst organisierendes SystemSoftwareentwicklerSoftwarePatch <Software>DatenverwaltungSystemplattformCodeOpen SourceRahmenproblemDifferenteDatenanalyseMinkowski-MetrikVerkehrsinformationKartesische KoordinatenRelativitätstheorieMetrisches SystemQuellcodeQuantenzustandWürfelMailing-ListeEndliche ModelltheorieSchnittmengeUmsetzung <Informatik>URLTwitter <Softwareplattform>BitGruppenoperationPunktEreignishorizontFrequenzWhiteboardWärmeleitfähigkeitBefehl <Informatik>Kontextbezogenes SystemStrömungsrichtungZahlenbereichKette <Mathematik>Inklusion <Mathematik>DokumentenserverProgrammfehlerTypentheorieComputeranimationXML
08:03
Repository <Informatik>Web logSystemaufrufInformation EngineeringQuick-SortSpeicherabzugSystemplattformCodeProdukt <Mathematik>Umsetzung <Informatik>Open SourceSoftwareentwicklerDokumentenserverDatenverwaltungNatürliche ZahlRückkopplungSoftwareBasis <Mathematik>MinimumElektronisches ForumZoomDiagrammCASE <Informatik>WürfelSchnittmengeMustererkennungStrömungsrichtungWarteschlangeSoundverarbeitungRechenschieberZahlenbereichMathematikProzess <Informatik>Computeranimation
12:43
MustererkennungProzess <Informatik>LaderSoundverarbeitungSchriftzeichenerkennungQuick-SortDatenverwaltungMereologieDokumentenserverRückkopplungWürfelProgrammierungInklusion <Mathematik>Produkt <Mathematik>GruppenoperationMultiplikationsoperatorEndliche ModelltheorieFokalpunktZahlenbereichMustererkennungProzess <Informatik>Umsetzung <Informatik>Repository <Informatik>Projektive EbeneSoftwaretestCodeSchnittmengePunktMetrisches SystemMathematikWhiteboardGüte der AnpassungComputeranimationXML
19:21
Prozess <Informatik>RankingGerade ZahlBildschirmmaskeGebäude <Mathematik>Prozess <Informatik>Umsetzung <Informatik>Metrisches SystemQuick-SortChatten <Kommunikation>Spezifisches VolumenMailing-ListeStabEinfach zusammenhängender RaumAbstimmung <Frequenz>MereologieRechenschieberGoogolZustandsmaschineTypentheorieArithmetisches MittelProjektive EbeneBildschirmmaskePunktEndliche ModelltheorieNominalskaliertes MerkmalTermEin-AusgabeCASE <Informatik>MustererkennungLogistische VerteilungDatenverwaltungFreewareHilfesystemSoftwareSchriftzeichenerkennungSoftwarewartungHyperbelverfahrenVirtualisierungRechter WinkelRankingXMLComputeranimationBesprechung/Interview
26:00
QuellcodeComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:04
All right. Well, welcome, everybody. I mean, as Alex mentioned, my name is Ray Paik, and I'm from Cube Dev, and I have my Twitter handle there. So if you want to continue our conversation, even after our talk, please feel free to reach out to me.
00:21
And a little bit more about myself, just want to share my background. I probably got involved in open-source community management full-time probably around 2014 when I joined the Linux Foundation, and I worked at DLF for about four years. I was involved in several projects in the
00:44
networking industry. In 2018, I had an opportunity to join the community relations team at GitLab. And as you know, I mean, GitLab is an open-source project that started about, I mean, 10 years ago, I think they celebrated their first commit to the repo sometime in like
01:02
October, November timeframe celebrating the 10 years. And I mean, they had this huge ethos, I mean, they still do, of working with community. I worked with community contributors, and it was exciting to be part of the continued growth. I mean, several thousand people over the history of the project contributing to the software and the community in general.
01:23
In late 2020, I joined my current community and company called Cube. You're probably not as familiar with Cube as you are with DLF or GitLab, but we're in the data analytics, business intelligence space where you provide a platform where you make it easy for developers
01:41
to access data from all your modern data sources and have those data readily available for the dashboards you're creating or other applications. So if you're interested in this space, do check us out. So what I'll talk about today, first of all, why recognitions are important in open source and also in general,
02:06
but some of the typical recognitions that we were used to seeing, or we still see, to this day. But some of the challenges they present, I mean, I assume you're all here because you're passionate about diversity and inclusion like I am, but I think we could do a
02:24
better job. I mean, recognitions in and of itself are going to solve the challenges that we're having in diversity and inclusion, but what are some of the things that we can do to create a foster more welcoming and inclusive community? And I'll try to make sure that we
02:42
have about 10 minutes or so for Q&A. So feel free to queue up your questions and happy to discuss them with you before we adjourn the session. So why are recognitions important? And I typically think of three things. I mean, first one's like little obvious. It's obviously
03:03
to thank people for great job that people have done, whether it's solving a bug, resolving a technical debt that we've been carrying for a while, or even things like making new people feel welcome and helping them sort of onboard things and pointing them to some of the onboarding resources or answering questions so that people can get started. And the second reason why
03:29
recognitions are important, I think all the open source community, whether you have this formalized or not, you have these set of values or ethos that you aspire to. I mean, you know, for example, being helpful and welcoming to everybody who joins the community,
03:45
et cetera, et cetera, you'll probably have that written, you know, some have written down as sort of a mission statement or maybe even reflected in your code of conduct, but you have sort of set of values that everyone wants to aspire to. And when somebody does a great job of
04:01
sort of demonstrating or exemplifying those values, you want to highlight those people as role models that we all want to aspire to. Hey, here's a person who, you know, really help with the onboarding process in our community, for example, and it's a good way to sort of highlight those role models. And also, you know, the third thing that I point out here is,
04:28
you know, it's a good way to sort of celebrate like your successes in the community by sort of highlighting great work that's been done, whether it's technical or community-focused. And I mean, even before the pandemic, I think people in open source are used to working sort
04:45
of asynchronously in different geographic locations. And so even if it's virtual, by doing just group celebration, it helps bring people together. So, I mean, these are the three important reasons why I think recognitions are important, not just in open source, but,
05:01
you know, any group of people you have. But in open source communities, you know, what do we typically see? I mean, I have a couple of examples here. And then when I present some examples that are not so great, this is, you know, all learnings for me, these are some of the mistakes that I made that I went to share this, I'm not pointing a finger
05:24
at other people or different communities are the mistake that are the only say that I've been a part of. So you'll see like charts or dashboards like this in some communities. The first one on the left, and the top left is sort of, hey, here are people who had their
05:43
patches merge over whatever period of time over the past 12 months, last quarter, or last month. And you sort of list people, hey, Jane has, you know, had 230 PRs merge over, you know, a period of a year and, and, and Sanjay had had like a 50, etc, etc. And you'll,
06:03
you'll, you'll typically see is that events or community reports or dashboards, etc. The one on the right, I mean, this is something that you typically see at a foundation based open source projects where you, you have, you know, sometimes dozens or even hundreds
06:20
of companies involved or organizations involved in open source project, like, you know, however you define contribution, you said all this, you know, here are the companies that have had like contributors to the project. I mean, whether it's contribution to the repo or discussions, etc, etc. And say, hey, this organization a has like 15 people,
06:41
organization B had had seven, etc, etc. And, and you'll see these in like dashboards. So what are some of the challenges with with these? I mean, there are two main issues that I see here is the first one is with the these dashboards and metrics have a tendency tendency
07:02
tendency to focus mostly on code activity, code base activities. For example, in your repos, whether it's like a GitLab or GitHub report repository you have for your project, you're just focused on activities around the tool chain for your code. That's one because, you know, you have it, you know, when you do that you have a tendency tendency to sort of
07:25
ignore contribution that happens outside of the where your code lives. The second challenge here is that there's a lot of emphasis on metrics or what can be quantified. You know, I think like we're mostly like a very data driven people. So we're kind of attracted to
07:44
numbers and metrics. But the challenge is that the metrics in and of itself doesn't give you the full context of the work that was done or the value that these contributions have provided. So those are the two main issues that I see with these types of dashboards or metrics.
08:05
Um, so, you know, when you when you focus on on code, and when you focus on numbers, the problem that you're facing nowadays is that, I mean, maybe 10 years ago, like when when you, when there's an open source community, it mostly attracted other developers. So the
08:26
developers like it's natural for their conversations or discussions to happen in a code repo. So if you know, if you did recognition, mostly based around code, maybe it wasn't as much of an issue. Like I said, like a decade ago. However, when you go to open source
08:44
communities today, a lot of discussions happen that involve non developers, and they're happening outside of your repositories. They're happening in platforms like Discord, Slack, or Mattermost, or wherever your conversations take place. And there are people that are making great
09:04
contributions to the community by, you know, participating and facilitating conversations. And I use an onboarding example earlier, when somebody new joins a community, they'll come on Slack or Discord and sort of introduce themselves. And there are people that are very experienced in the community that feel very passionate about, you know, making those people feel welcome
09:24
and help them get started in the community by pointing out the onboarding resources or answering quick questions. And it's a valuable contribution that happens outside of the code repository. The other contribution that I see a lot of, especially in my current community,
09:43
cube, we have a lot of non developers like data engineers or analysts that are interested in participating in your community by sharing their use cases. This could be something formal, such as a blog post, like sharing, you know, how they're using our software at their company
10:03
or in their industry. Or you could even be things like discussion, maybe it's on our forum on, hey, we sort of implemented cube this way, then we realized that wasn't working for us. So we architected it this way. And here are the improvements we're seeing. And that's, you know, they want to like contribute those conversations or use cases to the community.
10:26
And they're not as much as interested or, you know, have the expertise to contribute, you know, through code. So that's sort of, you know, that's the way they want to participate in the community. So if you're focused solely or mostly on your code repositories,
10:42
in effect, you're what you're doing is sort of ignoring those other contributions. And the two, like diagrams at the bottom of the slide, I mean, they're somewhat related. Obviously, I've been in open source for a while, and I like most conversations and activities to happen in public, so that other people can participate and have visibility to them.
11:06
But, you know, but you also have to be sensitive to some people because of the cultural reasons or background or even like people that are very experienced in open source. I mean, you'll see this when they first join the community. I mean, people all go through
11:23
the imposter syndrome. I mean, I go through them whenever I change jobs or change communities. And they're just not as comfortable or competent about having discussions in public. So even like posting something on Slack in this course could be, you know, could be, you know, somewhat stressful, especially in the beginning. And they're just more comfortable having
11:43
conversations with you, product managers or core engineers on a one-on-one basis to provide feedback on how they're using the software, what the challenges they're having, you know, feature requests that they may have. And you want to encourage them, you know, if they're not, you know, comfortable sharing their opinion in public for whatever reason, you want to give
12:05
them an avenue to share their thoughts, you know, on a one-on-one setting, you know, even if it's a quick Zoom call with me or like I said, a product manager, other people in the community, you want to sort of encourage them to, you know, still have a conversation with you. And then if
12:22
they make a valuable, provided valuable insight, you want to recognize them for speaking up, even if it's, you know, sort of in a one-on-one setting. And, you know, if it's appropriate, you know, highlight their contributions later on through recognitions if they're comfortable with that. So sort of flowing right along, the other thing that I've been working on,
12:48
especially in the past couple of years, is that I'm seeing quite a few people in various communities, they're just not very comfortable with public recognitions for whatever reason. I mean, I think a lot of us, including myself, made an assumption that like, who wouldn't want
13:05
to be in the front of the room and getting applause from rest of the community members, but that's not everyone's like a cup of tea, as they say, they're just more comfortable with sort of pat on the back one-on-one in a one-on-one more private setting. And, you know,
13:22
I need to be respectful of that. I mean, I, you know, I sort of had to get over that myself, where, you know what, if people just want to have a more private recognition, and because my goal is to really thank that person for making whatever contributions they made. It's, you know, it's, you know, if I can't, if all I do is, you know, conveying thanks, and I can't like,
13:45
sort of put a spotlight on them, or, you know, or point to that person as a role model, you know, I need to get over it. If they're not comfortable with getting recognition in a public setting, I need to be respectful of that. The other recognitions that, you know,
14:03
a lot of the communities are doing, including us, and we, you know, we launched this program in GitLab as well. I mean, one of my colleagues said, it's, you know, we wanted to recognize some of the top contributors from the community by sort of anointing them with titles, like Heroes is a title that's used at both GitLab and Qube. What I've learned is that,
14:26
especially at Qube, like, not everybody was very comfortable with the title. I was like, somewhat taken aback when I approached a couple of community members and say, hey, we'd like to nominate you as a hero because of the contributions you made over the past, you know, past year or so. And a couple of people actually sort of told me they're
14:52
uncomfortable with being called a hero. And they said something to the effect of, you know, I don't think what I've done is enough to be worthy of a hero. So I was, like I said,
15:06
I was taken aback, and I need to really think about this. And I reached out to a couple of my former colleagues or managers, who are, you know, very active in diversity and inclusion initiatives in various companies, to really sort of think about, you know, what's going on here.
15:27
Because, I mean, like I said, I was like, really taken aback, you know, like, who wouldn't want to be recognized and anointed a hero or ambassador, whatever the title is. And so like these, you know, people I reached out to, they
15:44
wanted both of what several of them did was asked me a question of what's your main goal of having a heroes program? You know, is it to really, is it recognition the main thing, or what's your main motivation? And my realization was that, I mean, it wasn't,
16:03
I mean, recognition, obviously, is part of it. But the big thing was, I wanted to have a group of, you know, trusted community advisors from the community that I can rely on for advice or feedback, things like if you're making an important UI, significant UI changes
16:20
to our product, or if we want to change the policies in the community for our project, etc, etc. I want a group of people that I can sort of reach out to for advice and as a sounding board. So what number of people told me was that if that's sort of the main goal, then we need to position this as more of an advisory group, versus like, we're putting
16:46
a spotlight on those people and highlighting their contributions and, and, you know, focusing on solely on recognition. So, you know, what we did was we sort of did a repositioning of the heroes program. I mean, I even thought about changing the title heroes to something else. But,
17:04
you know, we reposition this more as, you know, here are a group of advisors that are continuing to contribute to the community so that we're giving people the avenue to help community grow and help improve the community and the product. So that's, you know, so we sort of did this, you know, repivoting of the heroes program versus just, you know, having a focus
17:24
mostly on recognition. So people don't feel comfortable because they feel like just, you know, we're just putting them under the spotlight and, and, and highlighting them as a role model. And, you know, I also have to remind myself, these a lot of these people are contributing
17:41
because they like the, I mean, not just the process, like I say here in the slide, but active contributing. They're just, they're just like the act of contributing. And I want to just provide them more opportunities to do that as a hero versus, you know, highlighting their past work. So, so what can, what are some of the things that we can do to make
18:03
recognition more inclusive? And I've talked about these like indirectly a few times already. Obviously we need to look beyond your code repository or where your code lives. And I can also point out that, you know, even, you know, when you look at the, like, let's say
18:21
a pull request in the repo, it doesn't tell you the whole story. I mean, if you talk to the contributor who submitted a PR and got it merged, you might find out that, you know, there are other people that help with their work, whether it's through testing or, you know, providing ideas that's not going to be apparent when you just look at the pull request through
18:41
commit history or even comments. So we need to really, even, even the code contributions, you need to look beyond the code by having a conversation with the contributors. The other thing, I mean, like I said, we're, we tend to be sort of data obsessed in general, and especially in technical communities. And I think we're, tend to over
19:07
invest in sort of, you know, putting something into a metrics rather than trying to understand the background of their contributions. One of the things I like to do is if I see a
19:21
good contribution or somebody makes an interesting comment on our Slack channel is to have a coffee chat with them. I mean, so these are virtual coffee chat, usually through Zoom or like a Google Hangout, and try to find out like, you know, what motivated them to make the contribution than what their experience was. And what you'll find out typically is that,
19:44
you know, they're actually looking for more ways to contribute because they're using the software for free in a lot of cases, and they somehow want to get back. So they're looking for more ways to sort of engage and connect with other community members. And so, you know, rather than, you know, you know, focusing on, you know, who made like, how many contributions
20:07
really find out what, you know, what was behind their contributions through conversations at coffee chats, and hopefully, when things get back to normal after, after the pandemic, we can have these conversations in the hallways at conferences, you know, like us backstage.
20:25
So what are some of the other things that we want to do for recognitions? I mean, the other problem with metrics, it tends to be sort of backward looking. So you might not recognize somebody's contributions until like, weeks or even months later. So when you see something, even if it's a simple DM on Discord, just reach out to them and say thanks. And,
20:47
you know, they'll appreciate the fact that first of all, you noticed it, and two, you made a point of sort of reaching out. So even a simple thank you will go a long way. And it's not about it's, it's always good to send a nice token and gesture through like
21:01
a merchandise and swag. But, you know, people aren't doing, you know, trying to help the community because of the merchandise that they may potentially get. I mean, we like as community managers, we tend to obsess about the type of swag and the logistics, but just like metrics, like at some point, you reach a point of diminishing return. The other thing we want
21:25
community members to participate in the process. I mean, one of the things that I did at DLF for our project OPNFB, we led, you know, we used to meet once a year at a summit. And
21:48
we would also have awards for top contributors. And this was done entirely through the input of the community. The nomination process, the voting that was all done by community, all I did as a project staff member was to sort of administer the vote. I mean,
22:03
that's all I did. So, I think when somebody got selected as a top community, a top contributor, I think it was more meaningful because it was done through the input of community members. The other thing I want to point out, we want to avoid giving the impression of like ranking
22:22
like contributors. And I want to go back to slide five. You know, even if your intention wasn't to rank people through sort of metrics like these, people are going to see this almost like a ranking. And this is problematic, especially for the one on the right,
22:41
where you're trying to list how many contributions came from which companies. Large companies are going to have an advantage here because they just have more resources than people. And you definitely want to avoid giving the impression that somehow you're trying to rank people for the volume of the work they've done. So, just to wrap up on slightly
23:05
going along here, you know, like I said, I try to remind myself, my main purpose for recognition is to thank them and make them feel welcome. If I can't, you know, do the other
23:20
two aspects of the recognition, you know, two reasons for recognition, one of the earlier slides I showed in terms of celebration or highlighting role models, you know, I just need to get over it. I want to make him feel comfortable and welcome. And during the recognition process, you know, I want to form, I want to use it as a way to sort of form a closer
23:41
connection with that community member. And hopefully, you know, have that people more engaged, make them feel appreciated, and, you know, find an opportunity to have them connect with other community members. So, and because, I mean, that's, you know,
24:01
if I can thank people and allow them to form a closer bond with the rest of the community, I mean, that's what I need to look for. So, they feel included and welcome in the community. So, I'll stop here. I went slightly longer than I wanted to. If people have any questions, Alex, I don't know if you got questions during the session, but let me know.
24:27
Yeah, thanks for the talk. I think there isn't a question right now. But Brian commented that this was really insightful for him and really helpful. So, apparently, you struck a
24:41
nerve there. Maybe there's a comment. Dustin writes, a project I worked on at Mozilla had a contributor funnel where we wrote this stuff down. It was helpful for other devs, maintainers to know how to react and de-bias the process a little. It also had a long list
25:04
of possible rewards from SWAG and Rekognition through a network in networking introductions or help with that project. Yeah, that's a comment. Oh, cool. Yeah. I mean, I think one other example of having communities involved, I think I forgot to mention it. What I've also tried in other communities is to have
25:26
sort of a nomination. Because obviously, if you're working with hundreds of people, you're not going to know everything that's going on in different parts of the world. Have community members reach out to you and say, hey, I noticed somebody in Japan, for example, organized a meetup and did this wonderful job. Give them an avenue to let you know.
25:48
I mean, I tried like a Google forms or like a very casual slide conversation. Have a sort of a nomination process for highlighting what a great work somebody's done.