 All right, so welcome to the Tyga training. So what Tyga is, it's an open source project management tool. So in Fedora, we have an instance that we pay the Tyga team to run for us. It's at teams.FedoraProject.org, but there's also a free public instance at tree.tyga.io that you can use. So the main feature, the way I mostly use Tyga, and I suspect most people, this is the case, is really use it for the Kanban board. So if you're not familiar with Kanban, the sort of basic idea is that you have cards that represent work and they flow through different stages. And so for example, you might have a backlog and then if you're writing blog posts, you might have the writing column, the editing column, and the published column. And so each card would be a blog post and you move it from one column to the other as you go. The idea there is that you have very easy transparency into what work is being worked on by whom and you can sort of see the flow. The idea is that you basically pull each card forward as you have capacity. So it's basically that everything is getting done as soon as possible. So you're not really like scheduling the work in the Kanban model. But you know that as soon as somebody has capacity, they're pulling the next card forward and so things are happening as fast as they're going to happen. One of the features that often gets used in a Kanban model is a work in progress limit. So for certain columns, you might have a maximum of two cards and the idea there so that you don't end up pulling a bunch of stuff into in progress and then you're not actually doing any of that work because it's all stuck. For myself, I tend to not enforce automatically the work in progress limits the way Tiger lets you set a maximum value. But I definitely try and pay attention to, all right, I've got five things that say they're in progress. That's probably not true at this point. Some of them are probably waiting or they're ready for test or something like that. There's also the concept of swim lanes which can be a way to divide work among larger heterogeneous teams where maybe you have like development and testing so you can move the card between the swim lanes and then for each swim lane, you can have different work in progress limits for the same column and it's basically just a way to represent not necessarily at a per-person level although you can do it that way but maybe at a per-function level what work is in progress and set limits that way. So we're gonna look at the Fedora magazine's Kanban board as sort of an example of some of the basic usage. So you can see there are different columns representing states and so in this case, the article spec state is for an approved article that has maybe a rough outline defined but isn't actively being worked on. The card moves to in progress when the author is working on it. It goes into the review state when it's ready for an editor to look at it which point it moves into edit. The editor works on it when it's ready to publish, it gets queued and then from there it gets scheduled and so archived. So on each card, there is a card description. In this case, it's basically the title or the rough title of an article and this should be a very succinct but clear explanation of what the work is. So you wouldn't wanna say but do stuff but also you want it to be short enough to read so you don't want to describe the whole work to be done. And then so within each card, there is an area for sort of a longer form description. Tyga will let you do it in markdown or in HTML. So you can do things like lists and stuff like that and sort of describe the work in more detail. You can go down to the comment section and you can use this to communicate with people on the card. So you can add in a comment here and says, hey, are we ready for this article yet? You can tag people using at and their Fedora account name. You can set due dates, it's a calendar and this can be helpful for the magazine it's used to sort of plan when articles will publish. Tyga does not provide a sort of integrated calendar view which would be really nice. The way some other Kanban boards like Trello do but it definitely helps to sort of set deadlines on things that have deadlines. You can even create tasks and these are basically sub-components of the user story. There's not a hard and fast rule of when something is a user story versus a task but basically, for example, when we have Fedora council face to face I'll usually I'll have a card for that and then I'll have four tasks underneath, schedule it, prepare the agenda, do the Zodbot readout after the fact and then publish the community blog post. And so all of those could be cards on their own but since they're very tightly related to the overall concept of the Fedora council face to face meeting I choose to have them as tasks. You can also use labels or tags in the magazine that's mostly used for the needs image tag and that's just an indication to the editors that featured image needs to be created. On the Kanban board I use to keep my stuff organized. I have things tagged by, if it's documentation or process improvement, if it involves bugzilla, if it involves legal questions, things like that and that's just sort of a nice visual way to highlight things that are certain types of tasks because you might want to break up and not do a whole bunch of super related tasks at once because you get kind of burnt out on it or you might say, oh these are all related to documentation I'll tackle these all at once because I'm already editing the documentation in that workflow, so I might as well do it all together. So that's just sort of a way to organize your work. Some teams find them helpful to use, some don't really have enough different kind of work that it makes sense. Tyga also supports custom fields. So you can do things like, for example, in the magazine they set the preview URL which is just the link in WordPress where the article will be. So it's really easy to get to the article from the card and a cover image designer and an editor. And so these are fields that describe who's going to do things. I also tend to use a blocked by as in a URL. So if I have a card that's blocked by something else especially if it's blocked by something external to the Tyga instance like an internal service now ticket at Red Hat, I'll put that link in there just so that I know what it's blocked by and I can go back and check on it from time to time. Tyga also supports a field called Story Points which is, I don't think very useful in an open source context generally but if you're familiar with it in software development it's basically the idea of measuring the size of work based on some sort of criteria so basically the more Story Points you assign to a task, the more effort it takes or the larger scope it is. So you can assign users to a card. They have to be a member of a team and when we get into sort of how to administer a Tyga board I'll talk about that. But so you can see here the Fedora Magazine assigned an author, that's the person who's gonna work on the article and then they also assigned an editor once it's ready to be picked up by an editor. And that way it's just very clear who's supposed to be working on it but they also have watchers and so the idea of a watcher is that they're not necessarily acting on this card but they need to be informed by it. So for the Fedora Magazine there's a group that's just all of the editors and they get added as watchers to the card when the card is created. So that way all the editors can see when a card moves through and so they'll notice that the card has gone into to edit. They'll also see any comments that get made and so they'll know that author has a question or something gets stuck or whatever. You can add as many watchers as you want. I generally would suggest not adding people unless it's already agreed to by the team of who will be the watcher because it will generate email on basically every tick of activity. But if you have, you might want to set yourself as a watcher on cards as they get added just so that you are aware of what's going on or if there's a team leader or several people who are sort of team leads they might want to be watched. And also people can add themselves as watchers. So if the team is working on something websites related and there's a few people who are interested in the websites part of that team's work they can add themselves as a watcher and they can see what's going on. So it allows for some granularity in what notifications you get which is really important on an active board. So this board is one that I had used to basically track all the work and particularly the backlog of stuff that I was working on both Fedora-facing and internal to Red Hat-facing. But one of the things I've done is I've created epics for myself and these are sort of larger sets. And so some teams depending on their work like a Fedora Linux release might be an epic. So basically you assign the user story to this epic and that's sort of the umbrella for all the things that might happen in that release. I'm working on a book right now and the publisher has like four different milestones four different editorial reviews sort of checkpoints. And so from that I have each chapter as a user story each section in that chapter is a task under that user story, but then each milestone. So the three chapter review, the 50% milestone, 75% milestone and the final content they're each an epic and so I can add a user story to that epic and see you sort of plan out which chapters I want to have done by which milestones. And so like the current chapter can ban cards that epics also have state. So by default new ready in progress ready for test and done. So you can see like the closed epics. So I've had epics for different sort of things I was working on like Nest or when we were working with Lenovo to get stuff done things like that and then I marked those as done and then I have things that are in progress and you can see a progress bar of how many docs migration tasks user stories have been completed and how many are still outstanding. So I talked about swim lanes a little bit. So this is sort of a swim lane in action. So what I've done in this example is I've set up a default swim lane of unassigned and then a swim lane for Alice and a swim lane for Bob with different work in progress limits for each of those. And so as I move the card I can go from the different swim lanes. Now, like I said, you probably won't use them to separate on people but you might use it to separate on roles especially in like a larger team. For most of the teams within Fedora they're focused enough that swim lanes probably aren't going to be very helpful but they're there if you need them. So when you first log in to teams.FedoraProject.org you get basically a list of things that you're working on or watching and the projects that you are a member of. So if you click on manage projects it gives you a list because you have the opportunity to create a new project but you can go to, you know, whichever you can re-order how the projects appear. And so that'll show up in this dropdown menu as well. So if you wanna set what view you get when you first click on a project you go to your profile and click account settings and then go to set start pages. And so for each project that you're a member of it allows you to pick which page you're gonna start with. So that's sort of a convenience. For the ones that I actually interact with a lot I tend to just set the Kanban as the start page because I don't actually really care about the timeline. I'm mostly using it as a Kanban board so I wanna go directly to that. If you're working with a team that's also using it as an issue tracker or something else you might wanna change to a different view. But that is based on, that is a per user customization so I could change it for myself and not affect anyone else. So just because I have Fedora Magazine set to Kanban as my start page that doesn't mean that everyone else will. Somebody else would have to set it to Kanban for themselves. You can also customize your own notification so you can receive all notifications via email on a board even if you're not assigned as a watcher. By default it's only if you're involved and then you can also set no notifications which means you don't get email notifications but you can still, when you log in you'll see the bell with the number if you have unread notifications so it will show you what's going on and then you can dismiss them if you're done with them. So this is the part where we talk about administering a Tyga project. So you can have different users so you can see on this one I only have one right now but the user has to be added to the team and that means that you have to, they have to log in before you can add them. The way the login system works is the account gets created in Tyga the first time somebody logs in with their Fedora account. So if they've never logged in before you can't find them. And confusingly you can't add people to the team from the team view. You have to go into the settings and from the settings you go into members and then you can click on add a new member and you can either add them if they show up so you can search for them or you may have to just type in their email associated with the Fedora account and if they've already logged into Tyga then that email address will just automatically add them. So I'll just add Adam Shamalik to show it so you can choose a role. So by default there are different roles. You probably, when you're doing this for a team of Fedora want to customize those roles which I'll show you in a minute. So you choose a role and then you can invite the person and if they're already on they'll be added automatically. And then to remove, you can make somebody an admin by toggling the admin button and then of course you can change their role or you can remove them. Some notes about access control. So all of the boards are going to be publicly visible which means anybody who knows the URL can look at them can get to them without logging in. Now, one thing with the permissions if you want to make it so that anybody who's logged in can for example create a user story or comment on it you actually go to the external user and this very scary note that says by external user we mean any anonymous user not belonging to the Tyga platform including search engines. So it sounds very scary. Sounds like oh I don't wanna add permissions for that but because of the authentication plugin we use this basically limits it to anyone with a Fedora account. So unauthenticated users can't actually do anything here it's only, it's basically external to the team but still logging in with a Fedora account. So you can for example make it so that anyone can create an issue if you're using the issue tracker or anyone can comment on a user story. And so that makes it, so if the team that you're working with is using this to sort of interact with the rest of the Fedora community you can make it so that the community can actually directly interact there. I talked about roles so each of these roles is different. You can for example delete a role you can create a new role and then permissions. I think for most Fedora teams you probably don't need too many roles you know maybe like team member is probably enough so you can remove some of the roles and rename them just to simplify it a little bit. So like you might change people who are cool to people who are awesome. So you can easily rename them and things like that. So you go to like the project level basically various fields that you can set. You can set some of the default values. The interesting thing here is the module so you can add a Kanban board. You can add epics, you can add issues, you can add a wiki. The issues are somewhat useful probably but most teams will probably use Pagger or another issue tracker not the built-in one. The interesting thing about issues in Tyga is that you can actually promote them to user stories. So at one point a couple of years ago we were looking at changing the process for change proposals where basically it would be to submit a change proposal you open an issue and then to process it I would convert it to a user story and send it through the pipeline that way. Again you can also add a wiki. I would suggest generally the existing Fedora project wiki is probably a better place if you need wiki space and you can also add a built-in video conference system if you need to. The attributes section is where most of the interesting things happens so you can set statuses for your epics and your user stories and for tasks and for issues as well. I haven't bothered from most of the boards I work on changing the epic statuses just because it's fine. But the user stories are, this is where you wanna focus making sure you have reasonable columns. I showed the Fedora Magazine, Ken Van Ward, they recently changed some of the columns because it was sort of unclear. There was a, what does queue mean versus scheduled and then there was an archived after that and it felt like too many states and it wasn't clear. So it basically got rid of the archived one and made the combined to three columns down into two so it'd be a little more clear and understandable. So for me on the board I use I have a new which is basically a backlog of ideas that I haven't really necessarily fully fleshed out yet but I don't wanna lose track of. Ready is for things I could start working on today if I had time, I have a blocked and waiting and so that's usually it's depending on somebody else to do some work or some resource to become available. So I'll just put it there so it's very clear that it can progress as soon as the block is removed. And I have in progress for things that are in progress ready for test. I use that as sort of, if I'm writing a blog post for Matthew Miller for example, I'll move it to ready for test when I've given it to him and say please look this over if I'm submitting documentation or website changes I'll put it in ready for test when I've pushed the changes and then I'll move it to done once it actually builds and I've verified that it looks the way it's supposed to done is obviously it's done and I keep for myself done and archived separately because I like to sort of batch up my done over a week or two and then when I have my one-on-one meetings with my manager I can tell him oh here's some things I've done that are recent and then but when something's archived it's hidden by default so it's not easy to see. You can also of course set any status to be archived or done and you can customize the colors you can customize the names. This is the trick you wanna make sure here is that you need to save so each field you edit once and then save and then move to the next one and save just the way Tyga on the backend handles changes to the configuration. So if you go to the can band options under the attributes this is where you can set work in progress limits or create swim lanes. So basically the work in progress limit is you just set the number of user stories for that swim lane so you can or for that column and so basically you could set it on a per swim lane and per column basis. So I might not wanna have any for new or ready or for blocked but in progress and ready for test you might wanna have a limit just so you're making sure that work actually flows all the way through to the end and you're not doing a bunch of like half started things. You can also go to the tags to set the different labels. So you can see the bugzilla com blog conference council all these different things that I just sort of use as a visual as a sort of categorization to myself. It's not necessarily automatable or you don't really act upon it necessarily it's just some more of a visual and sort of mental queue. And of course there's the custom fields. So you can see I created the block by one type URL. You can set different kinds of types for any of the custom fields. Again, you have to save each one and so that's why we ended up not going with using Tyga as sort of the backend for the changes platform because it would have required the user to click save on every field. And I think we ended up with something like 15 custom fields because we wanted it to be very parsable by a computer. So we had each field one field for a link one field for a description. And there was too high of a risk of somebody not clicking save on each field as they went and losing the data. So I thought that would be a little user hostile. So that's one thing to be very careful of when you create custom fields is that if you get too many you're gonna increase your risk that somebody doesn't save it and then the data is lost. You can also set severities and priorities. I don't find them particularly useful for most open source projects just because the work tends to be sort of as you're available sort of thing. You can definitely use that to indicate if you're tracking certain bug fix kind of work that might be good to use those. And that way if somebody says, all right, well I can work on one of these three cards. Oh, this is the high priority one I should work on that first. I think generally people have a pretty good sense of the priority of the work anyway. So it's just sort of adds an additional layer of administrative overhead to maintaining the Taiga instance that you probably don't need. So one of the downsides of Taiga is that you can't just show a list of the user stories sort of as a list and not on the board. The closest thing is that there is a timeline view and this is the default when you click on a project and you can set that per project basis. But it basically just shows the most recent activity. Now with the issues themselves, if you enable the issues module, I believe that is you can get a list of issues. Again, I think most teams probably won't be using the issues module necessarily in Taiga, although it may just be that they would if they knew it existed.