 Hi everyone and welcome to this Fedora Badges workshop. I will share my screen and we can start looking at the wiki page. So is my screen shared? Yep. Yeah, that's clear. Okay, so the idea for this for this meeting is to try to come up with user stories for each of the personas identified in this wiki. We can also, if you think of any personas that we missed out, we can add some. That's fine. And we try to take each of them and try to come up with a few stories on how to improve the application. So we try to follow the initial story type as a type of user. I want some goals and try to explain why we want that so we have a good reason to do it. There is one persona that's missing. That's pretty common, which is it's a Fedora community member, but not necessarily in the mode of collecting badges. They want, they want badges created for their team or their initiative or their project. They're not going to put in the development effort or the design effort, but they want to submit that badge idea and like have that badge created. So that would be Fedora community member. So user that would like to submit that would like to submit new new badges idea. Yeah. And the thing is, like, sometimes they're very like, last minute, like, oh, faucet them isn't two weeks. We need a badge. You know, or sometimes it's like part of an initiative and there's like a wider plan. So there's like a range there. Okay, so do we want to start by the first one? So designer. So I put designer is creating the artwork associated with with a badge. So, since we have you more, you will be able to give us the the main point. One of the most common ones is as a designer. I'm looking for a badge that I can work on artwork for that will actually happen. So that I'm not wasting my time because nobody there's that's like one of the common complaints we have from designers is they're doing artwork for badges that never happen because they can't be implemented or. They don't follow the guidelines or whatever. So as a designer, I would like to make sure that that's what that I produce will be will be. Well, I think it's more, I think it's more finding finding an artwork ticket to fulfill. That's not a waste of time. It's more about like, it's less about, oh, I'm doing work and I want it used and it's more about just tell me what to do that will be useful. Because there's a lot of open artwork tickets and it's hard to understand which ones are the most useful to do. Find another ticket that I can implement. So that I'm contributing and not wasting time. Could this be solved by using something like I'm thinking Kevin board where you submit the ID in the backlog, it moves into the technical part because technical part is going to be the limiting factor. And the artwork comes only once the technical part is done. We've had the equivalent of that in the old track system and I think in regard to where it's tagged with different things. But the problem is that designers don't understand like Trello boards, they don't understand ticket systems that deeply. So they just see artwork needed and they don't understand how to translate the different columns or the different tags to understand which ones. And a lot of times they'll sit there and they're not even triaged. So it'll just say artwork needed and it's not clear. You know that it's actually been triaged. So maybe the workflow should be a bit simpler or better documented. Yeah, honestly, like, I would say that for for artwork contributors in particular because like, they're not typically sophisticated, like issue tracker or con bond users. If there was just like a simple page that just only displayed the ones that have all the approvals. Right. And show those as like newbie friendly ones, because that's like the biggest issue here is for newbies that don't have experience and we lose a lot of them because of all this confusion. It's not approved artwork it's approved artwork request, because the artwork is not done yet. That is easy for me to know request I should work on. Right. Another one that's common is like I'm the artist. I did the artwork. A person who requested the badge is asking well where's the badge. Can you push the badge. I need to be able to find something like I end up being the contact point of finding somebody who knows how to push the badge to the back end. So it's like as a designer, I need to be able to get a status update or contact someone who can push the badge. And honestly, it would be even better if like as a designer, I was not the liaison, I do my artwork and I'm done and the person who requested the badge can get status updates self service and make the request to the badge pusher on their own that would be even better. So either designer I should not be. Yeah. Yeah, exactly to push. I don't think we need to. So that's on this one. But yeah, right. So, I think those are the main trouble ones I can think of. I mean, there's other user stories for designers, but I think those are like the main pain point stories. All right, does anybody else have some thoughts on that. We move on to the next person. The only other one I could think of is just getting attention, like, especially when you're getting to the bottom of the barrel. The only badge artwork requests left are ones that you don't know as a designer is this even implementable. Can somebody actually do this. So it's like getting as a designer, I need to get timely feedback on someone familiar with how the system works with with a developer. Basically, I, as a designer, I need to be able to get triage help from developers in a timely manner. I think should the, for example, because we said that if we have this page where the approved artwork request was available. It's be approved only if we already have all the rules implemented and things like that so we know that. I guess this is more this is less for newbie designers and this is more for the designers managing the project. Because if, like, I think if we had a page that showed all only approved artwork that was ready to be designed. We'd probably turn through that really quickly, but then there would probably still be a big backlog of untriage stuff where we don't know if it's worth doing the artwork. And as like, you could say as a senior level designer or as a maintaining designer or something a design maintainer. I need to be able to get timely feedback triage feedback from developers on the feasibility of badge requests. As a designer designer. Yeah, designer with a hat. I need time. Oh, I need help triaging. Timely help triaging. Yeah. No, which request can be implemented. I think that's about it. All right, so we can move to the administrator persona so I describe this as the person which actually managing the badges on badges application so can create new one give new one. Edit or delete badges. I'm not sure we have anybody that is. Do we have anybody that is familiar with the process there. If not, I think there was one main complaint by mirror that there's some of that. And in the console ticket you wrote that the current new badges deployment sucks, but there is no death or death time to make it any better. So I've looked quickly we have a SOP for badges and there's like quite a big list of things that you should do to push new badges. And it sounds like there's like a lot of manual steps or maybe a simple user story would be to try to automate some of those. The steps are easier. As an administrator, I want it. I want the process of creating new badges to be as automated as possible so I can save time. Something like that. Good. I'm not sure we have anything else on like give power. I'm not super aware of the process to actually give or edit. I think to give badges we have like, you have to actually log into a box and run some scripts. I've had to do that before there's a web UI that it's very confusing. So if if a badge can't be automated, then there's a process where when the badges created in the back end, different fast accounts can be given permission to manually award that badge. So I've had to manually award that badge for like different fat events and stuff that I was the organizer for. And it's very confusing. You have to navigate to the badge itself on the badges page logged in with your fast ID. And there's like this weird form at the bottom of the page that just appears if you have that permission. There's no like overview page that shows you which badges you have permissions for. It's very slow. You have to do it one at a time like you can't just enter in a separate list of accounts. You have to load the page fresh every time it's super slow. It doesn't give you a good feedback. It seems to crash sometimes in the middle of it. So yeah, as that's not really an administrator though that's more. It's more, I guess maybe it's another persona. It's basically a an individual badge maintainer. I mean it's nice that there's a front end to do it, but it's just not a scalable front end at all. It's very painful to go through. And there's no auditing for it either. I think so like, for example, I've gotten into situations where someone was given a badge that I had this permission for. Other people had permission to award the badge that should not have had permission to award that badge and it was awarded to someone who really shouldn't have gotten it. And it's not something that you can audit like who gave this person the badge and when did they give it to them. I don't know if I, if as the badge owner, I don't know that I have permission to revoke it. So we've had some, I want to say the only like one or two but they were pretty tense drama filled situations around this. So for the individual budget maintenance I would like the process to award a badge. To be more scalable, because I might have a list of like 100 people who attended an event. And I just want to like, upload a CSV and be done with it. I don't want to have to fill out a form and load the page under dives. Yeah. Mass award badges. Oh yeah, that's fine. So, another one is like as a badge maintainer. I need to be able to audit who gave someone a badge, and when it was awarded, so that I can ask them like why did you do this. And this, this might be like under that umbrella but it would be nice to get a notification to if somebody who's not me awarded a badge that I own, so I can kind of know what's going on. And then they find this later. Yeah, yeah. And then the other one was as a individual badge maintainer. It would be nice to have permissions to revoke a badge. If it was awarded an error. And one was about getting notification I think. Yeah. And I would, I would caveat that with, if it's a manual badge, because if it's an automatic badge, I don't care. I don't want to get spammed. But if it's a human being entering it, I'd like to know. So I would like. When my manually awarded badge maybe want to receive a notification or do you want to have the possibility of reviewing it. Oh, well that's even better. But but then you got it. The only thing is that complicates things because then you get into like a hierarchy. Like if there's three people who manage this badge who's who's the top cheese. You know what I mean. I'm not speaking about like approving, I'm speaking about, you know, having the history of who has done. So I think that's what. Oh, that's the audit one. Yeah. Yeah. We keep history of would you do it and when that's quite great. I mean, it's going to bust up this underground network we have of like badges instead of as like a currency for doing illegal stuff. Some people are very into like getting more badge points and their their ranking, I whatever. I'm definitely one of those people. Oh no, sorry. I'm sure you're not cheating. People I think people see the design team badges is like an easy way to cheat, you know. Yeah. When I see things that I can do and then someone's like, and you get a badge for I do that thing. All right, so should we move to the next one. I think contributors. I added that as a user that would like to create a new badge. I think it's the one we added there. The federal committee member that would like to submit your budget here. I read contributor as the person who actually implements the badge, but like writes the YAML or whatever. Okay. Maybe I would just make it clear. I don't know if it's YAML I'm just guessing. I think it is but yeah it is. Yeah. Some badges require actual like code, right? Or is it always YAML? It's always YAML but yeah. I think for some things it could require code depending on like the subsystem like if you want something that's automatically awarded. When some event and some infrastructure piece happens and there isn't a fed message or whatever that you can trigger off of it then you have to do implementation work too. I have a ticket where I wanted to make some funny bode badges and I think it would be more in that second category because there's not that messages for those things. Yeah. Yeah. Also, also sometimes you probably need to add those features and like for regular badges we did add a climate climate added PR and to handle those badges accordingly. I think there's probably a few levels of this type of contributor. There's the contributor that everything they need is already on fed message. They're just doing the YAML. And then you have the contributors who have some ability to actually go to the upstream and for apps and modify them. And then there's the communication between the two. Like, hey, I wrote this YAML, but I need this. Then you upstream maintain or do this for me. So those are sort of three main cases I think for contributor. Yeah. So in my case, if I forward a modified body so it sent a fed message when the thing I want a badge to happen, then I could write YAML in the badges thing. Right. There might be a good way to do it. Yeah, I think that's what, what Miro was adding here also that there by this is really get ready on artwork side and then sit forever to get the rules that you know, five, because nobody involved is capable of creating a new rule. So I think it's not, it's not very straightforward to create a new rule. So I'm not sure if we have a good documentation for that. Yeah, so maybe like as a contributor, I want to create a YAML like a simple YAML, but I don't even know where to get started. So I guess I want to know where to get started on creating a straightforward YAML rules. A lot of time I believe it's the issue is like probably it's not even if it's there, the contributor because the lambda things are so complicated that rules are so complicated to write. So people have no time to write it to think and write it. Well, like what we do, I mean, I kind of think there's a parallel there as a quick aside, like with the artwork, we definitely have a spectrum of abilities in terms of people's ability to do the artwork. So what we do is we have a set of like reusable assets of like pandas and badgers and snakes and mushrooms or whatever, that people who might not be able to illustrate on their own can kind of take and remix and make new badges using them. So it might be interesting if there's common lambda rule issues that have already been solved in other YAML files. If there was some sort of sheet that was like a template, like if you need to do this in your badge rules, follow this as a template so people can kind of copy paste and grab and go the same way that they do the artwork. I mean, I don't know if that's possible with YAML, but if it was that might be a good. Maybe we can have like, so yeah, so there. So there are basically if I remember there are a couple of like five, six common types of templates or maybe we can have a script where it asked like which type you want to make and then give a basic layout for the YAML. And then you probably edited but then probably we can work on this and have a script on that. I would even push it beyond cheat sheet and and say exactly that like a template library, right, or, you know, it's the script would pull from a template library to give you sort of a something to work from. Of the most commonly used. Yeah. Lambda, whatever. That's a technical term, landing, whatever. For example, I found that when I had to work on the one for Tiger badges. We have a small unit test that maybe we could try to make it more generic where you actually, you would be able to have the fan message. That you expect and test your YAML to see that that could be like a tight, tight feedback loop where where you're going to comment. Yeah, I'm not sure I don't think it would be too too hard to do. You would like, maybe have like two files one where you put like the expected fed message and then your, your YAML five, you just run one common and it gives you if it works or not something like that. That would be fantastic. You think it would be possible for him. So, I think it could be possible so I was looking trying to look to the badges and I was just trying to remember how the lambda function looks so if we give. So basically fed message a dictionary so if we give a dictionary and then ask for the key so maybe we can make one around that. It comes in where it basically like Koji base like we have when you do a 50th build or 1000th all those rules also needs to be generated. So we need to extract those also just not lambda. We can look around that it's not that difficult because there would be common badges like once in a blue one we might need manual introduction and build the rules from scratch. Anything else for the contributor. Well I think these are all sort of for the, the lower level contributor. So I think you would have one like as I say lower level I don't mean it like that I mean more someone who is not like an upstream maintainer of info apps. So it could be like as as a YAML contributor. I would like to be able to figure out or locate the correct maintainer. To add fed messages that I need for my, my rules. Because maybe they don't even know like who's the right person to talk to or how to even get that conversation started. Which person. Yeah, I'd say upstream maintainer. I would assume that they would know the application. I don't know that that's too wild an assumption. Maybe we can add this as into the template of the, when we are creating the badge. Issue. Yeah, yeah, like kind of like you check off which one. That you need rules for whatever that you need a message for. If you can have a very detailed issue template basically when you're creating the issues you have to build a bunch of data in. So that it gets easier on our side also. So maybe they need help like probably we need to. So, so suppose for a first time contributor coming down to give a batch idea. They might feel that over mem and a lot of things so. But suppose there is already a batch idea and somebody wants to write a rule for it. We need to have something on the issue itself that this is the upstream maintainer. Please go and contact. Something on this. Right. It might be interesting to just a random idea is if you could sort through the list. If you could easily access and sort through the list of YAML files that have already been created for other badges, like just as a one. One stop shop. And you could sort them by app. So like if you know that your rule is going to involve working with Bodie, you could look at like the 10 other Bodie related YAMLs. That are in the system for badges to see how they did it. Good example. Yeah, like as a contributor, I would like to easily be able to access and sort through. All of the existing YAML rules in the system. Because right now I don't know that that's so easy. I think the way that I do it is I go on the website and I look up the badge and then there's like a link at the bottom to get to the YAML but there may be a repo somewhere I don't know about. There is a repo, but I don't think it's very obvious which which holes is associated to which application. I think the rules has got the name of the badge but sometimes it's not. No, it's like a metadata issue. Well, don't don't don't the fed message things have like a namespace that would indicate which, which app. Yeah, topic from the topic we can figure it out, but we need a very good search around the rules. Yeah, so it's possible. I mean the metadata is there. It's just not easily usable right now. Do we want to move to the next person or we have anything else, something more on the contributors side of things. Probably move. The developer so someone that develops and maintain the application. So I think the big thing that I think of now it's the deployment of the application. It would be nice if it was more automated and could just like push new ease like with like just like a commit or something like that. Continuous delivery. The badges already moved to open chair. Not yet. But we are planning to. It should be easier to the plate. There is one thing that I found a bit confusing with the developer side is that we got so many repos. I think we got one report with the front end one repository with the back end that accessing the API is to access the database. One repository that is the fed message consumer. And then we got the other repository for the rules. So, if you're confusing to at the beginning, at least for someone who's looking to start contributing to this project is like, if you're confusing to find what, what is what and where I should go. So, did they have the same documentation. Go on saying. So, right now we have three. So, right now we have three repose the one. One is the one which makes the connection with the DB is basically an API around the database. Then we have the pyramid application which uses the DB API to get all the data. And the third one is fed badges, which is the federal fed message consumer, which has a rule generator and rules for sir. And the fourth one is probably the one where we maintain all our assets for the badges. The rules and so we can probably leave the federal badges which isn't regular side and merge the consumer DB API and the pyramid application into one. Because the documentation is also separated and it becomes very difficult to even like to test application I need to like probably move around the report and start three different servers and work it out. Even if for the deployment later if we look to have something a bit more automated it would be easier to just have one. Yeah. Do you need your own consumer for federal veggies or could we use the developer. No, we need the consumer because it's real time basically as soon as it listens to all the messages and fed message and keeps passing them. It would be very difficult for data because I don't find data to be very reliable like if you do 100 queries it would go down. Okay. Do we have anything else on the developer? Yeah. Yeah. So another thing from my side would be like one thing which is like if I push new things like we have the path support for a long time now, probably two years now but we don't have a front end to it which is basically one of the biggest next thing in badges. So if we can have mock-ups for badges and basically the stock around because we have been planning or revamp of the UI revamp for badges. So I was like a new content design or UI design. So, so, yeah, one is as a developer I would like a new UI design for badges and the other one would be as a developer I would like UI mock-ups for the newer features that we push. So that's, is that okay, Sayan? Yeah. So in the administrator we can probably add another thing which is like the admin panel is not very easy to use so probably a better admin panel in badges. Next. So are we happy to move to the next persona or anything else on the developer side? We can move to the next one. So the community member and this one like more related to the community members that are collecting the badges. They think that the user of badges, Roger, the badges. Oh yeah, let's see. Do we have anything on this persona? I guess a lot, a lot of things would be maybe for the UI. Yeah. Better UI and now faster, let's say. So in the better UI do you have like more like specific example what could be improved? Right now like. Oh, sorry. Well, one of the things and this isn't necessarily like what the badges user want it's more like what the Fedora project wants. So one of the ideas that we had for badges that we never implemented was using it is almost like a training platform. So to have a set of badges that were related that you would like work your way up. So for example, as a badges user, if I want to become a designer and join the design team, and I've earned like two or three design badges. What are the next ones I should be working towards and what I have to do and how far I am to achieving some higher level goal, like, you know, becoming a design team, whatever, a certified Fedora designer, something like that. Or, you know, whatever the area is within Fedora, but the idea is that it's not just like, like the fun little one officer, great, they're fun, but we also want people to learn. So, I would like to use badges as a learning path to. He also planned gamification around the badges project to gamify the complete. It was like, as a badges user, I would like to know what are the next badges I need to complete to achieve a certain skill or something like that. Like what are the next ones I should work on. And I would say maybe a closely related one is as a badges user. I want a need motivation to, to keep going. You know, like, like, I don't know if anybody uses something like Duolingo where you're using it to like learn a skill. And then if you don't log on for a while, it harasses you. Something like that where it like, I want it. I want the system to check in on me and like help keep me accountable for my learning. You say remind or motivate or help motivate me to keep going. So that you learn your skill, the skills you want to learn so that I learn and improve or whatever. Basically, you don't fall out in between and forget about it badges will remind you and then you can log in and start working on it again. Yeah, exactly. Did you add something cyan before. Yes, I was telling like the first. So the first thing we have that the back end is actually implemented. We don't have the UI for that like we can totally work on the UI to implement a lot of things but the back end is there but we never got to work on it. Another thing is the website is really slow. So probably from the back and I have got a lot of complaint from different badges user that it would be helpful to have a better like more faster website. And another thing would be which I have got feedback is a very much better. So right now we just list down the badges that we have on a page. There's a explore page where we list down all the badges and people have actually requested me to have that more intuitive so that I know which all badges to approach approach next rather than. So right now if you want to know which are badges I want to achieve I need to go to each and every badges and see the description and basically see the description and see if I can achieve that audit pulse through on my goal or not. It's not very you cannot really see what the badges does from the icon. So basically if we can have badges to as a federal badges user I probably would like badges to give me on the UI itself suggest me these are the badges you can go for or much better search page for badges list of all the badges. Would that be covered by this story not to know what are the next badges I need to complete to achieve a skill so if you start something, it will tell you or next thing you should do with that. Do you think it's kind of. Yeah, I think part of it to is not just. I think what you were saying is not just the next badges to do, but what I've already accomplished and we actually there is a front end design for it that wasn't ever implemented. So even having a flat list of just the badges and whatever random order, they're categorized, and they would give you a thing so like each badge, at least the artwork is coded to like they have different categories like there's. There's like a whole infra and then packager and design marketing contents. You know there's like different categories of badges. So like if you had 80% of your badges were in sort of the content and design category, then it would classify you as like a content design expert kind of So it's almost like as a badges user. I would like a good high level picture of what I've already accomplished and it's it's. I mean where that also comes into place where we were looking to do in other areas of the Fedora project like we wanted to do a thing in hyper kitty and we wanted to do a thing and other. So one of the other apps where people have accounts is to show the person's badge personality or profile. But like if you're having an argument with someone on a mailing list, and say like all of their badges are for like design stuff and they're arguing with you about a badge, then you know they don't probably have the background required so like you understand the context of the conversation versus someone who like has achieved all the development badges and, oh, well I don't know what I'm talking about I'm not going to argue with this person or whatever it it gives you a sense of the work that that person has done, you know like oh well you've been a long time contributor you've accomplished all these things. Maybe I'll give you a little bit more deference on the mailing list or whatever, you know, so I guess there's two prongs there it's, I would like to have an overview of the badges so that I can have a good picture of my accomplishment. It's sort of not as a badges user necessarily but more as like a general fedora community member, I would like to have a good picture of other fedora community members. It's not it's not that one it's more just generally like for a wide like a person I encounter in fedora. I just want to know, very quickly at a glance what their background is, because maybe I don't know who they are, and I just want to know, you know, where they do in the project. So conscience of the time we've got five or four minutes left so I think that will be the last story we do, but I'm planning to maybe run something similar. Next week or the week after and maybe we'll try to categorize so prioritize those stories and maybe try to go a bit deeper in some of them. And look at maybe acceptance criteria and what what we need to achieve them. So I would like to use badges to get to get to know. Yeah, yeah, to get to know understands other community members. All right, I think we've got a lot of great content there so thank you everyone for joining and contributing to this session. I think it was super cool. This is very good thank you for running it. Yeah, no problem. And, yeah, as I said, I'll share this on on the list and try to publish the recording or so on YouTube and I'll try to run an over session or so to go into a bit more details for some of those. Thank you everyone. Yeah. Bye. Bye. Bye.