 So this is the pager training for a thorough program management team The first question that always comes up is how do you pronounce it and the joke works a lot better in text format? But it's pronounced any type in the amount There is actually an old repo with you know How do you pronounce it where people have submitted pull requests of their different pronunciations? Which is kind of amusing So Pager is a git forge that was developed in the Fedora project and is used by both Red Hat sponsored and non red hat sponsored projects now Including some personal use By Neil Gampa on his own server So, you know, it's really the idea is a git forge in the sense of like github or git lab that kind of style so, you know, it's really focused on source code management and Tracking issues and things related to that but it has also grown to be used as Codeless ticket tracker by a lot of groups in Fedora because it you know has issues and it's Provides sort of a unified tool in recent years that also added a Basic can ban board feature, which we'll talk about a little bit When you're using it for issues, there's an issues tab across the top and it's sort of, you know, what you might expect from a issue tracker You know, so you can create a new issue you give it a title And then you give it a description You can do some formatting and it uses a basic markdown syntax and there is a link to the documentation here at the bottom So you can do things like lists numbered list links You can mention specific people by typing at and then their name it will search through so you can search by their user ID and then You can also preview it So this gun sort of gives you a live render you can make sure it's a the formatting does what you expect If you're familiar with markdown it can be very flexible, but also sometimes it's a little persnickety a Lot of the implementations just aren't quite robust enough once you're happy with it. You can create issue You can make it private And some repos will default to using private issues if there are things like the code of conduct tractor tracker Where you want to make sure that people don't accidentally make things public that they shouldn't be So once you create the issue There's comments and again the comments follows the same formatting You can also edit it which is nice The thing to be forewarned here is that when you're editing It doesn't you make it clear what edit was made so you can't really go back and see a diff very well It has tags or labels so you can apply Pre-configured tags the things you can set it that it blocks another issue in the repo And so you could search the five name You can't search unfortunately across repos as far as I can tell for the issue blocking and dependencies But you can also That's as a private again here so you can talk toggle the private status if you have access to edit the metadata We'll talk about the metadata access here when we talk about the administrative side Most repos by default don't let users edit the metadata But some will and if depending on the level of access you may have to the repo you can do that If they're if it's configured you can also have milestones So if we look Another board real quick There are milestones configured and so for example, I've set a milestone of F 34 for the mindshare election interviews You can also set the closed status when you comment it comes with some defaults You can customize those we'll talk about that here in a little bit And there are also custom fields that can be set most repos. I found don't do that so the foot or a badges repo makes use of this by having basically Binary fields for if The different stages of the badge development which things are done which aren't And this allows the team to be a little more rich in the status without having to sit there and parse through all of the comments Some repos will also use a priority field And these are customizable Attributes just you know sort of indicate which ones are the most important issues to work on I found in practice that most times that really doesn't get paid attention to but it is there if a team wants to use that To indicate, you know relative priorities of tasks that need to be worked on one other thing to note about issues is That You have subscribers so you can basically get email notifications about an issue People who are members of the repository and the person who creates the issue are subscribed by default But if there's a repository that you're not a member of but you still want to pay attention to that issue and get notified of updates There is a subscribers thing here And this will say subscribe if you are not already subscribed and you can click that and you will be subscribed to it Packer also has sort of the same, you know get Repository features that you would expect You know apart from just the issues So you can browse the code tree of a repository and see the files you can edit a File in the browser if you need to If you have a fork you can edit in your fork you can do you know sort of the normal get history and Get blame that you would do You can look at individual commits You can look at the different branches of course You can see who has forked it And you can look at the release tags now These are get tags which is separate from the Tags used for issues and pull requests, which are you know strictly you know meta data unassociated with the get repository So these tags actually come from when you do a get tag and then the tag name These will show up as releases So you can do the things that you expect to do with a get repository you can do a get pull You can you know edit a file We'll get commit We'll get push and so once you push you commit will show up in the commit If you have a Fork when you do a get push to your fork It'll automatically pop up the link in the output to create a pull request So you have a fork you can create a pull request from your branch I've actually just done this in my branches up to date But you know, it's just sort of the same you felt which branch you're coming from which plant branch you're going to put into description and Pull requests have the same Labels associated with them the same tags that issues do so that can be useful and you know How a team does its workflow where you know if a pull request is tagged against a certain set of functionality both the issue and the Pull request may receive that tag So optionally you can have a roadmap where you assign issues to certain milestones And this allows you by default shows the active and it also shows Inactive milestones so you can basically target issues towards that milestone as a planning mechanism and then see what what the status is you know how many are completed and How many are still open? Optionally you can assign dates to them. There's not really any meaning other than when you look at the roadmap. You can kind of get a sense of it You know some teams who use the roadmap will tie it to a specific Fedora Linux release if that's sort of what they're working towards For a lot of things like the elections app There's sort of a release associated target in that that's when the elections app tends to be used But it's really a release of the application itself And so it'll be a version number and so depending on what a team is working on and how it You know how it's doing its development or its work that will depend on how the roadmap is used if it's used Roadmaps are per repository So you can't really have multiple roadmaps for subsections You could create different milestones that each relate to the subsection, but they'll still all appeal up here on the same roadmap So similarly you can create canband boards and use those And those can you can have multiple of those per? Per repository so for the old Fedora project schedule one I had one for the elections interviews So anything tagged with election would be put on it And this is really how I used it to track state because the way that would work is Candidate would submit in an interview. I would enter it into WordPress. I would send them a link to review it it would review it get published and then Be done and so, you know, it's you know, very simple very basic can band functionality you can drag card from Column to column and these are all just issues and then when I drag it into published it knows to close them You can't do some of the fancier things that you can do in for example Tyga where you can set swim lanes and work in progress limits and things like that. This is a very simple functionality if you're familiar with like Trello Especially a few years ago when it was much simpler. It's you know, very the very basics of card moves from one column to another But it can be very useful for tracking state when a group is mostly working in pager and also This doesn't need a lot of the robustness that other can band tools provide Okay, so let's talk about the administration a little bit You know all the settings are in the settings tab So the first thing to know is that you will probably be prompted to log in again And when you go to the settings, just you know sort of as an extra layer of security So you can set project details are a ton of project settings along the side here I'm not going to hit all of them But just sort of the main ones and the documentation covers the rest of them in depth But the first thing to know about is the users and groups So you can add users and you can add groups and these groups are not the same as Fedora account groups, unfortunately, they're unique within the pager system So if you're an administrator of a group You can go in and edit that group. You can see the members and you can See the projects You can change The group you can give it away to somebody. You can also create a new group Same way you would create a new project And the members it's basically members like there's not Not really tiers of membership So the way you handle different Levels of access are with the roles. So for example, I'm the main admin on this repo Marie as the F cake is The is an admin on this repo because her job is partly to be a Backstop for the elections issues and then I also added the BGM team as an admin So you can change the access levels and they're described here But basically admin can edit all the settings and things like that. There is Commit level access where you can Basically do anything except change the settings A collaborator can Do most things but can't can only commit to certain branches and then ticket Access basically means you can only edit the metadata of an issue And by default anyone with with no specifically defined level of access can open issues can view Public issues they can view their own private issues and they can close their issues So, you know in general you'd want to have a couple people up with at least with admin access generally maybe an entire teams group would be an admin and then if they're sort of Peripheral contributors who you know might commit to the repo but don't need to access the settings you would give them commit Take it because it doesn't provide a lot of additional ability beyond Just being able to interact with repos most people don't use that level of access very often But if you want people to be able to access metadata and you don't have to explicitly add them So say you want people to be able to automatically create Or add automatically add labels when they open an issue for example There is a setting in project options Where you can open the metadata access to all so that means any authenticated user can Change labels change milestones change a sign me things like that For a lot of projects, that's probably fine. Some you might want to be more specific about it You can also toggle here whether issues default to private or not And you can also set the issue trackers read only you can even disable an issue tracker if you really just want it for code management purposes There are other settings of course you can look at more So we talked about the tags, so that's its own separate setting You create these manually and you can delete them So basically what you do is you give it a name you give it a description and you set a color by picking it somewhere on this color wheel I Think they all default to black like there's no randomization of the color Which is a little unpleasant, but that's okay and then of course tags can be assigned to issues and pull requests and They can have multiple tags to manage boards You can add or delete a board and you see here it's based on Has an associated tag with it Give it a name Decide if it's active or not and you can configure it and this is basically where you set the different statuses You choose one default status and you can have multiple statuses where it will close the issue and you can pick which Close status it uses so for example published is closed If somebody's withdrawn or removed from the ballot because they didn't submit an interview or they changed their mind and decided not to run after all That's a different state on the board, but it's still closed and it's fixed. It's closed as invalid instead of fixed And then of course from here you can go and actually see the board so as you can see board management is very Simple there's not a lot of features, but that also makes it very easy to understand and work with You can also Create custom fields and So you might call it Bob and you can choose different field types, which will just do a little bit of validation on it These are all pretty straightforward And of course you can delete custom fields when you're done if you don't want to use those anymore You can have different closed statuses So, you know for one team it may just be It's closed don't care the different statuses for some you might want to say You know if it's used if the repository is mostly used for voting on issues It might be approved rejected withdrawn or invalid if it's for code it might be Duplicate fixed insufficient data or invalid Things like that. And so, you know, it's very customizable to how a particular team is using the issues And you can even have sort of if you have a mix of both like code and voting you can you know create different Statuses for each of those on the roadmap We talked about you know having different milestones with a name an optional date You can set the order and then you can toggle which ones are active if you're working on a board that has old milestones You can show The old milestones as well or turn them off if there are too many I talked about priorities a little bit by default there are no priorities But you can add new ones and you can give them a weight The lower the weight the higher the priority. So you might have like one omg on fire and then 10 is Better hurry and 100 is Everything is chill Obviously you'd probably want to use more descriptive ones the Fedora council ticket issue Q suffers from some very undescriptive priorities And it also Tends to use The priorities also to indicate blocked status, which is probably not the best way to do it It's just one of those things I haven't gotten around to coming up with a proposal yet Some teams will also use labels to indicate something is blocked or stalled or whatever reason So it's basically just you know, whatever workflow works best for the people using it One other neat feature that it doesn't get used much, but I've started using it on the program management team repo is There are things called quick replies where you can Put in It's basically text that you want to be able to add to an issue very quickly And so you put in the same markdown formatting that you have The difficulty is because they don't have labels. It just basically shows you the first 50 characters So you want to make it a little clear if you have multiple ones, which one it is so you could use You know the html comment characters to say Give it a label and that shouldn't appear when you actually Preview it so you can see this in action if you go to the issues So If there's a little drop down here if there are quick replies configured and you would select it and Then when you preview it you see the html comment went away These is really handy if it's being used by for evil with external bug report kind of things where You know, you know, you're gonna need to ask them every time. Hey, you know, please provide this this this this and this Or if you have just other sort of procedural things where You know, you find yourself typing the same thing over and over again, I just sort of save some keystrokes and also provides a Little bit of consistency in the messaging Similarly, but managed more difficultly there is Templates that you can use for issues so I will show You that so the issue templates features a lot older. It's a little more complex So it it's managed a little different way so When you go to a clone or repo you see there's other get URLs drop down and There's one for issues also one for pull requests, but for the issues one what that gives you is essentially a Text a JSON file of all of your issues, but also let's see great templates so I've got the Fedora project schedules issues repo checked out and so you can see there's a whole bunch of files there. They're just basically with the UUID So I can just you know cat one and look at it. So this is basically a JSON file of The contents and metadata for an issue That's not particularly helpful. Although you can use it to migrate issues from one repository to another I think But but really useful part is this templates directory So if you go to the templates directory you see markdown files We look at the council election directory it says You know, these are basically the interview questions that we use for the council elections so when somebody creates an issue in that repository they can select from the templates and then load the template and It'll give you the instructions and the text for them to fill in. So this is really helpful if you want people to you know upfront before they even Provide any information is here's the stuff we're going to ask you for In the URL you can even specify Which template you want to use with template equals and then the name So that'd be the name of the file without the dot md So you can use you can use this URL and put that in documentation or things like that to automatically point people to the right template As soon as they click the link to open the issue But because this is done to a Get repo you actually have to get pull and then get pushed to update the templates you can't edit it through the DUI or the The normal like editing in the files interface because it doesn't show up in the files. It's it's a separate repository That's sort of attached to the code repository So it's a very powerful and useful tool to set up a template, but it is a little bit of a You have to remember to do it slightly differently And you have to remember to clone this special repo