 So with that, welcome to my speech. Thanks for joining me today. I'm going to be talking about open source resilience and growth, basically how to create communities that thrive. And let me make sure I go to the next slide. Before diving into the talk. Oh, okay. Sorry, there's a lag for me. I wanted to introduce myself in case you don't already know me. My name is Naritsi Sanchez, and I am a senior open source program manager at GitLab. I joined there in February. And before that, I was actually one of the founding team members at Endless, which is a company that created a Linux based operating system for users with little to no access to internet. And that's how I got introduced to free and open source software and how I got introduced actually to the GNOME community and ended up contributing more to that. And I'm a former president and chairperson at the GNOME foundation. And I also wanted to include a little bit about my academic background since I don't know if it's as common to find in free and open source software. I studied international relations and psychology in undergraduate. And that's the lens through which I see the world. All right. So in this talk, I'm going to be covering a few different topics. The first half of this presentation is going to be about resilience and growth and some opportunities that I see for the KDE foundation and really all open source software projects. And then the second half of this presentation is going to be about collaborative communication because I think it's really a really important skill to build. Okay. So resilience and growth basically this year has been really tough and it's included us all, our personal lives, our professional lives and our open source communities. There has been a pandemic, there have been wildfires, there have been issues with racial and social justice. We've had to change our perspective. And there's been through the Black Lives Matter, you know, fight through lots of issues that are being surfaced in all areas of our personal and professional life and there's mass unemployment. And in our open source organizations, there's the lack of in-person events has really changed things for us. It means that we haven't had as many hackathons or sprints that are vital to the progress of our projects and our human connection aspect has somewhat suffered and that it's been great to be part of this virtual conference and chatting is really fun. I've seen, you know, some really funny conversations happen but it would be a whole other level to meet you all in person. And so what I wanted to talk about is just resilience. It means the ability to bounce back. And when looking through the American Psychological Association's website I found this framework that they have about resilience and how you have to take time and really be intentional about building each of these four focus areas which are meaning, wellness, healthy thinking and connection. And so I wanted to take this lens and apply it to the KDE community and open source communities in general. So really see what kind of opportunities we have in each of these focus areas. And before I move on, I just wanted to see if you all are having problems with latency in my talk slides because I'm getting quite a bit of lag. Any looking at the public chat? It seems good. It seems okay? Okay, great. So I'll keep going. All right. And please forgive me if you hear me pause for a little bit because I see a blank slide. Okay. So the first focus area is meaning. And for that it's really about helping your community understand why it is that we're all here. And to that effect, I think the KDE does a really good job. It has a very clear and powerful vision. Clearly stated on a webpage. It says that KDE imagines a world in which everyone has control over their digital life and enjoys freedom and privacy. And they also have a mission statement where it provides in-depth information on how to actually achieve that vision statement. And so I think that is a fantastic start. And I think that there's an opportunity to keep bringing that meaning to more people. And so I see an opportunity around building the brand, the marketing and doing more outreach to the community. And I love this quote by Robert McKee that really says that storytelling is the most powerful way to put ideas into the world today. And I think that early on a lot of Fox projects started off with really strong developer communities. And we've started to see the importance of building out other aspects, bringing in other skill sets. And I'd like to encourage KDE and us all to keep moving in that direction. I think it's awesome that they've employed contractors to help with brand and marketing and community. This event is being run by incredible organizers, some of which are paid staff. And I think that that's a really great way to ensure that the project is resilient and continues to grow. The next focus area is wellness. And when I think of wellness in the open source sense, I think about measuring the health of the community. And at the Gnome Foundation, I know that we haven't done a lot of data collection, partly because of privacy concerns. And I think that KDE is similar where it's either, there were real concerns to be and challenges that we face. And then part of it is just like, maybe we don't have the skill set or expertise to really put this in place. And so I think that this is an area where we can all grow is because people want to understand the projects that they're engaged with. For example, companies need to understand the value of the project and the impact that their contributions make. And open source foundations like KDE can evaluate the impact that their programs, that their work is having as they respond to their community's needs. And so the opportunity here is to start measuring our success and measuring our community's health. We all have annual reports where we do, but this is taking it to the next level. And for that, there's a project that exists today called the Chaos Project. If you haven't heard about it, please check it out. It is focused on developing metrics and practices to help organizations measure their community's health. And KDE and Gnome are collaborating on creating a set of metrics specifically for our foundations. I'm part of the working group. It's called the App Ecosystem Working Group. It's an open group to join. So if you'd like to check us out, I've included a link there. And if you are part of another open source project, I encourage you again to check out Chaos because I think it's a really great thing to look into as we continue to mature our organizations. The next factor is healthy thinking. And to me, this is all about policies and programs and kind of like how we are enabling our community from a high level perspective. And I love that KDE's mission statement includes this people-centric bit that says that in order to promote the development of free and open source software, KDE maintains a diverse, inclusive, and safe community. So KDE is specifically calling this out that the people aspect is important. And I think that's important because it then enables you to fund projects or programs that are specific to helping make sure that that happens. As I mentioned before, paid staff, I think that that's a really important thing to consider and that could be full-time or contractors. But I think that having somebody there that sees the, you know, organization evolve that is paid and dedicated to the project is, you know, to work on the project is really important. We at GNOME have even hired a full-time developer to work on GTK and, you know, other aspects. CIS admin, we're, look, we have somebody who's helping with fundraising, all that kind of stuff. And so I think that, you know, we're still in the experimental phase at GNOME in terms of understanding, you know, how many people to employ and all that kind of stuff. But I think it's a really important step to be taking. And then sustainability in general. One of the things here is that I'm not sure that we do a great job of collaborating with others to the degree that we could be collaborating. I was part of this organization called FOSS Responders that came into being to support organizations during COVID-19 because, you know, because of the lack of in-person events, we thought that they would be, that projects would be financially impacted. And I was just amazed at how many amazing people there from like the Python Foundation and Drupal Association and all these other ones that I know, you know, I know that they're there. I know that they exist and we need it. Events, but we don't do enough collaboration. And I think that there's, that's a key area and a healthy way of thinking is like, how can we continue to collaborate with more open source projects and really think about this from the ecosystem point of view. And I just want to, in case you haven't heard about it, there's this group called Sustain OSS. I have the link here. And it's a lot of people from different associations, from companies that have open source program offices that all get together to talk about sustainability. And the opportunity here for KDE and other organizations is that we think about also a broader set of skills and more diversity in open source. And with this, I mean, going beyond normal non code contributions, which are usually like documentation or translation outreach, but really challenging ourselves to think even further. For example, someone might be interested in building skills for sales or business development or they might have that expertise. They would be great for fundraising or partnerships teams here at open source, you know, at KDE and other open source projects. Or people who have HR and people skills or expertise. They'd be great for engagement teams, board of directors or newcomers initiatives. So again, let's think even beyond just the normal non code contributions and do outreach into those areas. The final focus area is connection. And this is all about people, people focus programs. I think social events are crucial to the health of communities. And I was so happy to see that here at Academy, we have a couple of social events coming up. I've included links here just in case you haven't already signed up. I'm signed up for one of the escape rooms and really excited about it. And I think it's really important to have these regular social interactions so that you keep building relationships with the people that you're working with. It really helps newcomers feel connected, people who are already part of the community to feel motivated to continue to contribute. And I think it's, it's great to remember that we're a global community. So time zones and like the way that you connect is really important. Some people may not have great internet connections. Maybe a chat based thing might be more useful in certain situations versus maybe video would be better in others. So thinking about all those things. On-boarding initiatives, I think that's really important for the connection. Having some sort of a personal touch might be great to incorporate into such a thing. And I love that Katie is thinking about this. I know that the move to get lab was actually part of this where you're thinking about the newcomers experience and the types of tools that will help make it easier for people to contribute. So I want to encourage that continuation to think about the people first. And again, I think that it's really important not just to focus on the technical skills that our community has, but also the people skills. And so having people oriented training on things like implicit bias, which I know happened earlier in Academy and I'm bummed that I missed out. We at GNOME had this code of conduct training for events teams that they know how to handle complaints and to actually implement a code of conduct. And things like collaborative communication, which is what the rest of this presentation will be about. I think it's really important to build in these people skills into a community in order to make them resilient and in order to enable just collaboration in general. So as I mentioned, the rest of this is going to be around collaborative communication. And if you've seen some of my other talks this year, this will be a pretty condensed version and it won't have all of the topics, but I hope you'll still learn something today for people new to this topic. I'm going to start off with some of my favorite hacks and these are ones that I really would love everybody in the world to know. The first is that it is the writer's job to be understood and for this formatting really helps. So I know that sometimes when we're writing issue descriptions or anything else, we sometimes we have bullet points and sometimes bullet points even like we think that that's good formatting, but it can end up looking like a wall of text. So here you'll notice that I have bullets, but I'm going to be bolded the first item to kind of give you a sense of what the rest of the bullet will be and that really helps somebody be able to skim through it and understand like what they're most interested in or be able to refer back to it later. So that's a really handy thing doing a skim test. Also making sure that you understand what if you have a call to action and what that is, make sure to state who needs to do it and by when. Try to avoid long sentences, break them up if at all possible and then do not assume previous knowledge. Make sure that it's easy for anybody to just jump right in and this might even be thinking about like the acronyms that you're using or just the terminology that you're using and it might end up excluding others. So make sure that you think through it through that lens to make sure that anybody can jump right in. As I mentioned, a lot of us are spending time writing things in issues and communicating via merge requests or other things that are development oriented. And I think that formatting is really important there. Here's an example of an issue that our social team actually created at GitLab where when you have this is an issue template, so whenever you have a request for them you can easily go through all of the steps that they need you to fill in and be able to submit it. And here you see that they've made use of different titles of checkboxes, of emoticons and all of this really helps you be able to perform the tasks that they need you to. So I want us all to keep that in mind as we're writing our own issue descriptions and sometimes when we open feature requests or file bugs, they can sit around for years and if they're really controversial they might have hundreds of comments in them. And so it's important for us also to treat the description area as a living document, as a living section because we might want to have a summary of what the conversation has been so far or what's going on. That way people don't have to read through 752 comments and try to understand what's going on but they can get a quick sense of what's happening and then go into the comments to get further detail. So again this is keeping in mind that everybody should just be able to jump right in. This next one is one of my personal favorites. And so basically it's instead of saying no or yes but which is a favorite of many people just try switching it to yes and. So you can say something like yes I hear you and I disagree. So just by using that and it acknowledges what the person has just said and it lets you still disagree. It makes somebody more willing to listen to you because they feel heard and understood and then they're willing to try to hear and understand you. So it's a very powerful psychological difference. I really encourage you to start using it. And it's so cool that just one little word can have such a profound it can make such a profound difference to how we collaborate. And that can make somebody go from feeling attacked or like not listen to feeling heard and wanting to collaborate. And so collaborative communication collaborative phrases are so important. Here's a list. You're welcome to screenshot it. And so an example I won't go through all of these but the very first one. How might we another alternative of this that isn't as collaborative is we need to solve this challenge. It's a statement it's you know saying we so it's inclusive. But if you just change that to how might we solve this challenge it then goes from kind of like a closed off feeling to more of like a I'm invited to participate. I get to give my input and my ideas. And so that one little switch again makes a huge difference. And a lot of these phrases do the same. I encourage you to read up on other ones that might help you to. All right. Next section is navigating cultural differences. And this is really important as we continue to expand our communities and diversify our contributor base. This section is really based off of the culture map which is written by Erin Meyer. She does research into this topic. And she's plotted out countries along these seven indicators which are communicating evaluating leading trusting disagreeing scheduling and persuading. And while I don't have time to go through all of these I'll cover a few. The first one is communication. Here we go communicating. We have low context cultures and high context cultures. Low context value communication that is precise, simple and clear. Oftentimes repetition is used to avoid misunderstandings. Versus high context cultures care about sophisticated language and nuanced layered. Oftentimes you have to read between the lines. The next indicator is evaluating. And this has to do with how people deliver negative feedback. Direct negative feedback cultures deliver feedback frankly, bluntly, honestly. They don't soften them with positive feedback or positive messages. And they oftentimes use absolute. So things like you always do this or you completely failed things like that. And it's okay to give negative feedback in front of groups. On the other hand, indirect negative feedback cultures deliver the feedback softly, subtly and diplomatically. They often use positive messages to wrap negative ones. So you might have heard of the sandwich effect which is positive thing. You give your negative feedback and then you end with a positive sandwich effect. And oftentimes qualifying descriptors are used like you sort of do this a little bit sometimes. Oftentimes feedback, this negative feedback is given in private. And so you can see how if cultures value giving negative feedback in different ways. This could be really problematic in any situation and especially online where sometimes like other context missed with like facial expression or just in general like the physical cues that you get. So it's really important to understand that this difference exists as we navigate these different relationships and different scenarios when we're working in open source. This last indicator is persuading and this is principles first cultures before anything else. They've been trained to develop the theory or the concept first before presenting facts, statements or opinions and applications first cultures value the how or the what first. They're trained to begin with the facts and the statements and then back it up as necessary. And what Aaron Myers mentioned is that somebody from France might get really frustrated when they're working with a manager from the United States for example that is constantly asking them to do something and mentioning the how and the what but not really the why. And so again I just think that this is a really interesting indicator to know about as we consider how we work with others. And lastly I kind of wanted to show how this actually works by choosing an example of the PDEV board of directors is from or what cultures they might identify with and I didn't consult all of the board members I'm sorry so this is just my best guess based on some information that I've been able to gather. So this is we have directors with backgrounds from Canada, Germany, Greece Netherlands, Spain and as you can see there's a map of that visually right. We'll just choose the trusting indicator which is kind of in the middle of that all and you can see that some of the board members are from cultures that are task based and trust building which means that the way that they build trust is by doing tasks with others like how well do you perform how like can I depend on you from a work perspective. Versus there are some board members that are more from the relationship based trust building which they really need more of that personal connection and understanding do others trust you what else do you do in your life like what's the full person here that I'm interacting with and so with this it would be really great for the board to have both to really work on building both types of trust make sure that there are some social events where they can get to know each other over lunch or you know drinks or whatever it is and keeping in mind that others might build trust more through just working together and really like carrying out the tasks so by looking at maps like this you can start to understand the working groups or the people that you normally interact with and develop more empathy for the approach of everybody. All right final tips I'm almost at time and the first is really to invest time and understanding the people that you work with don't make assumptions I just kind of did in the last slide but somebody may not identify as the culture of the country where they were born or someone might look like they're from a certain culture but they may totally identify with a different one so don't make assumptions and then I think that it's okay to set expectations and I've included a link below to check out the cross-culture collaboration guide which is what inspired this section of my talk but you know in the cross-culture collaboration guide they really mention you know get lab values this type of communication or like this is the leadership style that we have and I think that's okay but we need to also understand that as we're building diverse teams and having for example an interview process that really values high-context communication that means that you might be you know not allowing people from high-context communication cultures to be part of your company so you really have to understand these differences and see how they're affecting our interviews our interviews and everything else. All right and I'm going to end with this quote which is communication works for those who work with us. This is a quote by John Powell and this really is meant to just encourage you to continue to develop your communication skills it's something that is quite technical in nature in many ways like there's psychology behind it and that you know it takes research to really understand how best to communicate and so I think that by having resiliency into your program into your open-source project because people are able to bounce back more easily by having that human connection. So that's it I'm at time so if you have any questions feel free to send me a message on LinkedIn, Twitter, at me on GitLab and I'll be reading the shared note stock later in responding there. Thank you very much. Thank you so much and we see that it was super interesting and I hope many of us will take some interesting learnings from it and yeah there are a bunch of questions in the shared notes maybe you can answer them in the chat later also. And that concludes our second day of talks at Academy. Thank you very much.