 Hi everyone, this is Peter Schumliwari. I'm a technology architect at Accenture, and I'm one of the maintainers of Hyperledric Actors, a blockchain interoperability project. Today, I'm here to talk about bootstrapping an open source project and GitHub. If you are a maintainer of an open source project, or if you're planning on being one, then here are a few basic tips and tricks for you to help get off the ground with managing that project as a maintainer. The first thing is to have a project vision, which really just means that starting an open source project is similar to adopting a path. Others will depend on you on the long run, so you kind of have to decide how much effort you will put into this and how much effort are you going to expend to support and maintain it. This is important because the vision should be outlined in the documentation and then it should be sort of a social contract between you and those who use the project. So that if you, let's say quit the project later on, no one is surprised if you did so because you did not commit to spending your life or the rest of your life maintaining the project. You also have to think about whether similar projects already exist or not. If they do, people will generally ask you every now and then what is the difference between your project and this other project that seems to exist for the same problem or solving the same problem. And obviously the answer can be pretty much anything to this as long as you know what that answer is. And then let's get started with automation. It is very important if you plan on making your project being a bigger one, which is the assumption that I will make for the rest of the talk. Because generally, maintainership slash community management tasks are difficult when you're running a bigger project, not a small one. You should always use continuous integration. That's the bad rock with automation. There's plenty of tooling for setting this up on GitHub. I highly recommend GitHub actions, which are very, very similar to most other continuous integration providers that you might have seen out there, but they also have nice integrations with the GitHub itself, of course, which is always a plus. And as of right now, they have three resources provided to open source projects, which is great. You should always have automated checks on top of the continuous integration. And these checks together with the CI passing should give you confidence that the code works at least for the simple case it meant to implement. If it's a bug fix pool request, then it should verify that the tests specific to that bug are passing, of course. And once your project gains traction, there will be more pool requests than you can leave you in detail. So this is why it's very important to have as much automation as possible, because otherwise you'll end up overworking yourself and just burning out. And that's, that's really not good for anyone. It's not good for you. And it's not good for the open source community around the project either. Try to reduce the bus sector, right as many checklists as possible, especially if you are a loan maintainer. Well, if you're a loan maintainer, you should also just be trying your best to find more maintainers. But regardless of that, the checklists are the way to go with any sort of manual task that you perform that is not yet automated. You should at least have checklists and you should dog food your own checklists, meaning you should follow the steps on the checklist. When you're doing said manual chores and then update the checklist if they become outdated or if you realize that you just missed one or two steps from something. Release management is a very important topic, although you might not need in the beginning its best to plan for it in advance. You probably want to decide on the version scheme that you're going to use, like personal recommended semantic versioning, which makes the clear distinction between breaking and non-breaking changes. Also kind of establishing a social contract between you and your users. And goes without saying that you should abide by that social contract as much as possible, meaning that you should not release minor or patch versions of your software that actually contain breaking changes. Those have to go to major changes. Release automation is also highly recommended. If you have it, it can remove human emotions, human decision making from the process almost entirely. This means that, for example, if you have a specific tag on the main branch, when the CI wants for that commit on the main branch, what you can do is detect the presence of that tag on the current revision of the code. And then automatically push a release based on that tagging release with the git tags of atomic release issuance. This is trickier to achieve depending on the technologies that you are working with. But it's definitely worth it. The bottom line is that if there's a bunch of pull requests getting merged left and right all the time on your project, you still want to make sure that when you cut a release, that release is really then not possible to be traced back later on to those artifacts that you released. And also that you have reproducible builds, which means that at any given release, users, even after the fact, can come back, check out your code, check out specific release tag, and reproduce the binaries for that release that are a byte to byte match to what you published. Version control, very important. You want to lint all the things, including commit messages with purpose made tooling. What I like to use is the conventional commits scheme, which gives you a loose but yet structured way of offering commit messages that allows other tools to generate change logs for releases automatically straight from the commit log. And this of course feeds into my earlier point about release automation being great because you want to reduce the number of manual chores you have to perform to the absolute minimum. You also want to make sure that you have a linear commit history on your main default branch, meaning that there should not be any zigzagging of merge comets on there, which would make it difficult later on to trace who did what change when and why. You can explicitly forbid the presence of merge commits on the main branch, and you should definitely enable this constraint in your GitHub settings. I highly recommend it and I'm pretty sure that you'll thank me later. You also want to ensure that build and tests have to run against the PR branch, based on to the latest target branch, the default branch prior to merging. There can be certain pull request base condition scenarios where this becomes extremely important. For example, if pull request A gets submitted and then the CI passes, and then pull request B gets submitted and the CI passes, and then pull request A gets approved and merged. But due to the change in pull request A at this point, pull request B actually no longer compiles when you rebase it onto the default branch, because maybe there was some API change introduced that the compiler is now complaining about. But if you don't have the constraint enabled that I mentioned, then at this point you will happily merge pull request B, because he saw that the CI passed earlier and that means that it should be good to go. But it actually isn't, and then step five at this point after merging pull request B, your main branch is broken. So to try to combat this type of situation from happening, you can go to the GitHub settings of your repo and search for the branch protection setting called Require branches to be up to date before merging. Onto issue management, which is very important, but often overlooked with an issue of project maintenance. You want to make sure that labels and metadata is attached to as many or best to all issues that you create on GitHub, because these can help people tremendously who don't have all the same knowledge about the project as you do, especially with trivial information that only seems trivial to you. The specific type of label is the Guest First Issue label, which I highly recommend, and I also recommend to break it down into separate expertise levels, because a good first issue can be something very different for a person who doesn't know anything about your project and they have 20 years of experience in the industry versus someone who doesn't know anything about your project, but they also just graduated University and they don't really know that much about programming in general. You want to have a product mindset when thinking about your project. Basically, if you imagine your project as a product that contributes to prospective customers, it will help you see why people do not want to spend their time, invest their time to get to know your project and to contribute. Even if you're not planning on charging your users, this is always a helpful mindset to keep. Now regarding documentation, there's a slide that I like to show, which is about how you should try to reduce the barrier to entry based on your documentation and show emotions like this picture that I've shown. It should reassure people that onboarding to your project will be straightforward and it will lead to success and joy. You don't want it to feel like this when people look at your documentation. It's simple but powerful. To optimize your quick start guide, especially the part that bootstraps people's local clones, you want to make sure that it doesn't take 15 or 20 steps and that everything is as clear-cut as possible. This goes back to my previous slides about lowering the barrier to entry. Of course, sometimes you can only converge to the above because, for example, with infrastructure projects, the basic setup can be notoriously hard. Specifically about testing your documentation should provide examples on how to test each and every endpoint if you have any kind of API BDS. Rest, pure HTTP, GRPC, your WebSocket, anything. Postman is a very, very widespread piece of software that people use for testing APIs and I can highly recommend it. Another thing that people usually forget about is that not everyone uses the same operating system as they do, so you want to make sure that your CI, your build, and the tests are running on all the supported platforms that you claim to support, even if you're not actually developing against those operating systems. The same goes for your software stack. For example, if you are a JBM project, you want to make sure that you test against multiple different versions of the JDK, just to make sure that nothing bad happens if someone happens to have a different version installed. And a small piece of practical advice, copy as many best practices shamelessly but not mindlessly from other projects as you can. And I say shamelessly because you should not be ashamed of it at all. And I also say not mindlessly because you at the end of the day have to charge on a case-by-case basis what makes sense to your project and what doesn't. And a hint, of course, I did not come up with all the ideas in this presentation just by my lonesome leader. Lastly, if you have any questions about my presentation or the project that I represent, please reach out. There's a few links here attached that you can achieve that through. Thank you.