 Fedora program manager Ben Cotton here to walk you through the Fedora changes process. So the first question you may ask is what is the changes process? It covers what we build and how we build it. So what we build includes technical changes to packages and configuration but doesn't include simply adding packages to the repositories unless that package edition changes defaults on deliverables. But it also includes how we build it. So this is technical or policy changes to how Fedora Linux is built. So why do we have a changes process? It's about communication not gatekeeping. We're communicating with each other by providing feedback and improvement to proposals and we're coordinating work. So for example the QA team knows what they need to test and the documentation team knows what to write in the release notes. We're also communicating with users. This is via the release notes and the release announcement and things like that. And with the press and in particular the Linux enthusiast press often covers our change proposals as they're submitted and helps generate some pre-release buzz for the next version of Fedora Linux. So how does the Fedora changes process work? Well there are two types of changes. There are system-wide changes which have changes to the defaults or to critical path components. They may have broad impact across many maintainers and so as a result we give them stricter policy requirements. On the other hand self contained changes have a smaller scope and impact and we give them fewer policy requirements. The process has a few stages. Preparing the proposal, submitting, the community comment period, the fest go vote, and then doing the work. In doing the work there are several milestones that start from the beta freeze and work backwards. So starting from the bottom there are the change proposal deadlines which vary based on the type of change that's being proposed. The mass rebuild is a common checkpoint for system-wide changes for packages that need the mass rebuild. If the change isn't done by then it may be deferred to the next release. There's a deadline for code completion where it should be in a testable state and that is three weeks before the beta freeze and then changes should be 100% code complete by the beta freeze. So let's look at the anatomy of a change proposal. So this is the wiki page for the Python 310 change proposal. You start with the title and you have a summary which is a one or two sentence explanation of what you'll do. The owner lists all the people who will be working on it or at least the people who will be coordinating the work and if you really love your program manager you'll use your bugzilla email address as the email. For a current status you just have to worry about the targeted release. The rest happens on the backend. The detailed description gives you more depth on what you're doing. So if you have a schedule, this is where it goes. If you have some more technical detail about what is being done that's this section. Now the next section is benefit to Fedora and that explains why is this change important to the project. The next section is the scope where we talk about what you will do as the proposal owners, what other developers may need to do, what release engineering will need to do, and for system-wide changes you are required by policy to file an issue with release engineering to get them to sign off on it. If there are policies and guidelines that need to be changed or if the trademark approval is needed from the Fedora Council, for example, if you're creating a new spin. Next you need to describe what happens on upgrade on backwards compatibility. You need to give a plan on how to test this and that includes both making sure it works as expected but also just making sure it actually landed. Describe the user experience. Describe the dependencies of the change. So for example 4,000 plus packages that depend on Python 3. In the contingency plan you describe the contingency mechanism. So what do we do when the change is incomplete? Does it get deferred to the next one? Do you need to do something special to back it out? Does it require another mass rebuild? You provide the deadline and that's typically going to be the beta freeze or the start of the mass rebuild or maybe the branch day and you can have other contingency deadlines but you should really have good justification as to why it's not one of those three. The documentation section is for upstream documentation links or first-party things that you're writing. Just a little more explanation than would be appropriate to put on a page. And finally the release notes section is guidance for the documentation team on what to include in the release notes. You don't have to have it fully fleshed out. It's really just there to give the documentation team an idea of what they should be focusing on. Well how do you submit a change proposal? There's an empty change proposal form in the wiki so you'll save that as a new page. But basically what you do is you go through and add all the fields that we just talked about and there's a lot of helpful comments along the way. When it's ready to be submitted you look for the category change page incomplete and set that to change ready for wrangler. Make sure that you get the capitalization right because the wiki is very finicky about that. But once you save it that way then it will show up in my queue and I will start processing it. Once Vesco approves the change proposal the program manager creates a bug in the changes tracking bugzilla component. So you can use that to track the other bugs that go into doing the work. You should also set the state based on the current status. So when it's assigned that means the change has been approved so that's you know when it gets created it'll be set to that. Modified means it's testable on QA means it's 100% code complete. Please do not close change the tracking bugs the program manager will take care of that on release day. So there are two key deadlines in the changes process. There's the code complete testable deadline and the code complete 100% complete deadline and those are basically as they're described. For the testable deadline you don't have to be done with the code but it should be in enough state that we can test the basic functionality and make sure it works. By the 100% complete that's the start of the beta freeze and really all of the code should be done by that point. At each of those deadlines changes that aren't in the appropriate bugzilla status will be sent to FESCO for FESCO to evaluate and what FESCO may do is they may decide to defer that change to the next release or they may grant an exception to allow it to be continued or they may ask the change owner to withdraw it or modify the scope in order to make the release. And that's the basics of the Fedora changes process. The QR code on the screen has links to the documentation in the program management docs and as always you can come to me with questions via email or chat. I hold weekly office hours so you can join that see the Friday's Fedora Facts posts on the community blog for more information.