We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Are we being inclusive with our community recognitions?

00:00

Formal Metadata

Title
Are we being inclusive with our community recognitions?
Title of Series
Number of Parts
287
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Recognizing community members is one of the most enjoyable activities for community managers. It is a great opportunity to thank people for their work and highlight their contributions to the rest of the community. However, we need to evaluate if we’re truly being inclusive with our community recognitions. For example, when discussing contributors, we still see a lot of emphasis on the volume of contributions on project repositories (i.e., code) that some may find intimidating. This focus on code is partly because contributions on tools like GitHub and GitLab are easier to measure and quantify. On the other hand, it can be more challenging to measure (or even notice) how much a community member is helping others on platforms like Discord, Matrix, Slack, etc. When someone helps a newcomer by answering a quick question in chat, it’s easy to miss that among other discussion threads. Even though it can be more challenging to quantify non-code contributions, it’s crucial to look beyond repositories to see how people are helping to improve our communities. In addition to contributions in chat-like platforms, this can include sharing their use cases, participating in meetups, providing honest feedback in 1-on-1 conversations, etc. Looking across a broad spectrum of contributions will help ensure that we recognize everyone regardless of their background, interests, and skillset. Also, not everyone is comfortable with public recognition. Some may feel uncomfortable being in the spotlight or even think what they have done is not significant enough (sometimes I see this with contributors from underrepresented groups). In these instances, it is important to find ways to let them know that the community appreciates their work without putting them in an awkward position. In this talk, Ray will share his experience identifying different contributions, community recognition examples (both good and bad), and feedback he received on community recognition programs. There will also be a discussion on how inclusive recognition is vital for strengthening the sense of belonging in the community.
CodeOffice suiteRepository (publishing)Online helpQuicksortGroup actionConnected spaceRemote procedure callCycle (graph theory)Software developerNumberMultiplication signBitEvent horizonEndliche ModelltheoriePattern recognitionRow (database)Focus (optics)Thermal conductivityStatement (computer science)Order (biology)SoftwareDifferent (Kate Ryan album)Source codeData managementMereologyCodeMetric systemData conversionDisk read-and-write headShared memoryQuantificationSelf-organizationSpacetimeCASE <Informatik>Projective planeOperator (mathematics)Analytic setType theoryOpen sourceTranslation (relic)String (computer science)Time zoneData analysisRight angleElectronic mailing listIntegrated development environment2 (number)Term (mathematics)Ideal (ethics)DiagramComputer animation
SoftwareLaptopPoint (geometry)Message passingQuicksortSystem callService (economics)Source codeInternet forumTerm (mathematics)Data conversionMereologyFront and back endsCASE <Informatik>Computing platformFeedbackError messageNumberDifferent (Kate Ryan album)Open sourceBlogOnline helpOnline chatLevel (video gaming)Computer animation
Process (computing)NumberFeedbackInternet service providerFocus (optics)Product (business)Computer programmingDifferent (Kate Ryan album)Data conversionGroup actionQuicksortTerm (mathematics)Pattern recognitionSoftware developerSet (mathematics)Boss CorporationPoint (geometry)Medical imagingOpen sourceCASE <Informatik>Decision theoryShared memoryMathematicsVector potentialHydraulic jumpOpen setComputer animation
Process (computing)Data conversionWebsiteMereologyEmailQuicksortElectronic mailing listFocus (optics)Multiplication signSoftwareLatent heatPattern recognitionCodeDifferent (Kate Ryan album)Metric systemData managementTerm (mathematics)Point (geometry)Series (mathematics)Projective planePivot elementGoodness of fitContext awarenessGroup actionComputer animation
Process (computing)RankingMultiplication signSelf-organizationTerm (mathematics)Sound effectQuicksortPoint (geometry)Process (computing)Projective planePattern recognitionTelecommunicationForm (programming)Metric systemFlow separationOpen sourceTheory of relativityNominal numberWordStack (abstract data type)Group actionSelectivity (electronic)BitRankingRight angleWhiteboardCycle (graph theory)1 (number)Inclusion mapComputer animation
Process (computing)RankingBuildingSocial classSelectivity (electronic)Event horizonQuicksortPattern recognitionZoom lensTerm (mathematics)Process (computing)Product (business)System callMultiplication signCodeFeedbackPoint (geometry)Projective planeOpen sourceRankingDifferent (Kate Ryan album)Self-organizationRepository (publishing)Pulse (signal processing)MereologyBuildingStack (abstract data type)Data managementVolume (thermodynamics)Computer animation
Computer animation
Transcript: English(auto-generated)
Hi, my name is Ray Paik, I'm the head of community at Qubedev, and it's good to be part of FOSM once again, although it's virtual. And here to talk about how we can make our community recognitions more inclusive.
There's a Twitter handle on the slide. So feel free to reach out to me after the talk if you have any questions, or want to have follow-up conversations. So a little bit more about me. I, you know, been involved in community management for,
I guess, the past seven or eight years, started when I worked at the Linux Foundation. I worked as a part of a number of different networking projects, and after about four years, I joined GitLab in the middle of 2018.
And you're probably, you know, most of you are probably pretty familiar with GitLab as an open source project in a company, and it was exciting to see, continue to see the growth of contributors and community members while I was there. And about 14, 15 months ago, I joined a new community called Qube, where it's still a relatively young community, less than three years old.
You know, we started out as an, you know, open source project in the data analytics space. And our mission is basically to make, you know, all your data accessible from all your modern data sources that you typically have.
And we want to make it accessible to everyone in the company, whether it's, you know, developers developing internal applications in-house, or even your customers who can benefit from getting insights into your data. So feel free to check us out if you're not, if you want to learn more, but, you know, want to move on to our topic at hand.
And what I'll talk about today, you know, a number of things, I mean, first is, you know, why recognitions are important in open source communities. And what we typically see in a lot more like a traditional open source communities.
And some of the challenges with those, you know, some of the more traditional recognitions that we've become pretty familiar with. And what are some of the things that we can do to make our recognitions more inclusive? Because, you know, obviously, I think all of us in
open source or society in general want to make the place we work in, you know, more inclusive and be welcoming to everybody who wants to participate. And obviously we'll have time after the recording for Q&A's and definitely look forward to that as well.
So why is, you know, community recognition important? I think, you know, I can think of three main areas. I mean, first one might be a little obvious. I mean, it's, you know, important to thank people in general as a, you know, help other community members. And, you know, those of us in the open source community, we've been working in this like all remote,
you know, asynchronous work environment, well before the pandemic, but I think a lot of people are experiencing this. When you work in a, you know, sort of a traditional office setting, you know, pre-pandemic, it's easy enough to sort of stop by somebody's office or desk and give a high five and do a quick celebration for, you know, whatever that person help accomplish.
It's sort of had a lot easier to have like impromptu interactions with people. And as a result, give that person a pat on the back. And this is a little harder to do in a remote work environment. You have to go
to make an effort to actually do this, reach out to the person to give people thanks. But it's pretty important that that's something that, you know, we all, you know, should put a lot more effort into in, you know, open source communities as we all work in different parts of the world.
A second reason is, you know, what I call role modeling. You know, a lot of communities have like code of conduct or mission statements and values. And there are a lot, you know, certain behaviors that we obviously want to encourage based on, you know, who we are. I mean, you know, things like, again, like helping newcomers feel welcome in the
community and helping get onboarded and get started and be productive in a short order. That's obviously something that we want to encourage everyone to do. And by recognizing, you know, a group of people who've been instrumental in that over a period of time. Obviously, that's going to, you know, put a spotlight on the importance of that value and importance of wanting to continue that tradition.
So it gives us sort of an opportunity, the recognition gives us an opportunity to sort of highlight, you know, what you call like a role models in the community. And finally, you know, it's, you know, these recognitions are opportunities for, you know, community celebrations.
You know, obviously, this is a little bit more difficult to do as we're working asynchronously in different time zones and remotely because we don't see each other very often outside of, you know, in person events.
So it's good to sort of take stock once in a while. Maybe you had a successful launch of your new feature. You know, maybe you have a regular release cycle. It's good to sort of pause and celebrate as a as a as a community, as a group and sort of reinforce that connection that we have with each other.
So what do we see very often in open source communities? And I want to share some some examples that I've seen. And, you know, and the other thing I want to point out, if there are if I talk about examples that are less than ideals in terms of helping with diversity and inclusion, it's the these are some of the mistakes that I've often made in the past.
So the couple of charts here, I mean, one on the left basically sort of list people who had most number of like a PRS or merge request merge throughout the year, as an example, maybe at the end of 2021 or starting part of 2022.
Maybe you'll publish a sort of list like this. And here are sort of the top 15 or 20 contributors and one on the right. I mean, you often see this from foundations. They want to talk about like, here are some of the companies that have been very active in their communities or their projects.
And, you know, they're basically counting whatever you want to define as contributions. It could be commits. You know, it could be PRS merge, issues closed, you know, number of translation strings that was successfully translated, et cetera, et cetera.
However you want to define contribution, basically this sort of list, you know, the number of organizations that had the most contributors, as an example. And there are a couple of issues with this. I mean, one is that often like these types of, you know, metrics or your recognition focus mostly around the code.
So you're looking at activities around your code repositories. It could be GitHub or you might have, you know, or you might have GitLab, Bitbucket or other tools, whatever you're using. But if you think about this, you know, think about open source community over the past
10 years, maybe 10 years ago when you joined the community, it was mostly comprised of developers. That's not the case anymore. I mean, you see a lot of users. And I mean, especially in like the networking space, you see a lot of operators from Telcos who are not necessarily developers.
And data analytics space that I'm in now, you see a lot of data engineers, analysts, you know, who are not necessarily interested in programming. So by focusing too much on code contribution, you're basically ignoring a huge
swath of your community members and obviously that's not something you want to do. The second issue that we have with this is that there's too much emphasis on metrics or whatever can be, you know, quantified. And I think a lot of us know who's been in community management or working in, you
know, open source community in general know, I mean, metrics and dashboards are pretty important to have. But they don't tell you the whole story, what's going on in the community. So just focusing on what can be counted, you are potentially sort of ignoring other contributions that people are making.
So I'll share some examples of those here. First, I mean, I think a lot of communities have, you know, use chat like platforms, whether it's Slack, Mattermost, Discord, or even, you know, IRC, you know, for more traditional, you know, open source communities.
And there are a lot of people that are very active in terms of like helping other community members or especially like new people get up to speed in these, you know, chat platforms. I mean, somebody might post a question, hey, I'm trying to get the QJS software up and running on
my laptop and I'm struggling to get my playground up and running because I'm seeing these like error messages. And invariably, you'll see, you know, within, you know, minutes or within a few minutes, like if somebody chime in and say, hey, this is I've seen that error before. And this is, you know, here are the issues that you're running into and here's how you sort of fix that issue.
So, I mean, the contributions they make, I mean, is, you know, obviously invaluable and something that we want to recognize. And I've, you know, seen over the past years, I've actually been, had a number of people contact me.
These are companies that are typically setting up, you know, dashboards or trying to quantify contributions on some Slack, like, you know, how many conversations did somebody start? How many messages did somebody post? I mean, that's obviously, you know, somewhat helpful, but it doesn't tell you the whole story.
I might know, you know, this Contributor A posted 13 messages over the past two weeks. But, you know, it doesn't tell you anything about those messages. Were those messages like, you know, more questions or making announcements or was it really helping other people?
So, you know, to get a really sense of that, I mean, I don't know other way of really doing this other than reading, you know, carefully sort of parsing through messages and trying to find out what contributions that somebody is making. So that's one. And the other example, other ways that is particularly users have been contributing to open
source communities, including the one I'm in currently at Cube, is people sharing their use cases. You know, somebody might be from financial services industry, you know, they describe their sort of backend infrastructure. They talk about these are sort of the journey that we went through to successfully like you.
And this is how we're using it today to serve our internal stakeholders and customers, for example. I mean, it's a valuable reference for, you know, people that are in the other financial services industry, or maybe this person is using, you know, Snowflake as a data source and having those reference points for other people to sort of, you know, to follow
as a use case or even some cases like recipe is extraordinarily helpful. And their contribution, you know, it's not necessarily technical, but I mean, that's something that we obviously want to recognize and encourage people to do more of.
And, you know, you want to go beyond again, just, you know, you want to go beyond like certain person has, you know, published like three use cases or three blog posts. That doesn't really tell you the whole story. I mean, that's what we really want to focus on is, you know, how did it help other community members and I mean, that's the aspect that we want to thank them for and recognize.
The, the other point here that I want to make is not everyone is comfortable making their contributions public. And, you know, I, you know, this part of this could be cultural or part of this could be their
personality. I mean, by default, I like to have people have most of their conversations and in the community done publicly. But, you know, if there's a reluctance on individuals' part for whatever reason, I mean, maybe they're not, you know, comfortable, completely comfortable with communicating in English or whatever reason.
They're more comfortable communicating with you one on one to provide feedback and share their use cases or recipes. I mean, you don't want to prevent them from doing it. I mean, the least I can do is get on a call with them and, you know, take their feedback or their
contributions and, you know, and then also recognize them for making an important contribution to the community, although it wasn't done publicly. So you also want to sort of moderate or give different avenues in terms of, you know, how different ways that people can contribute to the community based on their comfort level.
This other topic here, this is something that I sort of have to think a lot about over the past year or so, particularly last year in 2021. And although I've seen this in the past, I mean, I'll share an example where why this
became something of a concern for me or, you know, something that was on my mind a lot. So one thing that we need to recognize is that not everyone is necessarily comfortable with public recognition.
So, I mean, you see, you know, two sort of contrasting images here. I mean, one person's getting accolades in front of the crowd, sort of put on a pedestal versus somebody that's sort of getting recognized or getting thanked on a one on one setting, a more private setting.
So that's something to keep in mind. It's something that I try to sort of be mindful of. So I realize that a person's not necessarily being recognized in a public setting. They just wanted a more quieter or private recognition. And that's something that I need to be mindful of.
The one example of this that I wanted to share was a lot of communities have different titles or programs for their, you know, important contributors. I mean, you can be so like various titles like, you know, Community Advisory Board Member, Ambassadors, Heroes is something that's sort of been popular in a lot of communities recently.
And as a matter of fact, both at GitLab and Cube, we have these title heroes for people that have been making important contributions to your community.
And when I had conversations with, you know, what I consider the potential heroes in our community at Cube, I was a little taken aback by, there was a certain number of people that just didn't
really embrace, didn't necessarily sort of jump at the opportunity to become a hero in our community. They didn't necessarily like embrace it. And a few people in particular that were from, you know, traditionally underrepresented communities and open source made a comment that, you know, Ray, I'm thankful, like I'm flattered that you asked,
but I'm not sure if I've done enough to really be a hero in the community. And they sort of, you know, backed off. So that was sort of somewhat of an eye opener. I think, you know, for like 99 plus percent of the people, I
would assume that once, you know, I extend the invitation or nomination, they would almost automatically accept it, but that wasn't the case. So I had to really think about how I framed the conversation with potential heroes and then also how I framed the program. So I had a number of conversations, especially with my, I mean, some of my
former bosses were actively working on different diversity initiatives and in different communities or different companies. And a couple of things I want to share in terms of feedback I got, I mean, one was that the title hero just gives you the impression that you're putting somebody on the pedestal and putting a big spotlight on them.
And they reminded me that's not everyone's cup of tea. Not everybody appreciates that and not everyone is very comfortable with that, especially with people from underrepresented communities.
And the other, like a comment, or this is more of a question they asked me, was what are our goals of nominating or selecting somebody to become, you know, one of the heroes in our community? And, you know, my main point was I wanted to sort of have a group of people that we can sort of tap
and get sort of advisory or guidance when we're making important decision for, it could be for our product or it could be regarding our community or even governance. I mean, one example was that we were considering a UI change for our developer playground, and these are some of the key people that were involved in the conversations
that we can sort of reliably like reach out to. And the comment that, you know, a lot of the folks that I talked to made was that if that's the case, if, you know, having an advisory group is the main point, then that should be the focus. I mean, when I sort of present the program, don't talk about it
as this is sort of an honor or recognition that we're giving to people that have made, you know, a lot of contributions in different ways, but, you know, present this more as an opportunity for these community members to continue to help the community and provide advice and guidance
to help grow our product in the community. So, you know, what we did, at one point, I even thought about considered, I even considered like remaining the program from Heroes to something else. But, you know, we decided that wasn't necessarily, that wasn't exactly what was needed. What we did was to
sort of, you know, reposition how we presented the Heroes program, for example, on our website as, you know, this is sort of group of advisors that we were looking to work with to help improve both our project and the community.
So, you know, I sort of had to do a slight pivot in terms of how I start these conversations with community members. And the other thing, the big realization that I came to was that the main point of doing recognition is to thank people for what they've done for our software and the community.
It's not necessarily just to show off how cool our community members are or how cool we are as a project. So that's something that I try to keep in mind, you know, as I consider, I mean, not just for the Heroes program, but different, you know, recognition that we're doing in our community.
So what can we do to sort of improve things? Now that I talked about some of the challenges that we have, and the first one I've already talked about is, you know, look beyond the code, look or look beyond the code repository, because when you see like a PR, maybe it's a series of PRs
for, you know, specific feature improvements or a new feature for your project. The PR in and of itself, I mean, you might look through the PR, look through the code, comments on all the reviews, that only tells you a part of the story. That doesn't tell you about, I mean,
for one thing, that doesn't even necessarily tell you who all was involved in creating that new feature, as an example. The discussion on, you know, adding this feature or fixing this particular feature may have happened in things like the mailing list or other hallway conversations that have happened, you know, offline. So it's important to talk to some of the people that were,
you know, involved in those discussions to make sure that if I want to sort of recognize a group of people for developing this important feature, actually talk to those people and make sure that I'm including everyone that sort of
helped get these things started. I mean, there may have been an intern at a company that, you know, they didn't necessarily participate in the repository, but they may have been in the background sort of facilitating their work. And that's something I need to keep in mind. So look outside of the code. I mean, look at, you know, reach out to the people, even if it's one on one and to get more background in terms of what work was involved and who else was involved
to find sort of the hidden contributors that may not be apparent just by looking at the code. The other thing, you know, I talked about a lot of emphasis on metrics and quantifying things.
I think to a certain extent, a lot of community people or community managers spend way too much time sort of instrumenting things so that it's easy to do, sort of create a dashboard or quantify things.
You have to ask yourself, is that really a productive use of your time? You know, one of the easiest way to sort of recognize people is to actually reach out to the person. If you see something wonderful that was being done, either in Slack or other channels or other tools that you're using in the community,
once you see something, just reach out to the person in a timely fashion and just getting on the phone and thanking them in and of itself is an important recognition. And then actually have a conversation about, you know, sort of their motivation for doing something, for example, or, you know, how they got started.
And then a lot of those conversation materials, a lot of the things that you discuss with those individuals are not going to be quantifiable. I mean, it might be just something that you want to jot down in your notes. And this is something that, you know, I've been doing for a while, both at GitLab and here at CUBE,
is to have like a virtual coffee chat with community members. And, you know, I try to take it. No, it's not necessarily blow by blow account of the conversations that have happened, but these jot down highlights of the conversation, even if it's in bullet points.
And I take a note of that, you know, you can put it in either Google Doc or I happen to use Notion here at CUBE, or you can put it directly on your team so that they have a background, they have more background of their contributions and different community members.
So don't focus too much on like instrumenting things to quantify and create new metrics. I just take good notes and get a get a good context in terms of, you know, what motivated a contributor and their work. A few more things, and I mentioned this a bit earlier, you know, time may come, you know, one of the, I think, let me back up a bit here.
One of the other shortcomings of metrics is that it tends to be more backward looking. So you might not notice like, you know, somebody made this contributions, you know,
a month or even several months, like down the road, because you're just reviewing like the data points from from from a dashboard, for example. And then, you know, besides not having context, like if you're looking if you're looking at a backward looking sort of sort of metrics, based on like a monthly or quarterly data, you may not recognize a
contribution like, you know, weeks until weeks after that contribution was already made. But if you actively, you know, pay attention to communication channels and communicate with community members, you'll have the opportunity to sort of thank them.
You may not be real time, but, you know, a few days after, or maybe most like a week after the contribution and just the fact that just reaching out to them and thanking them is is is it goes a long way, especially if it's like very timely. And second, and somewhat related point I want to make here is that it's obviously good to send out like, you
know, especially if you have nice merchandise and cold swags to community members after you had a chance to thank them. But it's not always a requirement. I mean, no one's like motivated by, you know, 1520 $25 merchandise.
That's not why they're contributing to open source projects in general there, they have intrinsic motivation that's driving them. Right. So, although it's a nice token of appreciation. Don't make it about all about like swag and spend too much cycle on that and I've actually
had community members in Europe, tell me, hey, if you're shipping from North America, you know, please don't. I want to reduce my carbon footprint and I don't need you to, you know, put something in. In mail so that so it has to fly across the Atlantic.
So, you know, I took that to heart and appreciated that so you know there were, you know, for them just a recognition and a word of thanks was it often swag isn't something necessarily we're looking for. The other point that I want to make in terms of, you know,
making the whole process inclusive is, you know, including community members in the process. You know, one of the things I did at get lab was created like a nomination for him because I mean if you have hundreds several hundred or even thousands of people contributing. There's
no way like a one person or even a group of people like several people in the community relations team what now, everything that's going on. So I created a nomination form to encourage community members to sort of highlight things that we may have best. It's a simple Google form just, you know, you know, write down who the individual was a need to reach out to and the contributions they made.
So it's an easy way to sort of get community members involved in the process. And the other example I want to share and this is something we did when I was at the LF was our project OPN FB had an annual summit so once a year we'll all get together and
one, you know, in select location, worldwide. And one of the highlights of the summit was recognizing what we call sort of top contributors, and this whole process what was done through community nominations, and also voted on by community members.
So all I did was sort of administer the process for nominations voting and then, you know, securing the award. So, I think, even for people that were gotten the awards as you know quote unquote top contributors like appreciated that
more because it was voted on by community members it wasn't they weren't like anointed, or it wasn't selected by executive director for example, or board members so you know just having these selection process sort of own from ground up by community members I think made it meaningful for everybody involved.
The other point I want to make, and the chart, the two charts I showed earlier in terms of like your sort of top 1015 contributors or top organization with most, most people participating in a project.
The effect of those chart. You know, it's has what what the, the fact that had those charts have is that you're sort of stack ranking like individuals or like organizations. And they're obviously there are a couple of issues with that I mean one is you're awarding by quantity.
I mean solely based on quantity or volume of activity. I mean they made that in and of itself is not necessarily a bad thing, but what that does is that if you're from a large, larger company or large organization with a lot of resources. You're probably going to have a lot more time to contribute to the open source project versus somebody who
works at a, you know, 1015 person person company so you're, you know, almost automatically putting the contributors from smaller organizations at a disadvantage and obviously that's not necessarily inclusive thing to do.
So, you know, again like try to avoid like stack ranking individuals or organizations and so that everyone feels included and so even like a people who can only afford to contribute like a few times a month. I mean, we don't want to like a discourage their activities right i mean what, why should we put those people.
You know, you know, cheat them like almost like a, you know, not first class citizen so I mean that's you know something that that we should all avoid. And the final point here, you know, I won't, not going to dwell on it too much
but this is actually a hard thing to do. I mean trying to find a merchandise and swag. I mean it's easy to fall into the trap of hey I went to this conference or I've seen other community sort of give out this, you know, product at their show so I'm going to do the same thing but you really want to think about if that's appropriate
or that's going to be appreciated equally by by global community, and I know this is hard because you know what works in North America doesn't necessarily translate well and other geographies but you want to be sensitive to, you know, to, to, you know, making selection for
swag for your next event for example and obviously having feedback from the community is going to be helpful and then, you know, again, letting community members sort of participate in the process might avoid pitfalls, help you avoid pitfalls. Sort of quick wrap up.
You know something that I try to remind myself. I mean, first of all, like I said, I mean the main point is to thank people for contributions. So, you know, that should be the first and foremost priority. When you're doing recognitions and make sure that, you know, in the process that you can do it in an inclusive fashion.
So, and, and as part of that, you want to look for, you know, you know, different ways that people are contributing and who's participating, and then you're not going to be able to do that effectively if you're just looking at, you know, your code repository
so try to be inclusive. See where, you know, different community members are gathering or creating. And, you know, it's very likely that it's not always a code repository see we people are gathering where people are communicating, and so people get pulse on you know what's going on, so that you recognize all the work that's being done and then you have a chance
to connect with them. And final point. You want to use recognition as an opportunity for like a relationship building even if it's like one on one, you may have like reached out to somebody through the M or or a zoom call.
You know when you're sort of, you know, thanking that person you should really opportunity, use that opportunity to really get to know the community manager and build relationships. And that's, you know, that's also going to be what's meaningful for that community members as well it's not because, you know, I call somebody up and, you know, offered to send them.
Send them a nice swag, but I think the fact that I first of all noticed their their contribution and appreciated and made an effort to reach out to them. That's what's what's important. So, you know, use the opportunity to build relationship and, and, and use an opportunity
to sort of sort of celebrate another contribution, and continue to grow up to the community. You know, will definitely help go a long way in terms of making everyone feel welcome and then that appreciating the community. So, I think that's the end of my, my time here, and I'll, I'll see you
during the q amp a session and look forward to me further interactions. Thanks very much.