 Welcome to the Change Wrangling training for the Fedora Program Management Team. If you haven't watched the changes process video already, I suggest you do that first, as it explains more generally how the process works from the developer view. So we'll start with looking at the pending proposals, and these are pages in the wiki that have the category Change Ready for Wrangler. So the first thing you want to do is review the proposal for completeness. And what that entails is basically just looking through the fields, making sure everything is set. You don't need to necessarily evaluate how good it is, whether or not we should implement the proposal or not, but you do need to look to make sure it's functionally complete. In particular, you want to look for the release notes issues for system-wide changes and contingency plans. If it's not complete, set it back to change page in complete, and notify the change owner of what they need to fix. If it is ready, copy the content, and it's time to send an email. So you'll paste the contents into an email, strip out any of the comments or anything if the change owner left them in, strip out unnecessary fields. Then you'll set the email subjects to be, for example, F35 change, Python 3.10, system-wide change proposal. You don't have to be exact in the subject line, but you do need to be somewhat close. We want the ideas to keep the important information towards the front of the email subject so that people can see at a glance if they care about it or not. When it's ready, you send it to the develop-announce mailing list and copy the develop mailing list. After you've sent the email, you can change the category to change-announced. After a week has passed, it's time to submit it to Fesco. So you open up a new Fesco issue, select the change proposal template dropdown, select the title in the issue title, replace the proposal summary with the summary from the wiki page, and then add the wiki page link. You also need to go to the email archives and copy the announce and develop discussion address. If you sent it the way I said with sending it to announce and see seeing develop, then the message ID will be the same so you could drop that in for both. You also need to add the change owners. If there's more than one, include all of them and then set the assignee to be the first owner, add the tag either self-contained or system-wide as appropriate, and then set the milestone to the appropriate release. At that point, you will also edit the wiki page to be the change ready for Fesco category. Fesco, when Fesco has voted on it, generally after a week, but the time period may vary based on policy, but you'll go to that issue and you'll count up the votes. So in this example, we count up five votes and so that's approved. So we'll write a comment saying that it's approved. We'll apply the pending announcement tags. Next, Fesco meeting chair knows to include it in the announcement email and then we'll go to the change proposal page. So in the change proposal page, you want to enter the current status and set the category from change ready for Fesco to be change accepted F35 or whatever release number is appropriate. So after you've done that, you'll go to a terminal and you'll go to the changes directory in the PGM scripts repo and you'll run make version equals the release version and type equals self-contained or system-wide build and this will download all of the wiki pages for that combination of categories and process them. After you do that, you'll run make bz and that will create new bugzilla trackers for each one. So we'll scroll up here and get the bug number and then go to bigzilla. So in the bug, there's a few things you need to do. You need to look at the CC list and add me and potentially yourself. Then you go to the assignee and set it to the lead change owner. Then you'll want to click on the show advanced fields and set it to block the F35 changes bug or whichever release is appropriate. Then you'll scroll down and set the status to assigned and save the changes. Next you'll go to the release notes tracker and create a new release notes issue. You'll give it an appropriate title and then select the change template and then put the wiki URL page where it says URL here and create the issue. Then you go back to the wiki page and you edit the current status and now as we go back and add the release notes tracker and the bugzilla tracker bug. Now you need to go back to the terminal and you'll run make clean to clear out the cache and then run the make build command again. So what this does is it will go through and now that there's a bugzilla, it will update the status field and the output. This is something you probably want to run on a regular basis. Even when you're not processing changes, especially as we get further along the development cycle so that the change set page has the most accurate information. So now you want to take the contents of the changes list file that the build script produces and copy that to your clipboard and then go to the releases change set page, find the right section and replace the contents with the outputs of that file. And each time you change the state of a proposal you want to make sure you update it in the Fridays fedora facts file report.md and the pgm communication repo. So let's talk about a few of the weaknesses in the process. The biggest one is that people will skip it. They either don't submit the change proposals or they basically land the work in rawhide before they submit the proposal and get it approved. There's not a whole lot we can do to stop that. So we really have to make sure what we're doing is, you know, making it valuable, showing that it has value and making so that the communication value outweighs the paperwork burden on people. As you've also may have noticed the wiki is not great for this kind of work because it's so freeform it's very difficult to parse and people can type things in a way that breaks our scripts pretty easily. We've looked at a few different ways of potentially making it a little more structured but those have fallen through for various reasons. I'd be happy to explain that to you sometime one-on-one. So that's a quick view of wrangling fedora changes.