 So, this is going to be a quick introduction to the Fedora Badges sysadmin point of view. So, there's been the design workshops for the last several years, but this is the first time we've done a sysadmin overview for the Fedora Badges side. So, we're going to try to do a quick overview of what that, the technology behind the Fedora Badges infrastructure is, give an overview about some of the automatic badges and then explain the workflow. And then our goal is to try, at the end of this is to try to actually try to have everyone push badges based off of the tickets that we have in the Peugeot preferences that are ready to push status. So, this is the quick agenda, basically what I just explained. And Cyan was going to, oh, and this is an anti-agenda, but since I guess you're in the room, anyone that wants to design the badges, there is the Fedora Badges design workshop tomorrow, 9 a.m. to 10.50. So, I will hand it over to Cyan for the technical overview. Do the wiggle. Hi, I'm Cyan, and I'll go through the technical overview of it. So, before starting off with creating the badges, it's better to know, like, which projects make up the Fedora Badges project in whole. So, we have a Fed message, we have data normal, we have Fed badges, Thahiri and Thahiri API, and sometimes for debugging, we use data gripper. So, that's the last point as a maybe data gripper. And so, let's go quickly through Fed message and data normal. So, this is a simple diagram. So, within the Fedora infrastructure, we have a virtual bus, which we call as Fedora Fed message, which is the Fedora Fed message bus. If you can see, this is like a virtual message bus that we have, and then various applications push messages to the Fed message bus, be it like Koji or both the Pegi or Cameras, both the all push messages to this particular message bus. And this works on a public subscribe model, so different application again can connect to either subscribe model to this bus and can start receiving those messages. And each message has a particular topic to it. So, using the topic as a filter, they can start using or subscribe to a particular topic and start receiving those messages. So, badges also lies on this front. So, we have badges rules which listen to a particular topic. And based on that, they filter out which person should get which badge. And we have different rules set up which Miro would be explaining ahead. Anyway, so we have, so here you can see like Fed badges is one of the component as a subscribers which posts the data into the process. So, now moving ahead, we have a data normal. So, what's data normal? Data normal is a database where Fed messages stores all its messages. So, data normal is also a Fed message hub which listens to a particular message. So, it actually listens to all the messages and stores it into a database. Next, and yeah, so next part is the major part is the Fed badges. So, Fed badges is a project which is like the rule generator. So, it converts the rules file, the rules CML file that we create into proper SQL query and then awards the badges as it goes forward. So, this is a simple sample rules file that we have. I picked up from the documentation. So, you have the topic. So, for any Fed message which has this particular topic. So, this rule file will pick up that particular message and then you have the criteria on how to filter those messages from the data normal. So, you have like filter the topic and then from the message, it tries to pull the message.commit.username, which is a person who actually gets that particular batch. And then you can do various operations based on that. Like suppose you need a batch like where the comments are greater than 50. Sorry, greater than 90. So, you can put all those conditions in the YAML file. Okay, do you want to show this particular? Right. So, this is a data grape, data grape UI. So, data grape is primarily API, rest API kind of a layer on top of a data normal. So, if you need to pull data from the data normal database, you have to query them via the data grape. So, Justin, can you click one of the JSON messages? So, right now we are filtering based on the get receive messages. So, you can see this is the message structure to that particular message. And if you can see there is a message, comment and username like a dictionary. So, we try to filter out that particular username. So, here we, from data, so when fed batches does the ruling part, so it would filter out the username and I want the batch to this particular user if all the conditions are met. Yes, that, message.commit.username, okay, go on to the slides. The next that thing comes in place is the Tahrir API. So, Tahrir API is primarily the, so the batches front end that you see is primarily divided into two parts, which is the Tahrir project, which is the front end to it and the Tahrir API. So, Tahrir API have all the models in place, which defines the database structure. So, it also provides with the API layer over the database. So, if you need to create user or award a badge or create a series in the badges. So, you can actually use that particular API from Tahrir API to do all the operations. So, primarily the Tahrir project actually uses that API to create all the operations on the database, Tahrir database. So, primarily it's a database. It uses SQL Alchemy and it's written in Python. And as I told, it provides the API over the Tahrir API database. Next, and finally we have the project Tahrir is a pyramid, pyramid based project, which is a Python web framework. And it's basically the front end to badges.fridderproject.org. So, whatever you see, the admin page or the explore page or any other page that you see. So, it's basically all the codes lies in the Tahrir repository. And if you want to like contribute or add new features or probably update the templates in the badges project. So, Tahrir is the place where the code would be. Sure. Sure, so probably we can show a code if we can. So, just to ask the question like if I can give an example for Tahrir API. So, Tahrir API like as in like you, if you open the, go to GitHub, Tahrir API, yeah. So, anyway, so you have a file called the DB API within Tahrir API. So, which contains the extraction of like all the database operations that we need to expose out. So, like as I told, it can create a simple user or create, award someone a badge. So, all is done via this particular API. Go to Tahrir API, yes, and DB API. Yes, just increase the font, yeah, just scroll down, scroll down. Yeah, so if you see that there are various methods, utility methods like team access, get team, scroll down, like create team. So, all these are like the API endpoints or the methods that can you use. So, basically the Tahrir actually uses these methods to interact with the database. It does not do it directly via the SQL Alchemy. And even the, I guess, the edit badge or all the badges, scripts that we have, those also uses this all API methods because this is like you need to create a DB session and then start accessing using these methods. So, next, Mido would be taking over to explain the automatic badges. Hello. So, we already seen an example before. So, just a little repetition, we have some trigger, which is something that will basically, it's cheap, it doesn't take much time. And every time there is a fed message, the rest of the file will only be applied if the trigger matches. But it's not very powerful. You can basically filter by topics, maybe some lump does, like here, but you can't see history. In the trigger, you can only filter the particle or the fed message they, sorry, I don't know how real time or not this works. But so, basically, the fed badges thing is hooked up on the message bus. And every time it receives a message, it goes through all the rules and applies all the triggers. So, it's almost real time. It might take some time because we have a lot of rules and a lot of messages and I don't know how fast is the machine. So, sometimes you do an action and it takes a couple of minutes before you receive the badge. Yes, you're right. So, but we need, we have badges that say something like, you did something five times already or something else. So, we first do the trigger part and then the criteria can look to the data number, which is basically like a recorded history of all our things that happen in the fed message bus, including a short period before message bus was actually created. So, when this started in 2013, I guess, they kind of looked at the database and they reconstructed partial history for data numbers. So, there are even more historical data, but not all of them. And then you can look to data number and find another messages with the same topic and with the same user. And then you can do some operations like count or there are more, I don't remember them all. There is no real documentation for this as long as I know. Bit of it, yeah. So, the workflow usually is you find the badges which is similar to this one. You copy paste the rule file and you try to make it work, which sometimes is possible and sometimes it is not. But that's a little problematic thing. So, what you could do is search the topics on the data number, try to find something which is related to the stuff you try to create and then see the JSON of the fed message and figure out what's in there. So, for example, we have been having troubles with the Pazure Comets badges. So, there is a lot of badges for commenting into Pazure IO project, like one Comet, five Comets, 20 Comets, 100 Comets. But they have never been averted because the file doesn't work and nobody knows how to write it properly because the badge says Comet, but you can't have a fed message on Comet because you Comet on your machine. You can only push to get. And then the fed message contains all the Comets in that very push. And it's almost impossible or nobody knows how to write it properly. So, the issue with the Pazure badge is you do the Comets and then you create a PR or if there's a big issue that you're working on, there would be multiple authors to that particular Comet. But fed message only contains the name of the fast idea of the person who actually merged the PR and the total number of Comets. It never lists all the authors in the PR or how many numbers of Comet they did in that particular PR. So, that's the issue. The earlier API had the functionality to do that and the current badge rule is written on using that earlier API. So, after the API migrated, we started getting all these errors and we don't know how to fix this. So, I'm going to spend a little bit of time covering the workflow so we can actually get started trying to push the badges. So, if on your personal machines or anywhere else you can load these up, this is what I would call the like sysadmin fedora badges toolbox. The things that you need like minimum viable items you need in your toolbox. Like we were talking about before, all of the design assets and rule files for fedora badges lives in this Pazure repository. So, this is where all the design work happens but this is also where all the design assets live that eventually are synchronized over to the badges back end server. Yeah, if you can get on it on the conference Wi-Fi. We'll figure something out if not. But the other one, this is what I would say is like the definitive guide or standard operating procedure for actually pushing and managing the infrastructure side of the badges. This is, I would say like if you're ever confused about a step or if you're here in this workshop and later you want to try to remember some of the things we covered, this is the best place to look and understand the process. The last part is the badges website front end, which if you haven't used it already, we'll explain a little bit from the admin point of view for using that towards the end. So, I'm just going to go ahead and just do a quick run through of the SOP up here really quick just to run through what that process looks like. And anyone is welcome to stop me at any time. So, I'm not going to talk about the description because that's kind of the technical overview that Saiyan and Miro gave earlier. I'm going to cut straight to the chase on pushing new badges. So, and I can zoom in on this so it's not is not hurting your eyes as much either. Where's my mouse? So, pushing a badge always consists of two operations. When you're doing this, you are going to be pushing the badge assets, which are the the PNG files, the SVGs created by the Fedora design team in the issues in that Peugeot repository. And then it's actually adding the badge to the badges website front end. And there is an intermediary step for how you get the design assets from the Fedora badges to the badges front end, but I'll explain that in a little. So, the way it works is that anyone with right permissions can push to the Peugeot repository, but because everything is now in a Peugeot repository, this can actually just be done with pull request workflows. So, even if you don't have direct commit access to the project or you don't have sysadmin rights to just you can actually jump in and get involved and even do the work. If you see a ticket that has ready to push status in the Fedora badges repository, anyone can actually just jump in and make a pull request to start closing that ticket and pushing out the design assets. So, when you're getting ready to create a badge, from this sysadmin point of view, there's always a few things that we want to check for. One thing that's not covered here that I do want to add in is from this sysadmin side, whenever a new badge is being reposed and if it has an automatic badge rule, it's always a good step to make sure that whatever is being proposed, whatever is being suggested, is actually technically feasible. In the same way that Miro mentioned earlier that there's a fair set of limitations on what kind of automatic badge rules we can push, we need to be mindful of what we can actually push out and have as an automatic badge rule. I would like to see also, which I think I talked to, I think I mentioned it to you or someone yesterday, is that there's a step before that we should add a step kind of going along with what you're saying now. Before the design team designs the badge that a badge sysadmin says, yeah, we're going to do this or not, both because some badges are not currently technically possible or things like we've had come up with event badges where we're not going to make generally not making multiple badges for the same event except for flock. Right, and the design people are nice people. We don't like to waste their time. Yeah, because that's why we're trying to. I hate closing tickets that they've already made art and saying, sorry, we're not going to use it. I would rather say we're not going to make that badge so don't spend your time designing it. So when a new badge issue is made, we should put review on it or developer review or a tag that means that it needs to be reviewed by you guys and then I'll keep artwork needed off of it until that time comes. I think that would be good. No, well, for manual ones, too, because there's some like event badges where someone will put in a ticket like we had the ticket for Fleasall Organizer. But it already got art made and then we're like, no, we're not making that badge because of our general not making multiple badges because most of the people getting the organizer badge or well, most of the people with the attendee badge are also getting were also proposed for the organizer badge. So I'd like to have that conversation separately. OK. So looking back at the steps, so that was just one thing I wanted to add in because that's not currently mentioned in this document. So I just wanted to put that in the beginning. For the rest of this, the work begins once the artwork actually reaches is given the final sign off approval by a design team member. From that point, from the Cisabin view, we're wanting to make sure that then what we're going to be pushing up is clear. So the name and description of the badge that are being pushed, and if you're not familiar with the badges site, this will be the badge title and the little description hover text that goes along with it after it's pushed. And after that, ensure that one of the requirements are met, that for a manually awarded badge, like an event badge, you know what FAS accounts are going to receive the privileges to award it and to make the QR codes to award the badge, or if it's an automatic one, that it has a YAML file with the rule already created. So once you've done that, the checks to make sure everything is all set and ready to go. And if it's not, just comment on the issue and remove data push tag. We are going to actually add the badge assets to Peugeot. So the way this works, and like Nick mentioned earlier, if you have your laptop open, you can try to navigate to the Fedora Badges repository on Peugeot and clone that down. Because there's a lot of design assets in there as well, and we're using a little bit to push the badges. So the way the workflow is right now, the design team will create the design assets and upload them as an attachment into the ticket for a badge. So what we do is we'll take the artwork, the SVG and the PNG, and the YAML if there is one. We'll make sure that whatever artwork we do that we grab is actually valid and correct and looks right. If he is example, sometimes we've grabbed a PNG and the file was corrupt because of something on our end. And sometimes it's been that the SVG was rendered correctly, but the PNG is slightly off-center. There was some minor trivial exporting issue. So it's just good to take a look at it before you go and start pushing this up. So the other thing is once you have them downloaded, you'll put them into the Git repository. You'll see in the repository there's the PNGs, SVG and rules directories. Just a good rule of thumb is make sure that all the files you're putting in for both YAML, PNG, SVG are all the same root file name just to keep things sane. And there is some functionality that exists to create STL files for Fedora badges. So you can chuck it into a 3D printer and get a pretty cool Fedora badge out of it. It's not perfect. It's not really clean if you're a 3D printer hobbyist. They're not really amazing quality, but it's still pretty decent for just having a script that creates them on the fly. But because they're pretty big files, we create them only on request if someone is actually asking for them. And there's more information in the bin directory on how to do this. There's a nice bash script that will run through this. So how to make the 3D badges nicer or easier? So currently, the script is really dirty because you don't have any actual data except colors. And 3D printing usually is without colors. So we turn it into grayscale and then we do a height map of the colors, which doesn't really look good. So what you could do is to create another version of the SVG where only three shades of colors would be used or four. And that would make it easier to print either color badges or because it's easy to print like four colors, but you don't print in true color or something, or you use the color information for height. So you see there is a badger. So let's make him plastic a little bit, make it darker on the nose and lighter on the edge of the face or something like that. So we don't do that. So if the badger is white, it will be flat. And then there will be black eyes. And the black eyes will either be holes or peaks. I don't remember. So it's ugly. But if you use the color not to represent color, but to represent height and has another SVG file, it can be easily turned into 3D badge. So which denotes which? So if it's lighter, then it's flatter. And if it's darker, then it's going to be like a taller height. OK, well, if we ever want to do that again, we should figure it out. But that's something we could totally do, like put in a separate ticket or reopen the ticket and say, hey, we want this 3D printed. So going back into the workflow, just keep that in mind for the 3D printing for at least how things are right now. Script that does have some of the caveats we mentioned here. Once you have all the files in the right place, in the directories, the PNG, SVG, YAML, rule file, you will commit the files and push them to the Fedora badges repository, or just make a pull request for these files. Just rule of thumb on these is just make sure that they have sane names. There's not really a documented, like, you need to name your files this way. But you'll see, like, if you look into the repository, all the bad, there are some badges that are awarded when you are added to a Fedora account system group. And all of those are named like fast, dash, group name. So just try to follow best precedent when you see it. Try not to read. It just makes things easier to find if we're looking for different kinds of badges. So just use your best judgment for what to name the file. So this is the intermediary step I mentioned earlier. So you push the badges into Peugeot, you merge the files in, now what happens? So once everything is in the master branch of the repo, you're going to need to move them from the Peugeot repository to the badges backend server. And this is done via an Ansible Playbook that will take the Peugeot, or clone the Peugeot repository and put them into the badges backend and then restart the server so the files are present on the machine. So this is currently, to do this, you have to be a member of the sysadmin badges fast group, which has a pre-rec of the sysadmin fast group as well. So for this one, you can generally just paying a member of the current member of the sysadmin badges group or ask an infrastructure member to run this playbook, the push badges playbook. So this one doesn't really apply if you're not, or isn't really helpful if you're not in the fast group, but it's helpful to understand that this is the intermediary step, this is the infrastructure portion of actually taking those design assets and moving them to the badges backend so then you can actually interact, or so that they're present on the badges.fadoraproject.org website. So I'm kind of gonna skip through this one really quick, but so there's, like we mentioned earlier, there's the two kinds of badges that are generated. There's the automatic badges and there's the manually awarded badges. And they have two different ways of being created. The automatic badges are actually, I think, easier because you can just do it in the Peugeot repository. And when the Ansible playbook runs, it will create the badge when the badge is back in as we started. The reason why this happens is because, like you saw earlier, the automatic badges have a rule file. What you didn't see in the screenshots and the examples earlier is there's actually an entire section that has like the name, the description, the original discussion, the original issue for the badge. And you can specify those in the YAML rule file. So when you're making a pull request or a commit to the Peugeot, or to the Fedora badges repository, you also have all that info in the YAML file. So when you push it into the repo, run the Ansible playbook, the server restarts, the Terrier front end creates the badge on that restart. So you don't have to do anything except go to the badge on the front end and add tags. That's the only manual step you have to do if it's an automatic badge. If it's not an automatic badge, you have to do a few more steps. I think I can just show this kind of really quick what that front end looks like for the badges site if I'm signed in. Yeah, so this is what the admin portion of it looks like. It's not super intuitive. And so one caveat is like, if you enter bad information in this front end, it's very hard to correct it, which is why generally I prefer the way of the automatic badges of doing it in the YAML rule file. So let's say the badges, I pushed it to the master branch of the Peugeot repository, the Ansible playbook has run, what do I do now? So there's a section down below for adding a new badge to be awarded. So just like in the YAML rule file, you'll give it the name image. So this is actually going to be, I think I give an example of the URL string in that doc, but yeah, I'll make sure to explain that one because of the categories. Yeah, so for the artwork that actually is pushed to the front end, that is generated based on the name of the file of the artwork. So that's why again, like the file names, I think are pretty important because it just makes it easier to locate the artwork. So in this case, there's a badge that if you were to go look in the Peugeot repository right now, you'll find the comop superstar badge. And so after that Ansible playbook runs, if you're going to push a manual badge, you'll find that the artwork for that badge is, yes. So you'll see that the example of this will be the badges website slash PNGs and then the name of your badge that you pushed to the Peugeot repository. So after that Ansible playbook runs, you can actually take that artwork and you'll have to go and double check, go to the URL, make sure that it's there, it looks right. You'll copy that and you'll put it into the Terrier front end in this slot. So you're actually putting a fully valid URL into that field. The description is just the hover text that pops up on the badge criteria. So there is the little subtext there, but the issue where the badge was discussed or created by the design team, the issue link is what goes in that field, which gives us a point of reference if we need to look back on the history of when a badge was created or maybe a rule is broken, we need to update it. We can look back and see where the original discussion was and make adjustments if needed. Issuer, that one just leave as the default. I think that is the only option so you don't have to worry about it. And tags, and this is exactly what Nick was talking about earlier. So tags are a little bit tricky. So the way Terrier works is they're, in the Terrier application, you can specify a set of tags that will display on the main application pay or the main page of the badges website. So I'll show you on, if we go to look at some of the badges here, go, let's go explore, explore and pull this up. You'll see, if we go to the badge index, there are the content badges, there are the development badges, the community badges, and the quality badges and event badges and miscellaneous after that. So I'm just gonna open one of these ones up. We'll look at the Flock 2018 badge just to see how that one was done. So with these five categories, these five tags, those are special tags. So the way that we do things now, every badge, and you might have noticed actually with all of those, each group, each of those special tags had a frame, like had different colored borders on the badges, had different colored backgrounds. That's actually part of the design, yeah, the design scheme for the badges. So a badge will only ever have one of those tags. And it's important it only has one of those tags. So you don't have a content and community badge because then it will show up in both of those parts of the web application. But if you look a little closer, and let me zoom in on this so you can actually see it. So for the Flock 2018 badge, you have three tags here. Ooh, should be two. This is again why it's not the cleanest thing, it's actually the events tag that is the correct tag that will make it show up in that front end web application under the badges or the events category. But you'll also see it has other tags that are helpful just for sorting purposes, like tag. And I could find another badge that has some, like for example, for an event badge, if it's like a LATAM event, I'll give it like event, maybe the name of the event, fleasaw, and then I'll give it a LATAM tag. So then you can go and look at all the badges for LATAM events or for all past fleasaws or so on and so forth. But because of the fact that all those groups on the front are just special tags, you have to be careful about what you fill in in that tags field on the badges site. So once you've done all that, you've put all that information in there, you hit the add badge button, magic voodoo happens, and the badge will actually end up in that badge index on the front page. And so at that point, congratulations, you have pushed a new badge. And for the people who are just coming in now, if you want to take a look at some of these links, I would definitely, we're kind of going through this second link right here. So you can pull this up and follow along with the SOP as we're going through it. All of the action for Fedora badges is happening here. So I just wanted to give you a chance to pull that up if you're just getting in here. Yeah, go ahead. So there is a little bug, which I guess I need to file an issue about. If you add the category tag, when you create a manual badge, it doesn't work. Like if you look, try pull up the one that I was working on for the advocates. It shows up as uncategorized. Go back later and add the tags. Don't add the tags when you push the badge or when you create the badge. I guess, yeah. So what Nick was saying, so if you forget to add the tags? No, no, no, no, no, no. Do not add the tags when you create the badge in the web interface. There is a bug and Terrier does not see the category. So go back and add the tags later. You can go to the badge page and if you're an admin, you have an option for adding tags and because for some reason, Terrier does not see it if you add the category whenever you create the badge. There's some sort of bug. Yes. So that'll be an actual item for us. So just to clarify, there's a field from the app when you're logged in as an administrator where you can go in and add tags to a badge retrospectively. So the best practice for this is actually to do this after the badge is created. I did not know that. So thanks for specifying that. This I mentioned, I think we kind of ran through this when I was in the Terrier front end, but this is just a reference for the badge metadata. Again, like what all those different fields mean. I did explain all these, so I'm not gonna spend too much time other than making sure that if you are in the front end, make sure there's no hanging white space in the description field. And again, like for the tags, make sure that when you're entering a tag, you're following previous precedent, you're following trying to avoid creating new tags because it's easy to add new tags, but removing tags is much more difficult and involves SQL query writing magic. So now once you've done all these things, you have taken the artwork from the design assets, from the Pejor Badges issue, you have committed them into the master branch of the repository, the Ansible to Run, and whether it's an automatic or manual badge, it has been added to the front end of the badges application. The final steps is just to close out the issue. So you'll go to the original ticket where the badge was discussed. Oh, and before you do this, make actually looks right, make sure you go find your badge, make sure it's tagged correctly, make sure it appears in the categories, you're expecting it to appear in, the artwork's not wrong. Just do a quick look to make sure everything looks right. If it does, go back to the ticket in the Fedora Badges Pejor, and you can close it, or if you're making a pull request as a new contributor, you can say a point to your pull request if you did. But what we do is we'll go to the issue, we'll close it out as complete, and just best practice is post a link to where you can find that badge after you publish it, so give it the link to the badges.fedoraproject.org, and if it was a manual badge, please list the fast usernames of any users that have authorization credentials for that badge. And so that's the last step of the workflow process. I don't think we have to cover the rest of this, this is more the sysadmin scripts. You're welcome to go through this on your own later, but that's kind of the quick overview of the actual workflow of how we push badges. So from there, now we actually wanted to give everyone a chance to get hands on, oh, quick question. So I have to leave in a minute to go to the Outreachy showcase, but something I wanted to ask this part of badges is, is there any interest in redoing the website, maybe making badges, a dashboard thing in Fedora? Is there any way to, I mean, or is there any interest? I know there's ways, but is there any interest in kind of updating or improving the UI for it? Because I just, I think it's a little tired, I think it's a little old, and I think maybe we could gain a little more usage and excitement out of it if it didn't look the way that it does. So I just wanted to bring that up and I'd be willing to help from the design side of it. I don't have a ton of experience, but this would give me a chance to get that experience in building something new there. So, I'd like to hear people's thoughts on that. Yes, so one of the things is we probably wanted to move, this is the Fedora Bootstrap layout to unify it with the other projects that we have in Fedora, but as you see, another thing is, yes, we have a couple of pages we really don't use, but then a few things are like, if we can, first thing is we can make it similar, combined with the Fedora Bootstrap and have a better admin page. That would be a very good part and then in general, if we can have the profile page a bit better with a few more data in there. So, yes, there was, so right now I talked to a couple of people and they said that if we can improve the Fedora Badges UI and right now it feels very dull and blocky, so. Is there any way to integrate it into Fedora, like just what you open up, I don't know, a dashboard, kind of a, maybe a mobile app, but like opening it up on your computer and maybe you see it as like a notification, like it comes up, pops up and says, I don't know, like I get like an IRC notification, like this person messaged me, can you do that, like you got this badge, can we get it like more integrated with, and like maybe like you could pull it up somehow and see like all the badges you've earned or I'm just kind of, yeah, I'm trying to, I just wish that it was a little bit more integrated with like, you know, actually using Fedora. A quick idea, since you mentioned the outreach session and I know the call from mentors is opening up or has opened and is in the process of happening, thinking it could actually be a really nice, like outreach-y project to have a Fedora, like to work on the career front and try to revamp the UI, UX, because I know a lot of, we've had a lot of like really great success stories in Fedora with UI, UX, like with Fedora Hubs and with, there's another, I think it was the Fedora Android application, but there's been some other ones that, I know this has been a very great, like kind of niche for us and outreach-y, so this could be like a sidebar we could have maybe after this session about trying to combine, as I think it'd be helpful to have the design point of you and the development point of you for like a project to work on. So who would be like the mentor for a UI side of this? I can't personally like commit the time to do that at this point in my life, so we would have to find someone willing and maybe like it would have to be a design person and a development person together helping that individual. Yeah, I think if we can try to query around do you wanna add? So Ryan was interested in changing the UI and working on that, but probably did not get time, so probably we can talk to Ryan on this, like if he's able to mentor someone on this because he knows the development side and the design side, so. I think you would be a great choice for that. Okay, so for all of you that are here now, we're going to try to do some actual pushing, pushing some badges live right now in the remainder of this workshop. So if you still have the toolbox that I mentioned earlier, these links here, we're going to look at the Peugeot repository really quick. So if you go to the issues tab on Peugeot and you find the ready to push tag, and I'll zoom in here so it's not as painful to see, but if you go to the ready to push tag, you'll see there's actually a series of badges that are ready to be pushed live to the front end. So now we're gonna make this less talking and talking speaker audience and we're gonna make this more like a hands-on workshop. So anyone that wants to jump in how this will work is we can kind of divide up some of these tickets that are ready to push. I guess you'll find out, you'll see the secret, oh, okay. Secret extra block badge. Oh, okay. Yep. Yep. So like. Another badge that you can try to put on here is just, you know, just like this with the badge. Even it's automatic. The block-pitcher's one? Yeah. Oh, it's not true. It's a weird Google Plus action that I think broke or either Flickr or Google Plus. Oh, is it the photographer's one? Yeah. It's a record-taker. Oh, yeah. Partly record-taker. I just will be manually awarding it, but so before we split off, I just wanted to give a chance for people to look at some badges that we can try to push out. And some of, since that meant that we were gonna try to do a ticket triage or some of these other ones so we can maybe do that on our own while we're going through. I don't have a chance to look at this one. The FPC ticket. One, maybe. I don't think there is a number of files, but yeah. So we have some that need, we probably need to have rule files created and we have some that just need to take the artwork and can be made into a pull request to throw on to the pejor side. I'm just trying to find some that, the other way this will work is if someone wants to take one on, we'll assign a ticket to you to work on during this workshop. You can try to run through this workflow on your own, do it, and then we'll run the Ansible Playbook and you'll have a chance to actually see your badge if you have made a pull request for make it onto the front end. So I think one of these is a good candidate here. Or is this one? What I did recently is when I see an issue for a badge that says ready to push and there is a missing YAML file, I remove the ready to push tag because it's not ready to push because it doesn't have a YAML file. So what do you actually, what is possible to do now is Federal Women's Day 2018 attendee because that's manual, Flock 2018 and 17 contributor badges that's also manual could be done here. And for the automatic ones, you would need to check the rules files which I think is maybe too much for a beginner right now. Yeah, fast group should be easy because there are other fast groups, YAMLs. Yeah, the easier ones would be that are just artworks like design assets would be the Federal Women's Day attendee and the contributor badge. If you wanna try your hand at writing a YAML file, like a YAML rule file, this would be also a good one to look at, the Fedora atomic badge request. This one is just when someone joins a fast group, they're awarded the badge once they're joined or sponsored into a fast group. There's some good examples that are already in the Peugeot repository in the rules file you can look at as an example. Anyone wanna try working on these during the workshop or a sign we can split up and sign the ticket? Try your hand at just doing a full request. If you've been able to pull down the GitHub or the Peugeot repository, you know it's kind of a big repo. Free tickets, but actually four badges? One, two, three, yeah. We have three tickets, but four badges because the flock one is two years, 2018 and 2017. And we have four people in here who never pushed a badge, if you had never pushed a badge. Okay, so it's gonna be mandatory. Because you don't see very enthusiastic about picking a badge. So whoever feels for writing some YAML, that will be voluntarily, and if nobody wants it. It's pretty much just. Copy pasting it, yeah. So who wants to? Yeah, we actually have one person for one person. So it's gonna be a pair of pushing of badges. Are you in? No, okay, then one person is already running away. So we can do the flock badges as one. Where about you? Not really, okay, so let's just scratch it and go for lunch. I guess is there anything that we would want to try to work through like from our side as this admin, like take some time to sit down and just try to file some issues or make some miles, keep on the agenda? If we have no volunteers for actually hands-on, maybe you can live push something on the, yeah. So, we'll live push. Let's see, we can do, I guess this one is probably more immediate, right? The flock 2018. I'll do one that's just a single badge. I'll do the one with the rule file for Fedora Atomic. So I'm coming in on this one. So I see that it's been ready to push. I just want to get some historical context on this one. So someone will probably need to be awarded manual privileges to award because they have some people who are already in the group. Oh, and there is the mapping. Could just do that, roll badges. I think I have direct committed that now. I don't think I have to submit a patch to the mailing list now, so that's helpful. Okay, the listing is pretty straightforward. So they don't have the rule file written, but they have the design assets done. Where are the last design assets? This looks like a confused ticket because they want to make it manually awarded, which is something I wouldn't rather do. Why don't we just do the Fedora Women's Day ticket and that should be straightforward. Yeah, okay, so this one had the review passed or artwork approved by Marie here. So this one is ready to go. So in this case, I'm just going to grab the, this is the PNG and the SVG. One thing I don't like about the GNOME terminal is I can zoom in with my keyboard, but I can't actually zoom out with a shortcut. The shortcut doesn't work for me. I do control, yeah, control minus and, oh, it's been broken for me for a long time. Fedora, I've got badges. So I always do a get pull before I push a new badge because the odds are I've missed some new badges that have been pushed since I last did since I last pushed a badge. So I always pull down any last changes since mine or since I've last finished, you'll probably see there's a bunch of stuff that's going to get pulled in here. I don't know how long this will take with the conference. Well, just a few. So that's done. I'm now on the latest commit for Master Branch. So I'm going to just grab the uh, doc, just the long title. I'm just going to put them here for a sec. So I think the precedent for these is actually just going to be the event name. So I can just probably do, was there a Fedora woman day bad last year? Yeah, so I'm just going to. It's a FWD dash attendee. And then there is FWD dash attendee dash 2017. Excellent. So this one. So I'm just going to put the PNG in here. FWD, 10D, 2018. And the SVG to do the same. FWD, attendee, 2018. Excellent. So now that I have them in the right place. Oh, and actually let's make sure that the artwork is actually good because I've done that before where I've grabbed the PNG. Yep, looks like it should. So I have both of the files in Git. Oh, and I have one that shouldn't be there. I have a dirty working tree. I didn't realize that. I'm just going to move that one away. Okay, so you'll see I have the two badges. So I'm just going to go ahead and do add Fedora women's day 2018. Attendee artwork. And since, and now if you don't have access, at this point you would just do a pull request. You'd have forced the repository. You, the best practice would be to create a new branch on your fork repository and then push your changes to that branch. And then you could go to Pejor and make the pull request to the Fedora dash badges repository. In this case, I'm just going to push directly since I have access and just so we can kind of move things along. So I'm just going to take a second. So it's the remake? Yeah. Let's try that one more time. So there was a stay for the recording context. There was a new commit added upstream while I was working on it. So now we have it pushed. It's on the master branch. If we go to the Pejor repository, I'm going to close these since we don't need them. Let's see if they're here. So you'll see PNGs, FW, or Fedora, FWD. Just to make my life easier. Hey, and there it is, the 2018 edition of this badge. So now that that's done, if one of you do the Ansible Playbook run, because I do not have my 2FA with me. Okay. So this would be the point where if you're not in the sysadmin badges group, you'd want to drop a ping to one of, like any of the four of us in this room, or to... Okay. I'll show them the Ansible. Oh, okay, sure. So at this point, you either ask one of the four of us that you see here in this room, you can just ping us on IRC, or you could go to the Fedora-Admin channel on FreeNode and just ask the on call or another member of the infrastructure team to run the playbook. I would suggest try to get ahold of one of us. That way we don't put more on the sysadmin on call people. Yeah, but if you don't know who to ask, you can just ask the question in Fedora-Admin. And one of us should see it there too. Do .members sysadmin-madges, and that will tell you... With Zodbot. Yeah. Cool. Okay, so my run, I just ran the push badges because I was pushing... I just ran the push badges because I was pushing the flock contributor one. Oh, so our back playbook is a script that's basically a wrapper around Ansible playbook to allow people that are not in sysadmin-main to run specified Ansible playbooks, which is defined by what fast groups you're in. Our back playbook will either allow you to run a playbook or not allow you to run a playbook. And normally you have to... It'll say... What is it? Password plus token or something? Password plus token. And you type in your fast password and then either a Yubiqui that you've configured with Fedora Burn Yubiqui or a TOTP token that you can set up using Google Authenticator free OTP or whatever program you prefer. But since I've just done sudo a few minutes ago, it did not prompt for credentials. And you can see what all it says it's doing. And there's actually a badge for running a playbook. Yes. Does that work with the our back playbook? Yes. It's based off of FedMessage and our back playbook publishes FedMessage. What it's doing in the background is it's just taking the Git repository, cloning it onto the badge's backend server. And once it does that, moves everything in the right place, it will restart the badge's backend server. And that's what will make the artwork available to you when you go hit the URL. I think it only restarts the backend server if there are rules. Or no, I guess it doesn't know if there's rules. Rules or not. I think, okay, I guess it's for any Git. It doesn't really have to restart that if it's just a SVG or PNG because those just get shoved there. Okay, so now it shows that everything finished. It even tells you how long it took to do everything. Everything is either okay or changed, which is good. Awesome. Thank you, Nick. All right, so now that's all been done. If you go and take a look at the badge's site, it's there. So now I just hit this URL. This is the FWD attendee 2018 URL that we just pushed. So that is now there on the public web that we just pushed live from the Peugeot repository. So that is what just happened here. So since it's a manual badge, we were talking about earlier with the manual awarding, I'm going to, I said that in my life a little easier. I'm just going to mirror these displays so I'm not like cringing my neck around. That's a little ugly, maybe not. So we'll go ahead and get things back up here. Okay, so now I'm going to go ahead. I don't think I need to do anything more with the Git repository. So that's been done. I'm going to close this out. So now I'm going to go to the badges front end with the admin interface. So now from my point of view, I'm going to go and look at this ticket. And so it's Fedora Women's Day 2018 attendee for the badge title. So I'm going to take that and use that for the badge name. Make sure that I don't have any extra white space. I'm going to take the URL that we just pushed, put that into the image field description. That was also in the badge. You attended a local Fedora Women's Day 2018 event. I'm going to take that string and put that in there as well. No hanging white space. Criteria, that's just going to be the Peugeot Fedora badges repository. I'm going to put that there and I'll add the tags after we add the badge. So now I'm going to push this to the front end and we see you added a badge with Day in Fedora Women's Day attendee. So let's go find it. Let's go take a look at this. Helpful there. Plus one. All right. So the easiest way I think would just be to look, or when I add a badge, I just go and look at the side here that shows all the recent badges. So you will see that here it is. This says an uncategorized badge. So I'm going to go and open that one up and I want to make sure I get, I want to make sure that I get the tag right. It's either event or events and I want to be, I want it to be positive. What's a badge that I know is right? I think that was mine. So before I actually, I want to look, actually I want to look at last year's Fedora Women's Day event. I want to see what tags it has. So I'll make sure I'm following past precedent for tags. So that way, you know, if you go to find the Fedora Women's Day tag for badges, you'll be able to see all of them listed together. I just have to figure out where that 2017 badge is. So it was tagged with 18. That one also has both. That's not a good example. So diversity and event, were the tags used for last year's badge. So I am just going to do diversity and event. I typed those right, right? Yes. So I'm going to add those tags to the badge and give it a second. You'll see, ah, there they are, diversity and event. If I look at the diversity tag, you're going to find both Fedora Women's Day badges. And now if I go back to the Explore, or if I go back to the badge index and take a look around, I'll see that now, those are the ones Nick just added, you'll see that now the Fedora Women's Day badge is listed as an event badge. It's ready to go and is now pushed. But since it is a manually awarded badge, the next step for me would be to go back to the admin interface and give someone the rights to push this badge. So in this case, I know the three fast usernames of the people who are going to need this badge. So I'm going, where you do this is you do create authorization. Oh, why can't I zoom down? So you create an authorization. So the badge is that, and this is mentioned in the documentation. Oh, I closed it. So it's that string in the URL. That's the badge ID that Terrier recognizes as the, oh, it's Women's Day. I'm glad I checked. Yeah, so it's that string that I'm going to take and go to the Fedora Badges front end, put that in as the badge ID. And for the person email, the way that the Fedora, or badges.fedoroproject.org works, you have to specify the fast username of the person and then at fedoraproject.org. So I know in this case, the three or four usernames of the people who will have authorization for this. So I just authorized the fast username B2502. And I know there's a few others that need it as well. So I'm going to add them as the, I'm going to grant them authorization rights as well. And I'll give it to myself so I can actually show, oops, wrong field. Yeah. So I can actually show what it looks like. What does it, what is, what is, yeah, I got that typo. Yeah. Oh, with the scripts. Yeah. So now I'm, I also awarded this one to me. So I can actually show you like, what does it mean when you're granting authorization to someone like you're giving in the right to push the badge, but does that mean they have access to the admin interface? Like what is that doing for them? So they don't have the admin interface, but what it does for them is, so I'm going to go find the Fedora woman day badge. Explore. Yeah. Yeah. Yeah. I was just clicking through it. So you'll see that this field I now have available to me. So when I go to the actual badge page, I see that I have the option to directly award the badge to someone and I have the ability to create an invitation. So for that one, so I think this one is pretty self-explanatory. For this one, and you actually enter the username of the person on this, you don't enter the email, which is kind of not intuitive, but in this case you would get enter the fast user name. So I would say, oh, you know, J Flory seven gets this badge if I wanted to give it to me. And then I would just click the award directly button. An invitation is pretty neat. So this is the one that maybe you've seen, like you've seen here at Flock, you saw the QR codes that were being used for the attendee badge. So creating an invitation will create a badge with a time period that expires. So let's say I wanted to make this badge have a QR code or have a special link you could claim that was only valid for the next 24 hours. So I would give it a time stamp like 2018, the 11th, and the time stamp, you have to give it a time stamp as well. That's in UTC time zone just for reference. So this one would be, would actually be tonight actually. So that would be August 11th at midnight UTC, this invitation would expire. If I were to create the invitation, it would give me, on my badges profile, my personal profile, it would give me the option to grab a claim URL, like a special magic URL that if anyone goes to, they'll get the badge. And it gives me a QR code that I can just like grab and put into a document or a poster if I wanted to print it out. And I think that's just, oh, and the last thing I want to do is just go back to this page and say we push this live in the badges to this admin workshop. Look, the badge is found here. So I'll take the URL of the badge. And then I'll say B2502, Yonah Tony, and JFlurry7 have authorization rights. Closing is complete, closed, pushed, ready to push. So, and that's the process of pushing a badge. So, and now Nick is going to show you in the case, this is only an option for those, actually in the sysadmin badges fast group, if you need to make edits or changes to a badge. I'll let Nick. Yeah, earlier today I was looking back at some past event badges and I noticed that the Fleasaw 2015 badges were, oh, I guess I should make that larger. The case did not match. Most of them were, the event name was all in uppercase. But then the other badges, but the 2015 were not. So I decided I would standardize that. So I actually was using the edit badge script during the beginning of this workshop. So, and then I also, whenever I was, which kind of goes along with what Justin was saying, if you are making a badge, be careful what URL you put in, because it's not very hard to fix it, but it's easier to do it right the first time. It was a lot harder before we got these nice scripts. Then you had to get someone to edit it in the database. Now we have edit badge script. So whenever I was creating the Flock 2018 contributor badge, I put criteria, which is a link to the badges ticket. I put that in criteria and also in image. Instead of putting the, instead of putting the link to the art. So I can just go to user local bin edit badge. I already, I already became root because this admin badges has full pseudo access on the badges servers. Dash dash badge, Flock 2018 contributor. And up here you can see where I did dash dash help because I can never remember exactly what the command is because I don't use it too often, but it does have help. And instead of changing name, I will change image. And it always gives you an error or a warning. You can ignore that. But it does say setting image on Flock contributor to that. So now if I go back to, oh wrong year. This is the, that was the first one I did and it was right. So now the art works with that script. You can change the name, description, criteria, image. Wait, they added tags? Yeah, they ended. Oh, that must have been recently. Oh, okay, then we can edit tags now. I did not, I did not realize that you added that because the last time I took it about tags, someone fixed it in the database. Okay, so yes, you can change tags now. So does that replace the whole list of tags? Oh, okay. So you just do comma separated list of tags. Oh, okay. Well, great. So we can fix up the ones that say event and events even. Okay. I saw those before, but I didn't want to mess, I didn't, well yeah, I did not want to mess with changing those because it was not an easy process. But if it's just a script, I may go through and change them. And we also have a few other scripts. Award badge can be done through a script, although usually I do it through the front end. The reason it, the way or situation where it comes in handy to use the script is if there's a big long list of people to manually award a badge, you could script that. Just have a list and make a script that takes a file of usernames or something and just iterates over it and awards the badge. There's an example of that in the SOP too. Okay. It's like, I didn't know how to do that, which is why I was like, oh wow, like I wish. There is a delete badge. I already showed edit badge. Grant authorization, you can do that from the command line, but usually we do it through the web interface. And there is a revoke authorization and revoke badge. If a badge is mistakenly awarded to someone, you can remove it. But if you remove it, there is a badge called consolation prize that you award them. You award them a badge as an apology for removing their badge. And you can revoke authorization if you accidentally award the wrong username or maybe say some group, the leadership of some team changes and they don't want Justin to be able to award the badge anymore. They want Miro to award the badge. You can remove the authorization from the old person and give it to the new person. I think that's about it with the with the scripts. So I think that's all we had planned to cover for today. So I know if either of you two have any any questions or any any feedback, but if not, then I think we are all wrapped up here. So thanks for coming out.