 I'll go ahead and get started. Thank you, everyone, for joining me this afternoon. My name is Chan Vong. My pronouns are she, her. I'm a technical program manager with the Comcast Open Source Program Office. And I'm super excited to share with you all that our Ospo is the first Ospo that we know of to be a team of all women. So I'd like to kick this session off by asking the audience here in person, if any of you are part of an all women team. Raise of hands? Just one? OK. Have any of you been part of an all women team in the past, whether in this industry or another industry? OK, another person? OK. And are any of you part of an Ospo, an open source program office? OK, a few of you? Well, thank you for joining me here today to not only celebrate this, but to join me in hearing why this topic is really important. I also want to talk about some of the challenges women face in open source, along with myths we hear in open source. Then we'll discuss some of the approaches in building an effective open source team based on some of the experiences from our Ospo. And lastly, I hope we have time at the end for discussion. So why is the topic about an all women Ospo important? Why do we even care about it? For me, this is about documenting history. And documenting history is important because it allows us to understand things around us. And it gives us a sense of how things came to be, right? And in this case, with the first all women Ospo, it shows the world what is possible. It shows companies and organizations that women are in open source and that a team with all women can be successful. But we know that women are left out of history. And not only are women left out of history, but we're actually currently not learning about women's history or the history of underrepresented groups in our own education system. There's actually a report out there that was released in 2017 called Where Are the Women? And this was an analysis of social studies education, specifically in the US. This report showed that the ratio of historical figures between women and men is 1 to 3. That means in our primary and secondary education, or grades K through 12, for every three historical figures that are men, you'll only actually learn about one historical figure that was a woman. And when they teach about women in history, the topic of women is often brought up as afterthoughts or they're grouped into categories of other. So in this review, there were actually over 1,300 mentions of women. And they're categorized to the topics that you see here. So 53% of women's mentions, they actually refer to them, is in domestic or family roles, making domestic roles the most frequent way of describing women's history. So when they looked at the data, they found keywords like daily life, women's roles, and domestic. And those keywords emphasize women's roles within households rather than placing them into the larger social context, even though we all know that women have impacted cultural, political, and economic life beyond household roles. This is another interesting finding that stood out to me in this analysis. Here's the racial breakdown of those named historical women and of those 178 women that are in our social studies education in the US. They actually didn't find a single Asian woman listed by name in our education. So I'm not surprised by this because for me personally, I didn't grow up learning about any Asian women who made history. And of those 178 named women, only three of them are associated with technology. So if students aren't learning about women in tech and we don't have representation, how are they supposed to know about what options are available for them? So while women make up 40% of all employed adults, again, and this is in the US as of 2022, they hold 28% of the computing and mathematical roles. Specifically in open source, we suspect that that participation ranges between 4.3% to 14.2%. And this is research actually done by Bianca Triggenreich. And I want to make a shout out to some of the women who are doing research in open source. And in her research, she shows that the lower number, 4.3%, actually represents data that was mined from software repositories on women's participation in OSS. And then the higher number, 14.2%, comes from self-reported surveys. So it's good that there's a higher number when we actually go to self-report. But still, 14.2 is a really low number given that women make up about half the employed population. There's also research out there from Vandana Singh that shows less than 5% of the OSS community have women-only spaces. They found that these spaces exist to provide a common forum for discussion, support, empowerment, and engagement. And that these spaces were not just for women to meet, but also a space for people who identified as being from underrepresented groups to also meet. And I think this goes back to what I was saying earlier, that when we learn about women in history, they're actually lumped into this other category. So what we're seeing here is that women-only spaces are actually attracting people who feel like they're in that other category too. Another thing that Dr. Singh mentions is that even though these women-only spaces have been around for more than two decades, not all of those spaces created remain active today. A lot of us know that there's challenges in maintaining active open-source communities in general. But I hope that in open-source, we're able to move to more intentional and diverse spaces for everyone. Going back to Bianca Triggan-Reich's research, she actually also dives into challenges women face in open-source. And I highly recommend looking at her paper and her presentation, which she did the same time last year. She talks about the different challenges women face. And here listed are lack of pair parity, non-inclusive communication, toxic culture, imposter syndrome, stereotyping, community reception issues, the glass ceiling, and gender bias peer review. I'm not going to go through all of these, but I would like to point out one of them, and that's gender bias peer review. In this research, it was found that code submitted by women often have lower turn per comment. Women have to wait longer to receive initial feedback for their code changes. And their review intervals can last longer than men's. And as a consequence of having such a challenging environment, women often decide to hide their gender when contributing to OSS. So in addition to those challenges, I actually want to talk to you guys about some of the myths we also hear in open-source. This is actually a definition that comes from Nifthia Ruff. And she talks about how myths are a falsehood that get passed down in time so many times that it starts to feel true. And I think this is why it's important to document history and share it, because we want to get rid of those myths. And so I want to go through a few of them that I have learned from Nifthia. So the first myth here is that you have to be a computer programmer. And for me, I didn't grow up knowing anyone in computer science, let alone any women in computer science until later in life. So I'd actually be curious to hear from this audience how many of you started off as computer programmers? Or were not computer, OK, we have one person that started off as computer programmer. Sorry, I wanted to flop the question around. How many of you did not start off as computer programmers? OK, so a good majority of the audience. And if it's OK with you, I'd love to hear from someone's story if you could briefly tell me your name, a brief history of your professional background, and if you were a computer programmer, how did you get into open source? Sorry, so is anyone in the audience willing to share? You want to? I don't know if that's on. I can talk louder. OK, beautiful. So I'm also Brittany Isennis. I am the open source strategist at Fannie Mae. And I started off my career as a teacher in Southwest Philadelphia. I taught fourth and fifth grade students. And there was such a lack of technology. And I didn't know how to leverage all of it. So I just learned it. And then I fell into ed tech. And then I fell into, I don't even know, high end IT project management for a fancy sneaker company. And then I fell into an OSPO. So yeah, that's kind of where it's at. Wow, thank you for sharing. I appreciate that. And would you like to share as well? I know you raised your hand. I'm Aisha, and I work for Bell Canada. I started off in the arts. I was a dancer. I went from a dancer to a stage manager, which is basically just a program manager or project manager, but in theater. Left that because there's no money in theater. Went to work for Bell Canada. And I actually started off in marketing communications. And she's taking over the communication website. Eventually developing it on my own. Learning code, HTML. Won't tell you the year. It was a long time ago. There is gray hair under this color. But actually went into the cybersecurity world. So I got my CEH, did all that good stuff. And then SSDLC opened up. And we realized we needed an OSPO. And so I am it. Yay. Thank you for sharing that example. I think those are two perfect examples of not being a computer programmer, but being part of open source. So you don't have to be an expert in code, or you don't have to be a programmer to get into open source. So thank you both for sharing those stories. And the truth is that you don't have to be a computer programmer because there's a need for all kinds of contributions. And contributions to open source can come in so many different ways as this audience probably already knows. It can come in the form of event planning. So that means volunteering for conferences like this one, or helping community members with their meetups. It can come in the form of design. So making visual designs or layouts for open source projects. It can come in the form of writing. So I think a few of you are part of OSPOS. So it can come in the form of newsletters, tutorials, and project documentation that we see often in our OSPOS. Organizing, so you can help organize repositories, help put labels on issues, and help open, new, or close old issues. And then finally, if you just like helping people in general, there's always space to help answer questions or help people find the solution that they need in open source. And I think all of those are considered a contribution that's not just code. Another myth that we have here is that you have to be a lifer. So that means you have to dedicate all of your spare time to just this one open source project. And even though it's true that maintainers like having long-term contributors, because there's usually a lot of volunteer time spent on onboarding people. And I think another benefit is that when you're on a project long-term, you can build up trust. And contributions usually go through smoothly. So being on a project long-term is good, but it's not always practical. Because projects and people evolve over time. And I think there's a huge challenge for us in finding free volunteer time to actually be able to contribute back to projects long-term. And I think this is especially true for women who may not have that extra time, because they may already have extra work that they have to do in overcoming the challenges that maybe men may not be facing. So the truth here is that casual contributions are still contributions. You don't have to be a part of a project for its entirety. And so I'd say my suggestion for you on this is that let maintainers know your intent and your time commitment to a project. Don't over commit or feel guilty about not contributing. I think for me personally as a woman, I always feel guilty that I'm not there. And I think that's a common reaction to not being part of a project long-term. But I would say just make sure that you're clearly communicating with the maintainer and the community to set expectations. And then our last myth is that new contributors aren't welcomed. And I put this one in purple in that red, because I don't think it's a complete myth. So even though you might be communicating clearly with the community and its maintainers, sometimes new contributors just aren't welcomed. And we see this in the communities that are closed, they're difficult to navigate, and then contributions get really stressful for new contributors. We also see some of these challenges as women, and I think they come from community reception issues, toxic culture, and stereotyping of women, which we saw earlier from Trig & Ridge's research. But I would say that there is some truth in that maintainers are becoming aware of the barriers to entry. People are realizing that documentation doesn't exist. Norms aren't set. Feedback on contributions are harsh. And the culture is just overall unwelcoming. So I do think people are realizing that, and they're making actions to change it. So I think we showed three myths and truths, and I think these are often myths that are told to all of us. But as women, I think there are also myths that we end up telling ourselves as well. So I want to emphasize that by documenting women in open source and documenting an all-women Ospo, we actually get to have our stories told, and we get to be part of the data, and we get to make it known that we're here and we're contributing. So now that we've gone through why this topic is important and some of the myths that we see, I want to talk about some approaches to building an effective open source team. So whether it's your open source project or it's your program office, I'm hoping to share some things that we learned from our Ospo. And I think that starts with defining success. So what does success mean to your team? In the tech industry, we're faced with constant change. And when there's a lot of change, you start to ask yourself, why? Why am I here? What's my purpose? And I think that's an exercise that you have to go through as an individual. But I think once you start feeling good about that as an individual, I then say, start thinking about it. Start thinking about your reasons why, sorry, start thinking about how that fits into your team's purpose. Why is your team here? What's their purpose? How does your purpose and your goals fit into the goals of your open source project or your program office? For many Ospos, that shared purpose is to help others do open source in a secure, compliant, and valuable way. And I think another goal that Ospos usually have is to create a positive culture within their organization and then hopefully within their own Ospo as well. For our own Ospo, we have created what we think is a successful team because we have defined and communicated what we want in our own work and what we want in our workplace culture. So I have the honor of introducing my wonderful team here at Comcast, a few who got to join today. So our Ospo includes Rama, Gail, Anusha, Sheila, and myself. And our team of five all identify as women. But I would say that the diversity we bring as a team isn't just restricted to our gender because in our case, it's just one gender. So I think that what our team brings in diversity comes in so many other ways. And we bring skills in program and project management, software engineering, data science, community building, developer relations, security, and compliance. And that's a lot for our team of five. But we all have really different experiences and different journeys that led us into open source. We're a geographically distributed team located across the United States and India. So we work with stakeholders all across different time zones. And we're also ethnically diverse. And we all identify as being from historically underrepresented groups. We're also a fairly new team. Most of us have been at Comcast for 18 months and under, with the exception of our lead Sheila, who's been at Comcast for 12 years and with the Ospo for six years since its formation. And I'd say in those formative years, Ospo was made up of an initial team of women. And we actually wouldn't be here today without them. So Brittany, Krista, Ananya, and Nithya, along with Sheila, I think grew an open source culture within the organization. And we see proof of that through the efforts that they have made in the company and through our current team. I also want to make a really important note that this group of women didn't hire their team or our current team because they're all women and only wanted an all women team. But what they did was they sought for qualified candidates across a broad network and who had diverse perspectives. And those individuals were qualified to be part of the team. So it just so happens that we became an all women team. I do want to say though, the Ospo wasn't initially an all women team. It included Carl Leiby, who's a principal software engineer and a supportive ally to our team. And for this talk, I actually had a chance to talk to Carl about what it was like to be the only man who's part of an all women team. And the first thing he said was that he felt like part of a team that cared about him. And he said that he knew that the people in this team knew who he was. And when you talk to them, you can actually feel like they were listening to you. And that's, he said that was really different compared to teams with all men or teams with mostly men. I think hearing that story from him really shows the power of belonging. And the sense of belonging is feeling the sense of acceptance, that there's open communication, and that there's an appreciation for your team and your team members' contributions. And I think that's what is actually the most important for me personally, because I think that as an Ospo team, it's really important that you're going through the journey together as one human being to another human being, and that you're making that journey happy, healthy, and comfortable for everyone else. So I'd say that after you've defined success and you've created a sense of belonging within your team, there's other core attributes I think that could go into making or helping your team become an effective open source team. And so I hope to go through a few of those with you. So open collaboration is one of them, and I put the definition up here, but it just describes interacting on a goal-oriented project and that the benefits of it is that people to come together for a shared purpose to build communities over a common interest. For our team, one of the benefits is that we're remote and geographically distributed, so we actually are able to be more inclusive to a wider range of people. And then the other thing I wanted to mention about this definition is that it actually says contributors and non-contributors alike, but I would actually, if this definition was open source, that actually would suggest them to take out non-contributors because as we all know, a contributor could be anyone who adds values to the project and it doesn't have to be code. Another aspect of effective open source is to have open communications. So you should have regular communications structured and unstructured, formal and informal. You should be able to share objectives and metrics and create an ongoing dialogue, so it shouldn't be one-sided and there should be continuous feedback. But I'd say in open communications, you should also expect fair. Know that people are gonna be afraid to say or do something openly and publicly and I think some of you know that putting out your first contribution can be really daunting because you're putting it out there for the world to see. But I think you can overcome that by helping to empower people. I think that by empowering people, you could also try to have one-on-ones to connect with other people and help to provide concrete and specific guidance and examples. And then lastly, I'd say don't try to force things. When you don't force things and you let them happen organically, it actually leads to a better open culture. And here are 10 aspects of what are an open culture. And I actually like the first one that it's open. But the definition that they included here for open culture is that openness leads to authenticity. And the authenticity is being honest and transparent. And I think people really do appreciate when you have consistent authenticity in your open source projects and within your culture, in your organization. I'm not gonna go through all of these, but I do wanna point out another one and that's being a role model. So we know that there aren't many women in open source. So I would ask you to consider being a role model for newcomers and a role model for the existing community as well. In our team, I see all of the individuals in our group as individual role models, but as a larger team, I see them as a role model, as a modeled team as well. We, our team actually created a safe space for other women in our organization. And I think that's because we've showed our authenticity and show that we're genuine to the open source community within our organization. And so because of that, people have come to us as a safe space to talk about some of the challenges that they face. We're also really intentional about including women in our open source programs and that's through our open source ambassador program. I think building culture is really difficult. And so as part of building culture, I think you should also celebrate some of the wins that you get. Make sure that you're saying thank you and giving compliments regularly and in public. Announce projects or new features that are becoming open source and post them up on blog posts or email newsletters. And then the other thing about celebrations that I do want to talk about is that sometimes they come in the form of parties or happy hours, but more appropriately, I think they should actually come as financial incentives or promotions. And then lastly, I want to talk about OSPOS. So open source teams are often challenged with continuity. And continuity is this idea of having consistent operations or maintenance and you can have that within, again, your project or your program. But by having an OSPOS, OSPOS actually enable continuity in executive support and funding. They help to communicate the value of open source efforts and expectations across the organization and they encourage adoption, implementation and the maintenance of open source projects. They also ensure that there's adequate and continuous resources. They also enable continuity in strategy by informing the community of all the things that are changing within the organization or within the broader open source culture. And they also help to prioritize open source projects by ensuring that there's continued involvement in those projects and that there's ongoing initiatives again, throughout your organization. So just to wrap it up, I want to say that again, even though we just so happened to be a team of all women, what makes us an effective team is that we have all of these seas. We have collaboration, communication, culture, celebrations and continuity within our OSPO. And along with these seas, open source teams, we've been able to define our success and we've created a healthy culture with a sense of belonging. And I think all of these things help to create a healthy open source environment that's more inclusive and diverse. And by being more inclusive and diverse, we can overcome some of the challenges that I mentioned earlier, debunk some of the myths we hear about in open source and spend time documenting our truths. So I want to thank you all for joining me today. I'd like to thank everyone who joined virtually and we're actually going to end the streaming now. So thank you for joining today. And I would like to actually spend the last few minutes of this talk to just have an open discussion. There's not that many of us, but I was thinking that instead of doing a Q&A, we can actually just talk with each other and get to know one another. It did sound like some of us didn't start off as computer programmers. I really enjoyed hearing the stories of how you got into open source without a computer program background. I'd love to talk about what stood out to you in this presentation and then in your opinion, what you think makes up effective open source teams and what's necessary to get there. So I don't know, we want to do two separate groups or just huddle or hang out, but I'm going to end this.