 All right. So welcome, everybody. Thank you so much for showing up for the six o'clock late night presentation. I'd like to welcome you to my talk on creating an inclusive community. So I previously gave this talk at the hyperledger global forum in 2020 right before we went into the pandemic with Swetha Rippa Kula. And so I wanted to give this talk again and see if we could get some more conversation happening about how we create an inclusive community. In the spirit of being inclusive, because I knew this room was so big, I wanted to make sure that if anybody needed to be able to see the slides, they could download the slides and be able to download those locally and be able to view those. So if you do need to do that, please do go ahead and do that. But my name is Tracy Kurt and I work for Accenture. I've been in the software engineering and architecture space for about 25 years. I currently work on blockchain metaverse open source at Accenture and I'm a technology architect. But at the same time, I think it's really important that we create inclusive communities in what we're doing and how we interact with people. So prior to Accenture, I actually worked for the Linux Foundation. I was a community architect at Hyperledger. And before that, I spent 10 years at PayPal where I worked my way up from a software engineer to a strategic architect. And prior to that, I spent seven years writing compilers, assemblers and linkers for 8-bit and 16-bit microcontrollers. So I have very much the geek inside of me. But in the space of open source, I am currently a steward for Hyperledger Labs. I'm the chair of both the Hyperledger Technical Oversight Committee and the Open Wallet Foundation Technical Advisory Council. So I've been doing open source since probably 97 where I did my first contribution in the assembler space, so GNU Binary Utilities. And that's where I really got involved in open source and have had the great, fortunate experience of getting back into that space. So when I initially put together this talk, I thought it would be good to level set on what does inclusive mean. So I went to the dictionary. And lo and behold, what it told me is that inclusive means to include everyone. Well, that didn't really help me, right? Include, inclusive, kind of one of the same thing in my mind. So I said, well, what does it mean to include? Well, to include is to take in or comprise as part of a whole or group. So if we bring these two definitions together, what inclusive means is that we are taking in or comprising everyone as part of a whole or a group. So why is this important? It's important because people do not stay in a community unless they feel empowered, engaged and included. So if any of these three are missing, then people will look to another community where they do feel like they are empowered to contribute and make decisions, where they are engaged in the outcomes of the work that they're doing and where they feel included in the work that is being done. So it's very important that we make sure that people stay in the community and that's what we're trying to get to. And so what we're going to go through are kind of two sections in this talk. And this talk is really intended to be open-ended. So at the end I'm going to ask you for your ideas and your tips about what it is that you think makes an inclusive community. But don't worry, I am going to give you some ideas and I want you to build on that and really think about the sorts of things that make people feel welcome and make people feel empowered, engaged and included. So the first thing that I have is documentation. So documentation is normally the last thing that developers focus on. However, documentation is usually the first place that people come when they're looking at a project and trying to understand that project. So the more questions that you can answer in your documentation, the less questions will distract you from the part of contributing that you think is fun, right? Writing the code and getting involved in that way. So the tips here are really to keep your documentation up to date. There's nothing worse than following the documentation, running into a problem, and finding out that the documentation is not up to date. How many times have you done that and how frustrated have you been in experiencing that? So making sure that your documentation is up to date with the need to sort of changes and features that you added is really, really important. Also prioritize updating your documentation based on the sorts of questions that you're receiving. So obviously you have your FAQs. But if you think your documentation already answers a question and you keep getting that question over and over and over again, make sure that you take the time to figure out why people are not finding that in your documentation. So take that opportunity to really correct any sort of issues that don't lead people to find the answers that they're looking for. Provide introductory sorts of tutorials. So the first thing that you want to do is introduce your project. What is this project? When would I even use this project? Those are things that people are going to be looking for as they look at these open source projects. Then make sure that you're providing step-by-step documentation on how to install your software, how to configure the software, how to run the software, and ensure that any of the links that you have work. Again, nothing worse than going to dig deeper into a particular topic, clicking on that link, and it takes you nowhere. You get a 404. That is the worst sort of experience. And it is potentially an experience where you have people leave the community. They say, if this is my first experience and I click on a link and it doesn't go anywhere, why should I stay with this particular project? And why should I work on trying to figure this out? Documentation, the most hated things that we don't want to do, but probably the most important thing when it comes to our projects. The second thing is reduce the time that a question goes unanswered. How many times have you asked a question and not got an answer? What does that feel like? Well, as people who normally participate in these different communities, it's probably tough for us to remember how difficult it is for us to put ourselves out there, to ask that question. And what happens when you finally get up the courage to ask that question and you don't get a response back? That's the worst sort of feeling that you have. But I would recommend for those of you who are asking questions, write on your chats or mailing list, do yourself a favor and make sure that you're doing as much as you can to get that question answered. Make sure you're including all the relevant details. Make sure that you're including information about what you've already tried. It's important that if you've tried something and it doesn't work, that people understand so they don't recommend that you try something, that you've already done. So there's nothing worse than seeing a question of, this doesn't work. What do I do? Well, what exactly doesn't work? And what were you trying to do? And how did you accomplish this? There's actually some really great documentation out there on how to ask technical questions to get quality answers. And I have a link at the end of the presentation. It's in the deck that I shared. So feel free to take a look at that. Maybe even include a link in that if you're a maintainer inside of your documentation about how you can ask those sorts of questions. So providing the guidelines for how to ask questions is just as important to include. Also designate people or maintainers to monitor chats, mailing lists, maybe have that a weekly rotation where people are specifically tasked with ensuring that these questions are getting answered. And if you're the person who's assigned that task and you don't know the answer, make sure that you acknowledge the fact that you saw it, right? Or if you've seen the question, but maybe you can't immediately answer it because you're working on something else, also let them know, I've seen this. I'm going to get back to you on this, right? So people aren't wondering, did anybody see my question? Was this, you know, did it go off into Never Neverland and nobody's even looking at it? Make sure that there's some sort of response coming back. You can also reduce the overhead of answering these questions that come in on a constant basis, the same question over and over and over again by developing a chatbot. Make sure that that chatbot will point them directly where they need to go in the documentation in order to find that answer for themselves. The next thing that we have is different sorts of users that will come in and use our project. We have people who want to understand what the project is and does. We have people who want to use the project. We have people who want to fix bugs, as well as people who want to contribute to the project. Develop a separate user journey for each of these different audiences in your documentation or on your website. Make sure that regardless of where a person enters, they can find the right path and the right journey for them. So the next thing that we have is participation in community meetings. We need to make sure that we're encouraging people to talk in these meetings, to participate in these meetings. The best thing that you can do is make your agendas open and public. Make sure that you're putting those agendas out there prior to the meeting so that people know what's going to be discussed. Allow people to add things to that agenda. So it shouldn't be a set agenda. If people have topics they want to discuss, make sure that they have the time to add those topics to the agenda. And make sure that you're reserving time during your meeting to allow for additional discussion topics that may not have been on the agenda. You can also provide opportunities for new members to talk. One good way of doing this is at the beginning of the meeting, welcoming those new people who have joined the meeting. Giving them the opportunity to say hi, talk about why they're there, and what it is that they're looking to accomplish by attending. By having somebody speak up as soon as they join the meeting, it ensures that they're probably going to talk more throughout that meeting. Versus never recognizing the fact that they joined that meeting, never saying hello to that person. I've been in both of the sorts of meetings, and you can tell the difference between somebody who, the very first thing that happens is they get welcomed to the meeting. Oh, I feel like I'm now part of something. Even though it's the first time I've joined this meeting, I now feel like I'm part of this meeting and I can really participate. Also provide context on the items that you're discussing. So don't assume that everybody's been on every call before, right? It's very possible that this is the first time somebody's joined, and if you don't provide the background context of why this discussion is happening, they may not be able to keep up. It may not be able to participate fully. Versus if you provide them that context, it's more likely that they will understand what's been happening before and be able to participate in the conversation that's happening today. Most chat systems actually give you the ability to describe how a channel is supposed to be used. This is a great place to add useful links or FAQs. It could be a way that you point to maybe the pinned messages that are in the chat, right? So all chat systems usually have pinned this message. That pinned message might have all of the resources that you need to get started. Make sure that there's a link to that so that people recognize that they should look there first before asking questions that might already be answered in the FAQ or might be answered somewhere else. And that really allows for people to take a look at that resource before they ask the question. So the second part of these tips is how to be open to contributions. So as organizations, as we participate, it's sometimes the case that we do things inside our existing teams. And sometimes this team is co-located, which means that your conversations can be very insulated and not open to the public. And what we need to do is make sure that we're including others in the conversations so that ideas that are generated can be more than just the small group of people that are focused on it. And there's multiple lines of systems that we can use for this sort of communication. Obviously chat and mailing lists are wikis. Any place that you can make sure that you're putting information that other people can find and use. So the process for contributions, right, if we're doing a new feature versus fixing a typo in a document, that's probably going to be different. And we should make sure that we're documenting how to do those different sorts of things. So ensure that your contributing guide is clear. Talk to people about what it is that you're expecting from them. What are the requirements that you want when you see a pull request? There's even ways that you can do pull request templates to make sure that certain information is done. And provide for each of the different ways of contribution. So besides your bug fixes and features, you might have people who want to do testing. You might have people who are creating issues against your projects. You might have people who want to do documentation updates. Each of these ways of contributing is slightly different. And you'll want to document that and make sure that it's very clear in your contributing guide so that they know the exact process that they're going to follow. And also I think it's really important to document the process for moving from a contributor to a maintainer. So how do I go from making that first code contribution to actually be a maintainer of this project? What are the steps that are going to be take that I need to take in order to reach that state of maintenance ship? Is there a certain number of pull requests that I have to do? Is there a certain number of code reviews that I have to make? Make sure that whatever is the process that is going to take is documented. Make it easy for your developers to get started. So be clear about what the development requirements are. What sort of machine do I need? What sort of hardware is required? What sort of memory is required? What sort of disk space is required? All of these things are important when you're coming in and trying to contribute as a developer to the project. You can also provide development scripts that will download any sort of necessary dependencies that are required to the machine that they're using. You might even provide a Docker image, or as we maybe heard this morning, maybe Finch is the new direction. So maybe that's what we need to do is provide images that can be easily used for the development. Create documentation specifically focused on these developer workflows. So what does it take to actually do development? What can I expect to find in this GitHub repo? What are each of these directories? What should I look if I'm looking to fix a particular bug? What sort of place would I go look for first? These are all very important sorts of things. Also, create make files with targets to build, test, and run your basic checks. If you can have that developer do those basic checks before they even submit a PR, you're much better off. Architect design and develop transparently. I talked about this a little bit upfront where I said, you know, it's very easy to be working with your team, do your development just in that team. So the recommendations here are really to hold your discussions online. Make sure that you're using the chat system of the project and not the chat system of your work. Whenever you're having these discussions, make sure they're open and people are able to respond to those that are not part of your direct day to day team. Use your wikis. Use your mailing list. Document anything about the design that you're putting together so that if people want to contribute code to make that design a reality, they have the possibility to do that because they can see the design. They can ask questions about that design. They can look at the architecture and really understand the direction that you're looking to take the project. Make any sort of decisions publicly. Never make a decision and don't announce it publicly. It's obviously better if that decision is made in the public. But if you have to make that decision privately, make sure that it is documented publicly so that other people know that there was a decision made. This is the reason the decision was made. These are the thinking behind why we went with option one instead of option two. As a maintainer, you need to be inclusive. There are certain etiquette that we have as maintainers. When new contributors come in, even veteran contributors, they're putting themselves out there. So whenever they submit a PR, they're putting themselves out there and they're asking for you to be gentle with them. In the keynote this morning, I thought it was funny because I was listening to the conversation about the first PR and the fact that he was a veteran, but yet it was the first time he'd done open source and he was putting a PR out there and he was very nervous about doing that. And it's very true. It doesn't matter how much experience you have, whether it's your fresh out of college or you've been 25 years in the industry, putting yourself out there in the public is tough. So be gentle with people. Be cognizant of the fact that people are putting themselves out there. Be clear, but polite when you're giving that feedback. And try to point out any sort of resources or examples that you might have about coding style or what is expected of any sort of contribution. And remember, a simple thanks goes a long way. Thank you for your contribution. We appreciate the time that you've taken, right? Just something to let them know that you recognize that there was effort put into the work that they're doing. Also take the time to invest in your contributors, whether that's helping them learn the end to end process, whether it's helping them file an issue, submitting a proposal, any sort of work that you can do to help people through that process is going to benefit you when they start to contribute. So I remember the first time I contributed to Hyperledger back in 2017. I found a documentation bug, something very simple. I thought, this is going to be easy. I'll put this out there. I'll get it in. It'll take no time whatsoever. No, right? Took a lot longer than I thought. This is me, you know, 20 years of experience in the industry. Okay, why did this just take so long? But the thing that I had was somebody who helped me through that process step by step. Here's the things that are wrong. Here's what needs to be fixed. Here's what needs to change. And it was, you know, I still remember Nick Gasky, right? He's the person who helped me. He helped mentor me through that. And I think that experience was so valuable. And I recommend anything that you can do to help people through that process is going to be remembered by that person. How do you deal with ideas that conflict with your roadmap? Be honest about it. If it doesn't match your roadmap, don't beat around the bush. Don't waste their time. Tell them we're not going to accept this PR because it doesn't match the roadmap. This is where we're going. And we would love to have your help on this particular direction, but we're not going to accept this PR. And I think that is much appreciated, more appreciated than having that PR sit out there and get any sort of response. Nobody ever comes and looks at it. And so really, I think it's important to recognize that, but also at the same time, appreciate any sort of time that they've put into the work that they've done. Also use the systems that are out there to help you. So CI CD will obviously give quick feedback about whether or not a PR actually meets all the test requirements. Use labels to help you organize the different PRs that are put out there, maybe the different issues that are put out there. Don't take too long to recognize any sort of PR that's come in. Also, as I mentioned, you could add templates for your PRs, templates for your issues, any sort of thing that you can do to reduce the time for contributors is also going to reduce the time as a maintainer that you have to spend on reviewing those PRs. Speaking of timely reviews emerges. This particular example shows both good and bad examples of responding to a PR. First we had really quick responses. Right. We had two approvals in less than two days coming in into this submission. But the PR did not get merged. And so what ended up happening is it needed to be rebased. And so you need to call the contributor back. Please rebase this. Maybe they've gone their own way because that PR never got merged. Right. And they're not going to come back. But yet this was a valuable fix that needed to go in. So by being slow to merge or not explaining exactly what needs to be done, we discourage those new contributors from becoming those long term contributors that we're looking for. Creating and maintaining good first issues lists. So most issue tracking systems that I know allow you to label your issues. A good rule of thumb is to create and maintain a list of issues that's really good for newcomers into the project. And we typically label these as good first issues. We also have within hyper ledger a project that actually splits the good first issues into 100 200 300 and 400. So the 100 levels are introductory sorts of good first issues where they don't need to know anything about the actual project. But they're good enough if you know something like, you know, JavaScript, you're an expert in that is going to be a really good first issue for you to come in and contribute. Versus the 400 one, you now need to know something about the project and the way it works before you can actually do this, but it's still fairly small enough that it makes a good first issue. And so they separate those as kind of those introductory versus expert sorts of good first issues. You know, you don't have to do that, but it is something that I think is really interesting. In addition, you can also label your issues for help wanted. If you're looking for the community to actually help you with a particular issue, label those as help wanted. I don't know how many people I've talked to who said I really want to contribute to hyper ledger or I want to contribute to the open wallet foundation. How do I go about doing that? Well, I tell them look for the good first issues, look for the help wanted. Those are the places where people actually are looking for you to come in and provide your input in your insight. So with that, this is where I hand it off to you. What are your tips? What are things that you've seen to help create an inclusive community document governance? That's a very good one, right? And for those of you who might be listening, it was make sure that you basically have governance processes where you can turn the crank. If you weren't initially involved in creating those governance processes, make sure that it's easy for those people who are coming later in the project to be able to follow the same sort of governance and to be able to work through that without having that person who's wrote the original governance document still on the project. I think that's really important because I think one of the things that happens with communities is obviously people move on, right? They move on to their next job, they move on to their next open source project, whatever the case may be, and you're not always going to have that wealth of information in that person. I don't know how many times I said the word document today, right? But unfortunately, it is one of the ways in which we can communicate information that's come before. I think it's a really good one. Thank you for that. Other tips on how you've seen inclusive communities work? Yeah. So for those of you who are, again, on the virtual recording, it is about the open recognition of people who are using the project and being able to bring that back to the maintainer so that they still feel like they're doing something valuable for the community and that people are seeing the value. It's so important to realize that there's a set of people that are out there who are working very hard to make these projects a reality. And just as you need to thank those people who are doing contributions of the bug fixes and adding new things, it's very important to recognize your maintainers and all of the hard work that they're doing. Yeah, I like that. I like that. So designer, right? I think it's so important to recognize that contributions aren't just code, right? There's a ton of different sorts of contributions that we can have in our open source projects. And if I narrowed it down too much, I wasn't being very inclusive in my conversation, but I do think that it's so important to recognize designers, documentors, testers, coders, the people who are marketing our projects, right? All of these sorts of people. But I think what you said was really important, which is that anonymous aspect of being able to design on a board without people knowing that you're the one putting this comment or you're the one putting this thing out there so that you can really just get all the ideas regardless of whether they seem positive or negative, right? It's very important to have those open conversations. And sometimes the way to be open is by being anonymous in what you're adding. Yeah, so important not to take offense. So important just to hear the ideas, listen to them. Dave and I were talking earlier about somebody on the team who always provides his input regardless of time, place, or how bad it is, how good it is, right? He's very open and honest and just wants to get to the truth. And I think, you know, the thing that Dave and I were saying was like, yes, please provide that. I need to hear the other side. I need to hear where I'm wrong. I need to hear the truth, right? So that we can get to a better spot. This is about collaborating and making sure that we're, you know, thinking through our blind spots, right? And by bringing in all of these different aspects into the conversation, all of these different ideas and people, right? I believe that you end up with a better system, a better output. And by being open to those sorts of conversations. Very, very good. Very true. Anything else that anybody has as far as tips? Yeah. Yeah, challenge swings, any sort of recognition, the t-shirts that are given out, right? Any little thing that basically brings you into that community and makes you feel like you're part of that community and that you will recognize for any sort of work that you put into that community. I think it is very much, like you said, it doesn't cost a lot, but it takes time to do. But I think that people really enjoy that and they really appreciate, you know, having that. I picked up my Hyperledger coin for 2023 yesterday, right? Like, now I got that. And I, like, I just feel like, hey, I got all of these. This one's a brand new one. It's a different shape and it looks different. And, you know, it's exciting, right? I don't know why, but it makes you feel good. It makes you feel like you're part of something. Going back to that empowered, engaged, included. Any other thoughts? Any other tips? I'll contribute. I think, you know, a lot of what you shared is focused on, like, the online space. And one of the things that's really supported the digital identity community that I lead being open is having events that are open and inclusive. So we use open space technology as our organizing format where people, it sounds so hokey, but we literally have 350 people sit in a circle at the beginning of each day and a blank wall and we facilitate them through a process that means the agenda is co-created each day of the event. I think this conference could use some of that, but anyways. And I have a scheme of how to incorporate many on conferences into an event of this size and scale. I just need someone to trust me and experiment trying to do it because I'm pretty sure it'll work. Anyways, but back to inclusive community events. So open space technology really, and another thing we do that people don't, the first hour of the first day of the event, we have everybody sit at tables and we make up something they're supposed to do at the tables. But the whole point is that the oldies and the newbies talk and everybody has a chance to talk to other people at the conference. So right back to the opening of the meeting, everybody's talking and then anyone can put anything they want on the agenda. There's no central organizing force deciding who's speaking and that's very inclusive and it has meant that our conference is still around after 18 years and still innovating because it is open and inclusive and innovative and those things, I think, go together. Yeah, Kalia, I couldn't agree more, right? When you were talking I was thinking about when I first joined the Linux Foundation and the first meeting I had was in Washington DC. It was like April of 2017. We had these meetings that were called Hackfest, Hyperledger Hackfest and they were done in the open space sort of manner where whoever attended got to decide what sort of topics we were going to be talking about and I still remember meeting some of the people in the Hyperledger community back in April of 2017 at that meeting and I can still remember them and being able to put their faces to their names and their voices and being able to have those conversations where you just talk about what it is that you're interested in, you talk about why you're there, you're focusing in on solving a problem together. I think those are really great spaces to really become a very tight community and to be able to create those bonds so that when you do go back to being online, you have those relationships that you formed, you know when you're talking to somebody maybe not to get upset because this is just the way they are or that you want to hear their opinions because you've formed that sort of tight bond with them. So, Kalia, I think you're exactly right in that these are good ways for us to come together as a community. Anything else that anybody would like to add? No? Okay. Well, I will leave you with a couple of slides. So, this one is a slide that we always show at our Hyperledger meetings. We make sure that people recognize that they are welcome in the community and that they are welcome to participate and have conversations at the calls. Just yesterday I was, yesterday, no, this morning, it's been a long day. This morning I was having a TOC call with the Hyperledger community and we had some new people on the call and I wanted to make sure that they recognized that they were welcome on that call and that they could have a conversation and communicate on that call. So, this slide is really important. It's something that we actually show at our events as well that people are welcome in the Hyperledger community. At the end of this slide deck, I do have those additional resources that we talked about including the how to ask technical questions to get quality answers. There is obviously some other documentation about being a maintainer in this as well. So, feel free to take a look at those links and thank you so much for joining me at this late, late talk. So, I appreciate you guys being here.