 Welcome to the IRC meeting training for the Fedora program management team. So first I want to cover what you do before the meeting. The first thing you really need to do to run the meeting is to build an agenda and the reason you want to do that is it because, one, it gives participants a chance to prepare for the topics. So if there are proposals that you are going to share and discuss or there are bugs that need to be considered, it kind of a waste of people's time to open the link and first see it there while the meeting is going on. If people have a chance to look at it ahead of time and prepare their thoughts, you can have a much more effective meeting. But the other reason too is it lets people decide if they should attend or not and, you know, in an open-source community a lot of people are participating on a volunteer basis and even though they might really care about the work that's being done, they have to prioritize their time. And so if they look at the agenda and they say, oh, I don't actually have any input or I don't really care about the specific things to be discussed, they might go spend that hour and do it on something else. By the same token, if they have very strong opinions about something that's going to be discussed, they may say, okay, let me rearrange my schedule and I want to be at that meeting. So how do you build the agenda? A good way to do that is to review the action items and deferred topics from the previous meeting. This is sort of the old business category, right? Just, you know, following up on things that were supposed to be done or coming back to topics that you had to put off because you ran out of time or you needed more information or whatever. You can also go through the team's open tickets. Some teams like Fesco actively tag issues for meetings. So for change proposals, for example, if nobody is a minus one on it and the ticket is less than seven days old, it just it doesn't come up in the meeting because they assume they're going to go through it in the normal process. So it has to be explicitly tagged for meetings. For other things, like for the Fedora Council, usually when I put that agenda together, it's sort of a, all right, what's still open that we can actually talk about that's made some progress or that we need to remind me people to make progress on. But when you're building it, make sure you do list those things specifically. So if you're going to talk about open tickets, list the open tickets. You know, if it's talking about different bugs, like list the actual bugs you're going to be talking about, don't make people try and search or guess based on it because, again, you want people to be able to prepare and you want them to be able to decide if they're going to attend. And then, of course, you need to share the agenda because otherwise people won't be able to prepare or to know if they want to attend or not. So generally the easiest way to do that is if there's, if FedoCal sends a reminder reply to that email with here's the list of the tickets. Some groups don't have a FedoCal reminder set up or they prefer to prep the ticket before the reminder goes out or whatever. So in that case, you know, just posting to the mailing list or a forum sort of wherever the team normally communicates asynchronously is a good place to post it. You can also post to more broad mailing lists like the develop mailing list. I would suggest not doing that in most cases unless it really is targeted towards the whole audience because you do want to respect people's inboxes. And you really want to try for about 24 hours before the meeting, generally. Anything less than that and you sort of running the risk that people won't have time to look at it prior to the meeting. If you go too much beyond that, especially for things that are open tickets or open bugs, things may have changed by before between the time you put together the agenda and the time that the meeting actually rolls around. And then your agenda is out of date and it becomes less helpful. The next step, of course, is running the meeting. And this is where the bulk of this video we'll talk about. Generally, you want to have a sort of a flow to the meeting. As a very broad example, this sort of works. So you'll start off with a roll call to see who's here. Some teams may have rules about what defines a quorum. And so if there's a certain number of members present, then they can make decisions. Otherwise, they may cancel the meeting or they may just have discussion but not vote. If there are specific procedures or a purpose to the meeting, it's usually good to drop that. And as a reminder to people, people may not be familiar with the meeting. You have new people joining the team or people just may forget. Just a way to sort of remind people. The best way to do that, of course, is to drop a link to the dock. That way people can go look if they need to. You don't necessarily want to sit there and type out or copy paste several lines worth of explanation over and over again. Generally, doing announcements up front is good. If there are announcements for the team, that way you know you have time to get to them. Then cover the old business. So again, that's the action items from last time, things that were deferred, things are still ongoing. And then get to the new business. And then at the end, if there's still time, do an open floor. The important thing about open floor is you don't want to make decisions there. So if somebody brings up something on open floor, don't put it to a vote and settle it. And the reason for that is, again, because people can't necessarily participate in meetings generally or in a specific meeting, you really want to avoid making those quick last minute decisions when there hasn't been enough time for people to comment on it asynchronously and discuss it. Now, again, this is a general flow. Some teams have sort of adopted a different strategy that works for them. For example, in the prioritized bugs meeting and in the blocker review meetings, we actually start with the new business, the nominated bugs. Because following up on the old bugs is fine if we have time for it, but if not, we want to take care of sort of triaging the nominated bugs first. So in those meetings, we actually flip the old and new business. And so it's really what works well for thinking about the purpose of the meeting, but this is a good general flow. Now, to make life a little easier, we have a bot called Zodbot, which can do really cool things like take minutes for you and handle some of the topic changes and things like that. With Zodbot, there are a few commands that you can use. Basically, the idea is it sort of automates some of the workflow for you. To use Zodbot, you just need to be in any channel that Zodbot is running in. So it doesn't have to be in a meeting channel. In fact, some teams don't run their meetings in the Fedora meetings channel. The reason most teams do use a Fedora meeting channel is because a lot of people are lurking in there, and so a lot of times if you need help from somebody who isn't normally in your channel, you can ping them and they can join you. It's not really possible when you're running the meeting in your own channel, but you can do that and you can do it on an impromptu ad hoc basis. There's no scheduling it through FEDOCAL or anything. Once Zodbot sees that start meeting command, it's off to the races. To start a meeting, use the start meeting command, and you give it a name. So this is an example meeting, and sometimes you might put the date. So it starts the meeting, and then you might give it a meeting name. And the reason you might do that is, for example, with Fedora Council, we do the start meeting, and we do Fedora Council meeting and the date. And then the meeting name is just Council, and so that way it's easier to search when you go back and look through the search that I'll show you in a few minutes. So the next thing you can do is set chairs. The chair just has an additional level of access on who can, for example, start and stop the meeting. And this is really good to set, especially if you get disconnected or whatever, you might want somebody else to be able to end the meeting for you. So generally, for some teams it's they'll chair the entire team. Some people just chair a few people as they show up, sort of the experienced contributors, whatever. But usually you want to set at least one other chair. So I'll chair my other Nick, and you can do that at any point during the meeting. So if somebody comes in late and you want to add them as a chair, you can just type the chair command. You do it without arguments. It'll just tell you who the chairs are. The next thing you can do is do a topic. I said this is what we're talking about, and that sets the channel topic. And that will also show up in the minutes as a sort of divider. If you want, you can undo things with the undo command, and that will just undo the last command that you did. And you could go back basically to the beginning of the meeting. If it's possible to undo specific things that aren't the bottom of the stack, then I'm not sure how to do it. So generally, you know, everyone's going to have to undo like four things because I realized I made a fairly significant mistake a few lines back or whatever. But generally, you try and avoid doing that. In most cases, it's fine. You don't need to undo a lot unless you just completely got something wrong and you don't want it to be reflected in the minutes. So in this case, I decided to undo because I'm saying this is what we are talking about to avoid using a contraction. Then there's the info command. So this basically is just take this text and leave it in the minutes because it's something important. So I'm presenting an example meeting that's going to show up in the minutes. So you usually want to use this to highlight important things that you'd want somebody who's sort of looking at the summary to see. So you don't need to info every line because that would be rather cumbersome. But you know, if there are important updates like, you know, I filed the paperwork today or, you know, my computer is currently on fire. Those are things that you might put in info. You can also do a link and that will just show up as a link. So a lot of times we'll do that to a ticket or a bug and it sort of highlights what it is you're talking about. And then includes that link in the minutes. Zobot is usually pretty good about detecting the link. Especially if it's just a bare link is the only thing in the message and treating it like the link command. But it's generally good to be explicit about it. Another way to highlight things is with the agreed command. And so we can, that basically just shows what was agreed to. And so that's not always going to happen, especially if most like a voting mostly happens in tickets. But there might be cases where you want to use that and you would say, for example, agreed Fedora Linux is the best operating system. A lot of times what teams will do is they'll put proposed and then that text and then people will agree or disagree with that proposal. So sort of after a vote, you know, here's what the chair thinks the summary is. Is everyone good with this? Is the wording correct? And then actually put in the agreed once everyone has agreed to what they're agreeing to. You can call for help. This also shows up in the minutes. It also will send a ping into the commops channel. So one thing about the help command is if I happen to see that in meeting minutes, I will a lot of times put that in the weekly Fridays Fedora facts posted on the community blog just as a way to highlight that help is being asked for by somebody. We've discussed in the past, but maybe we should make that help command result in messages and more channels so it gets better visibility. But really it's a sort of a way to mark, you know, in the meeting, hey, this is a thing that we're looking for help with. And then of course there's action. So you put action the person and then usually say to do whatever. So action be caught and to give a demo of Zodbot. And then those action items will appear in the minutes. And then finally when you're done with the meeting, you and meeting and Zodbot will give you links to the minutes and to the log. So we'll take a look at that now. When the meeting ends, the meatbot.fedoraproject.org server has the logs. So this is the full text of everything that was said in the meeting. But you also get these handy minutes. And this is really the more useful part in most cases because this gives you the summary information. And so this is something where if somebody missed the meeting or they just want to keep up sort of at a high level of what's going on, they can look at that and get a quick view of what happened. And so you can see it includes the topics, the info, links, agreements, calls for help and action items. And then at the end it gets a list of the action items and then grouped by person. So now that you've run the meeting, it's time to do the follow-up activities. And that's generally just sharing the minutes. There is the meatbot.fedoraproject.org server that has all the logs and minutes. There's also a meeting minutes mailing list that every minutes get mailed to automatically. I don't think too many people subscribe to that. I do because it's really helpful for me to sort of keep track of what's going on around the project without having to sit in on every meeting. So a couple times a day I'll just go through that folder and I'll skim through the meeting minutes quickly to see if there's anything that stands out where I might be able to jump in and help or find people who can help with something or just sort of know what's going on in the project. So after you've shared the minutes, and again that's probably just going to be with the same place you shared the agenda, you want to make sure you go through and add or update issues for any action items or update bugs or things like that. It doesn't necessarily have to be you if you're running the meeting. You can have somebody else do that follow-up work as long as it's assigned and people know who's going to do it. Let's talk about meeting etiquette. The etiquette I present here is sort of a general guidance and teams may have their own customs and so you definitely want to sort of fit in with how different teams run their meetings. But in general, I find it's good to raise your hand, basically indicate that you want to talk, don't just start talking. Some people will type in lower case O and then a slash because it kind of looks like a head with a hand raised above it. Some people will just type a dot or just say, you know, they might say, I have something just something to let the chair know that you want to be called on and then wait for them to call on you. Because in IRC, you can't tell when someone is typing. It's very easy to talk over people and get a lot of diverging conversations. And so you really want to sort of take turns and then make sure that when you're done, you make it clear that you're done talking so the chair knows to call the next person or people know they can ask you questions, things like that. So, you know, EOF, if you're used to, you know, hear docs in bash scripts and things like that. That's a common, you know, sort of cultural phrase, but you can say that's it or I'm done or, you know, back to you Bob. Anything like that, just make it clear that you've said your your piece and you're handing the talking stick back. You do want to make sure you're being clear and what you're applying to again because the conversations can sometimes go past each other and there might be three different things that are kind of being actively discussed at once. So you want to make it clear if you're applying to a specific person or if you're applying to a specific idea. But at the same time, you do want to be brief. So you don't want to say repeat all of what somebody said and then make your comments. You know, the reason for being brief is largely because it takes you time to type and so the longer you spend typing the less time that people have to talk their piece. And, you know, IRC has a most clients limit the number of met the size of the message anyway. So you just want to make sure that, you know, you're saying what you want in as few words as possible. You know, so you don't be like, well, you know, I think probably what we should do is blah, you should say, I think we should do blah. You know, try and be more direct in your language. Now when you're running the meeting, the same sort of rules apply, but there are some extra tips. And again, you know, teams may have their own customs. I generally think you should do traffic control. So I talked about raising your hand. This is the chair version of that. You should, you know, call on people in turn. For me, I generally have a piece of paper where I'm writing down people who have indicated they want to talk. And, you know, this for me, this comes from years as doing doing amateur radio net control during severe weather operations. You know, you have to, you know, you go right now, you go and you go. When the meeting is smaller and more relaxed, you can be a little more relaxed in your rules. If the meeting gets bigger or the topic becomes more contentious, you may want to, you know, step in as a chair and be like, all right, we're going to take this in turn and just wait your turn. So that way the conversation can be followed. Another important thing to do is to pause between topic changes. I generally like to set a timer for 60 seconds and so say anything else on this topic, I'll start the timer and after 60 seconds, nobody has said anything. Then we'll move on to the next topic. And again, this is because typing takes time and people don't always just raise their hand and then do the message. They might just start typing right away or they may have already been typing something when you ask that. And so you just want to get people a chance to, you know, if they have more to add on a topic, give them the opportunity to do that before you move on. On the other hand, you do want to watch the clock. You know, most of the meetings tend to be scheduled for an hour and sometimes there's a meeting scheduled right afterwards. So you do want to clear the room before, so the next team can come in, but also you just want to, you know, be respectful of people's time. And so don't be afraid to move a topic along if, you know, you're kind of going in circles or if meeting is, if it's just not productive or if there's something else that you really need to get to and what you're talking about is maybe less important. And you also want to think about the minutes as you go. And so if you're running a meeting and basically the minutes just end up being a list of links with no other information. That's really not helpful to future you or to other members of the community who might be looking at the minutes. So you really want to try and use Zodbot during the meeting thinking about how the minutes will come out at the end. And so I wanted to highlight a couple of recent meetings that I thought were pretty good. So this is a cloud meeting. They start out with roll call. They review the action items. They had a new meeting time. Here's the issue for it. And then they agreed that they would move the meeting. They moved on to another topic that had some related links. They had some information about it and then an action item came from it. Again, another topic and just some information about that and so on. And they got to open floor. They created an action notice. There's no agreed or anything. And so it's just really informative and you can just sort of glance at it and see generally what the meeting was about. Similarly, the neuro fedora meeting recently, they start out with listing the agenda. And so, you know, it's a sort of informative meta content. Here's what we're going to do in this meeting. They go through it. They follow up on the last meetings, the information, you know, links to the last meeting. Information about what the action items were, whether they're done or not, new action items or carrying forward previous action items. Then going through the rest of the topics, coming up with action items about them, again, recording information. And so you can see this is a really thorough and useful summary of what happened in the meeting.