 Hello everyone and welcome to the CNCF Project Paperwork Micro Workshop. We are members of SIG Contributor Strategy of the CNCF and we are here to help you with your project paperwork requirements. My name is Josh Berkus. I work in the Red Hat open source program office. My name is Caroline Vansleik and I'm a developer at Microsoft. And I'm Don Foster. I work in VMware's open source program office. Now the format of the session is going to be a little bit different from other sessions you might have seen today. We're going to spend 5-ish minutes talking about the requirements, 5-ish minutes showing you some examples, and then 20-plus minutes on Q&A and helping you with your particular project and paperwork questions in blockers. The CNCF Contributor Strategy SIG provides a place for us to collaborate on strategies related to building, scaling, and retaining contributor communities. Our goal is really to provide resources for you that help our CNCF projects grow flourishing sustainable communities to help them on their journey throughout the CNCF project lifecycle. So for the contributor growth working group, our main focus is on making sure that we have a steady, sustainable pipeline of contributors coming into your project and ensuring that there's always people helping to work on things. So you have new contributors coming in. We want to make sure they feel welcome and we provide templates and advice for how to make sure that you have all sorts of documents that you need related to that provided for you. Then we also focus on contribution ladder activities. So for example, how do you get someone from being a contributor to a reviewer to a maintainer? And then how do we do this in such a way that's sustainable and not a burden for the maintainers themselves? So looking at this as a whole, that's what our group works on. Now one of the things that helps your project attract contributors is having demonstrable open governance. However, that's something that a lot of people running projects today don't have a lot of experience with, which is why we form the governance working group in order to help your project develop open governance and document it properly. We both create advisory documents and examples of how you would create various governance structures and meet certain requirements, and we advise the CNCF TOC on tweaking their governance requirements to make it easier for projects to meet them. Now, when you look at the requirements for the CNCF, you'll notice that there's three maturity levels starting with sandbox, then moving through incubating and moving through graduated. And this is the common path for most projects. And you'll notice that the number of requirements goes up with each level with sandbox. It's like five requirements with incubating. It's eight. We've graduated 13 or 59 if you look at all of the sub requirements. Now, not only does the number of requirements go up in every level, but the sort of depth of each requirement goes up on the different levels like for example, at the sandbox level you're not expected to have any referenceable end users because you're an experiment at that point. But at incubating level, you need to be able to name at least three referenceable end users to the TOC. And at the graduated level, you're expected to maintain an adopter's list that you keep adding to of users who have adopted your project showing its success as a piece of technology. But most projects start out in sandbox. And the sandbox process this year has been greatly simplified by the TOC. You'll submit a Google form, and it asks for pretty basic information about your project, and then you need a couple documents ready up front when you submit otherwise it will be ejected so you'll need a roadmap for your project. You'll need to have a code of conduct, a contributing guide that explains how to contribute to your project, and then explain how your project fits into the CNCF. It's tempting to write a lot here, but really it's going to fit into a single line in a Google dot like a Google spreadsheet. So keep it through just a couple sentences. The TOC will review the submissions in a closed meeting every couple months when we were two or three months. And then if you're accepted, you get to start the onboarding process, which is great and you're in the sandbox. Otherwise, you'll be able to watch that meeting, the recording of the meeting, review any written TOC feedback and then resubmit later. And once you're in sandbox, though, you're immediately can be asked to provide a whole bunch of documentation and paperwork essentially. So we have a templates project and GitHub that can help you get started. You just clone it and you'll be able to have basically an entire repo with all the various pieces of paperwork that you need for sandbox ready to go. At a high level though, you need a license and it's going to be a patchy to that's required by the CNCF. You'll need a code of conduct, even if you had an existing one, you're going to have to switch to the CNCF code of conduct. You're going to on your reading or your website, let everyone know you're in the CNCF sandbox. And then you'll also need a contributing guide and your lightweight road maps you need to keep maintaining that over time while you're in sandbox. And then the next step in the process is the incubating stage. So at this point, your project will need to have at least three independent and users which shows that there are people interested in using your project. And while it's good to have a governance file in sandbox, it is actually required in the incubating stage, but at this point it can still be fairly simple. And then you get to the graduating step where all of this comes together and you get to demonstrate to the CNCF that your project is awesome and it's mature. And the governance MD file will need to be more detailed than it was at the incubating stage and have things like a committer process which references owners MD files to show which people are responsible for which parts of the project. Again, those committers will need to be from at least two different employers. You'll also need to have a CII best practices badge and a third party security audit. So, having talked about a lot of that, let's show you a few examples. To help you meet all of these requirements and to find all of the various things that you need to do with examples of how other projects have documented them. We've assembled a checklist for project paperwork that is available on the SIG contributor strategy repository. It's more extensive than we're going to go over here, but we thought that we would give you a few examples of the things that you need at different levels in this video. If you enter sandbox, one of the first documents that you're going to need to edit, even if you had it before was the code of conduct. And this is what your new code of conduct should look like you're going to link out to the CNCF official code of conduct. And then you're going to decide who in your project is going to handle reports about your code of conduct. If you don't have anyone though who feels ready to handle something like this, you can have the Linux foundation just be your only point of conduct contact. You also have the option of being signed up for training through the CNCF and learn how to handle your code of conduct yourself. The next document that I think you're going to spend quite a bit of time on tweaking and updating while you're in sandbox is your contributing guide. Now there's a couple different things that you may already have in here. You may not, but like these are good things to look for and maybe fill in the blanks. One is caught how else you can contribute to the project besides pull requests. Usually the things that people do that aren't code is someone was time consuming things for maintainer and if other people can help with that. That would be great. Let people know how you can find issues. How do you label your issues do you use good force PR and things like that. How do you ask for help. Do you want people to hit you up on slack. Do you want them to use the mailing list. Make it explicit let them know one item that most people don't have but would be really useful and we're trying to encourage is saying what is going to happen when you submit a pull request. What do you expect. How long will it take. Do I need to interact with a bot. What are the various checks are going to be applied to my PR just so you know what to expect and it feels a little less intimidating. Also when you join the sandbox you're going to have to adopt either a CLA or a DCO contributors license agreement or the developer certificate of origin. And most people don't quite know how to work with those especially for our first PR so put in your contributing. How do I sign things make it a little easier for them. Now Harper has a great example of how to ask for help. In their contributing guide where they call out how you can join meetings. How can you get involved with community and then directing people appropriately to the dev mailing lists they're not asking for help on the general end user mailing lists. And then at incubation. As I mentioned earlier the governance and defile you need to have that and one of the things that needs to include is how leaders are selected. So we've written a handy guide for you which is in the governance working group documentation section. And it has a bunch of different ways that leaders can possibly be selected so you can have a look at these see what's appropriate for your project and use one of them if it makes sense. The other thing you'll need is a clear versioning scheme so again from Harbor we have a good example here of how they use semantic versioning major minor patches for their their numbering scheme and how they do that for both major and minor releases. Now one of the other things that you then need to add if you're applying for the graduate level is this adopters md file which is going to be a list of publicly referenceable users who have adopted your technology. This is to demonstrate that your technology is useful and is broadly interesting to a large group of people. If you can get access to case studies or articles about some of these companies, then that is also great. But really it just needs to be this list of users and they need to be willing to be referenced and to say that they use your project. If they're willing to join the CNCF end user council as well that is also great. The much bigger requirement though is the CNC the CII best practices badge. Now the CII best practices designed to demonstrate that your project follows secure and repeatable processes for releasing software so that users can be assured that they are getting the most secure and the most secure version of the software as they upgrade it and this contains a whole bunch of different requirements about how you run your repository and how you do releases and how you respond to security issues and handle that as does the security audit. So if you are looking at moving to the graduating level don't hesitate to start looking at this list of requirements and start implementing them because it is long and it will take you a while to do it. Now, having gone over some of the specific requirements and examples, we are here for you. What do you need to know more about which paperwork which processes do you need more information about which things are you stuck on to get to the next level of project maturity or to get into the CNCF. You can ask here through the CQ&A thing on Intrado, which is one way to ask if you need to share documents or additional information with us. You should already be in the CNCF Slack for the conference. Join the SIG Contributor Strategy Channel and go ahead and ask your questions and share files here and we will answer them on screen. With that, let's move into the Q&A.