 Hi everyone, my name is Peter Shomilwai, I work as a technology architect for Accenture and I'm one of the maintainers of Hyperledger Cactus which is a blockchain interoperability project. Today I will talk about strategies for inclusivity as an open source project maintainer. First you want to clarify to yourself why. Number one is if you were to contribute to a project you would also want to be included as much as possible. Reason number two is making your project inclusive will increase the number of contributions you receive and the number of contributors that you receive from the larger OSS community size. It's almost always correlated with higher quality and in general bigger success for your project so it's kind of an upgrade. Now let's talk about how. What you want to make sure is that you create a barrier to entry that's as it was possible. Something that evokes emotions like this picture from people when they first encounter your project's documentation. Obviously everything here seems straightforward, gentle and easy. Before you know it you're down at the beach just having fun. You want to avoid your project feeling more like this picture which goes without saying it's not a happy outlook for anyone. So the documentation should cover the whole spectrum from absolute beginners to seasoned veterans. The assumption a lot of experienced people in software development make is that everyone knows. Determinal everyone knows and is an expert in using all the version control systems, the IDEs, the operating systems to programming languages etc. With a little extra work you can update your documentation to provide tiny clues about how these things work and maybe link to additional documentation that of course you should not write yourself. We're on the topic of full requests. You want to make sure that all the requests serve as equal attention. What this comes down to is that you should prioritize the reviews based on the order of submission not some other arbitrary criteria such as how well do you know the person who submitted the full request. Also note that the order of merging does not need to match the order of views nor the order of submission. There can always be specific technical considerations why a specific purpose can or should be merged in front of another one regardless of what their order of submission was. So you just have to decide this on a case-by-case basis but all the points I make here stand in the cases when there's no special reason for deviating from the order of submission that's why full attention to full requests is so important. It is important because it will make people feel welcome at your project and it will also specifically put the burden of conflict resolution on those who submitted full requests later, not earlier. This is important because if you submit a second full request after the first one then you are already aware of the existence of the first full request and therefore you can take much easier preliminary measures to avoid a nasty conflict resolution process. To provide a specific example, this is the timeline of two full requests submitted where the first one gets merged later despite having been submitted first, causing a conflict that the submitter of the first full request needs to deal with. Despite them not being aware of the second full request at the time when they submitted their own since the second full request didn't even exist at the time. So instead of this timeline, this example, you want to shoot for something that looks more like this one. Where the first full request comes in, gets merged in the first, and then the burden of the conflict resolution is on the person who made the second full request. Of course in an ideal situation they would have completely avoided that cold conflict happening by basing their branch on the branch of the first full request. The other thing you want to make sure is to provide equal attention to communication channels, meaning that people's queries about the project should be answered in order submission in the same way full requests are reviewed. So the takeaway here is that this first and first out equal attention principle can and should be generalized to any and all human erections pertaining to the maintained project. This means that it doesn't matter if it's a chat channel, a mailing list, or GitHub issues, feature proposals, bug reports, full requests. You should always process these in order submission and make everyone feel welcome and make everyone feel like contributing to your project is worth their time. And finally, a little shameless plug, if you'd like to join a community of hopefully mostly inclusive project, please reach out to us at the Hyperlasic Practice Community. I've provided links for the chat channel, the GitHub reply story, and our weekly page. Thank you very much.