 All right, good morning, everyone. Thanks for sticking around for Sunday and coming to this talk. I realize I've been talking to people this week. I wanted to make it clear that this is herding cats as in like getting them to go and not like herding cats. I want to make sure that's clear to everyone. I'm Ben Cotton. I'm the Fedora program manager at Red Hat. So this is basically my job in 25 minutes. This is real quick housekeeping stuff. If you want to talk about me or my talk on Twitter, there's my handle for nice things, for not nice things. You can keep them to yourself. Nobody's going to be harder on me than I am. Don't worry. So what is project management? That's a question that you might want to ask as you're going into this talk. I want to be technically correct for a moment. And I know this audience really appreciates precision. The Project Management Institute says a project has sort of like a defined beginning and end. It's a thing you do and then you move on. So really, the word we should be using here is program, which is a collection of projects that move towards some sort of goal and an ongoing thing. But in the community, everyone talks about projects, like the Fedora project, for example. So I'm going to use the word project here to sort of follow what the community does, but know that if you're in program or project management, really what I mean is program. So what does it mean? Well, the Project Management Institute has a nice definition that says the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. And I looked at that and I said, what in the hell does that mean? There's no explanation of it, right? So I was sitting there, I thought about it, and I said, OK, it's basically just working with project teams to balance these constraints. And in project management, we have this what's called the iron triangle sometimes. Basically, you have time, cost, and scope. And when you adjust any of those, it affects the other two. So you imagine you have some sort of string with three anchor points, you move one of the anchor points. Triangle takes a different shape. And then more enlightened people also think about quality. So that adds a fourth dimension. And so now you've got this weird string thing that you're trying to do with your hands and whatever. But yeah, that's what it is, right? It's just trying to get everyone moving in the same direction to fit in whatever shape box you've defined. This guy, I know, said everyone does project management. Just some just do it poorly, right? Because no matter what you're doing, whether you're thinking about it or not, you have these constraints on everything you do. And you try to balance them. You try to manage it. On my team's internal blog at Red Hat, one of my colleagues recently wrote a post about how she used program management to help get her teenage son to do certain things that she wanted him to do. So it applies everywhere. So let's look at the different aspects of it. So the first is time. What? That's a thing. So basically what that means is managing schedules. Now managing schedules doesn't necessarily mean setting the schedule. In my role, the schedule is really sort of set by the Fedora Engineering Steering Committee, or FESCO, and the Fedora Project Leader, and other people who have input. And so basically they say, we want to get a release out here. And we need to do these things in order to do that. And so then my job is to say, OK, well, given that, we need to start doing things here. And this deadline needs to be here and here and so on. So I don't really set the schedule so much as I just turn it into something that people can look at. And managing schedules, very importantly, does not mean being held responsible for the execution of the schedule. I don't remember if it was during my interview or shortly after I joined, but my manager was very clear. If Fedora doesn't ship on time, you don't get fired for it. And even in a more structured environment, things happen, right? So really it's about setting the schedule so people can see it and then keeping it in alignment with reality. As things change, update the schedule so everyone knows what that means. So like I was saying, managing the schedules is building it, communicating it, updating it, and then consulting people on schedule related decisions. Like, yes, we can do this thing, but the trade-off is going to be all your volunteers need to work 25 hours a day to get the project done. Maybe that's how your project wants to work. That's fine, but don't expect me to volunteer. So then, what if we don't do schedule-based releases? Some projects like to say, yeah, we're going to add these features. Whatever they're done, we'll release it. Or it's just kind of a, it feels like it's time. Slackware is a good example of, yeah, I feel like it's about time to put out a release. We've been doing this for six years, and it's good now. And that's fine. This means doing project management in that project looks a little different. But you still need to know how long this work is going to take. So if you say, we're going to do features A, B, and C before we do the release, well, how long does that take? Because as you get close to being done, you're going to want to do things like promote your new release. You might have some artwork you need to do, write blog posts, go do interviews with tech press, or just let your user base know about it. So you still want to have some idea of when things are going to happen, and again, bring it back to reality. So cost. Community projects don't necessarily have a dollar cost. Some projects have some sort of corporate sponsor, and they get a lot of money, and they get to do stuff with that, and that's great. Most projects are like a couple of people doing a thing for a few months, and then getting bored and moving on to something else. So they don't necessarily have dollar costs. They have volunteer labor. They have donated hardware, or they're using free GitHub accounts, or something like that. But the people still have time costs, because even if you're not paying them, they have a finite amount of time, and they're choosing to give some of that to your project. So you still need to sort of manage the cost of how much of people's time is it going to take to do this thing? How much, you know, what are we asking of our community? But you don't actually have control of that. You can't say, hey, you need to go do this thing that you really don't enjoy. Volunteer community-driven projects don't work that way, and sometimes you get contributors who will do the things they really hate to do because they recognize that it's important and valuable to the project, but that's not a good strategy for long-term community engagement. So really, project management in this sense for community projects is helping people coordinate. It's connecting people and being aware, and they're like, oh, you're doing this. Well, they're doing that. Maybe you should talk to each other before you two break each other's code, or hey, you're working on this big thing that you want in the release, and the leader is over here saying, we're gonna get the release out in three days. Maybe we should figure out what's going on here. Scope, kind of been leading into this a little bit. If you didn't see my talk on Friday, get your time machine, go back. I spent an hour talking about how to get technical changes through a project, and there's all kinds of different ways you can do that. The condensed version is you want to have some way to get technical changes proposed and approved by your community before you implement them. And so part of a project management role in that sense is helping people through that process because it's not necessarily a process that they go through a lot. People don't like process and bureaucracy, so it helps make their life a little easier. And then of course you want to follow up on the changes to make sure that they're still on track. If you're planning on doing a release, and you're preparing to say, we're gonna have these features, and feature C is not even close to being done, you'll want to know that ahead of time so you don't start messaging that too much because then people will be really upset they expected feature C to be in the next release and it's not, and then people on slash dot say your project is terrible and it's awful and nobody should ever use it. And then quality, it's not really your job as the project manager, but again, it's the way you provide input. So for example, you might coordinate the go-no-go meetings like are we ready to release? And for Fedora, that's kind of a process because there's a lot of inputs. Other projects are much smaller and I have a command line Twitter client that I'm basically the sole developer on and the release process is, I feel like saying get tag right now and then pushing that and that's the release. There's a scale in a continuum. You might conduct blocker bug evaluations so you say, all right, we cannot ship until this bug is fixed because it is so bad that either this plane won't work or people will really hate us and not want to use version N plus one. And I don't want to take credit for this because in Fedora, Adam Williamson and the QA team do this and they do it incredibly well and I am not about to go in and take it over unless Adam says I'm tired of running these meetings. Okay, okay, great. But by the same token, I'm still in those meetings because it's very important for me to know about what's going on and so when people ask, I can say yeah, by the way, we should just go ahead and plan on the release not happening this week. And also it's a chance for me to jump in as a community member and offer opinions and there's nothing I love in this world more than having opinions about things. We also have a prioritized bug process which is different than blocker bugs. These are things that are sort of generally more polished things that just kind of make us look bad if they don't get fixed and we really want to use that as a signal to the community that gosh, we should fix this so it improves the user experience kind of thing so people don't ding us when the new release comes out and this thing doesn't work as smoothly as people want. And it's not necessarily so much a matter of, well, now it's a priority so everyone else drops things and it works on it. It's just kind of a signal that, hey, as community leadership, we think this is important. If you're in the Fedora community, I really encourage you to come to these every other week because usually just me and Matthew Miller are the project leader and we just debate among ourselves and make the decisions. It would be great to have more people give input on that. All right, so we've talked about what project management is, so how do you do it? I stole the slide from Friday's talk. Communicate, communicate, communicate. That is the entire job of a project manager is to take the inputs of knowledge from other people about what they're doing, synthesize it and then push it back out to other people. If you're not taking the knowledge in and sending the knowledge back out, you're not adding any value and you're probably just wasting everyone's time. So how do I do that? Well, I spend a lot of time sitting in on meetings and reading mailing lists and I don't attend every Fedora meeting because oh my gosh, there are like 100 meetings a week or something in FreeNode and some of them are like during the middle of the night and I don't love my job that much. But I spend a lot of time trying to keep up on the mailing list for even things that aren't directly super critical to the project and aren't things that I'm specifically interested in because it's really important that I at least have sort of a sense of what the sentiment is within the community. Are people talking about this new feature they're working on, they're really excited that it's gonna be great? Are they talking about this thing they're working on and they're pretty scared that it's either not gonna be done in time or it's gonna be super buggy and everyone's gonna hate them? Those are sort of good things to just kind of pick up on and have a sense of. It's also key to know, oh, nobody's been, there's been no discussion on this mailing list for like three months. Maybe that part of the project is just kind of dead and that might be something we wanna be aware of. So a lot of it's just taking things in and even if I don't necessarily remember all the specifics of what I'm seeing it just builds sort of a general sense in my mind of where the community is. And then take all that, feed it into different reports and schedule updates and stuff and then give that back to the community. So one of the things I do is I have, every Friday I publish a blog post on our community blog. It's just like, hey, here's what happened this week. Here's the changes that were submitted and here's what Fesco has decided. As we get closer, it's like here's the status of changes that are complete and incomplete and ones that are probably gonna have to get pulled out because Fesco's gonna say you need to be done before we ship in order to get your code in. Like that's kind of how it works. And it's sort of upcoming important meetings like the Blockerbug meetings, the Council meetings, things like that. So people don't have to go hunting for all the information. I have IRC office hours that much like a college professor's office hours nobody actually comes to. But I'm there, I sit at my desk and I drink my coffee and I just kind of watch the channel and see if anyone shows up. And it's a way for me to be available to the community if they have questions or comments or concerns about some of the program management processes within Fedora. And if they come ask me questions and we talk, that's great. If not, then the IOT meeting is at the same time. So I'm also reading that. And the great thing about IRC meetings is you can be in like three or four of them at once and nobody knows. That's also the disadvantage of IRC meetings, by the way. And then one thing I don't really do well yet that we're working on both me personally and the Fedora Council at large and trying to spread that out to the community. It's having more public issue trackers or cam-band boards. It's something where I want the community to be able to find out what I know without ever having to come ask me. And it's not that I don't want to talk to people but I'm only available during certain chunks of the day and sometimes I like to go on vacation or I just feel sick or I just don't want to talk to anyone. And so having that available means people can just look and be like, oh, yes, here's where all the changes are. Here's what the schedule looks like. Here's what's going on. Here's the different processes that are in play. So, you know, openness and transparency and discoverability is huge. I think the discoverability part is the thing we as open source communities usually don't do well. We can be very transparent with publishing things but you have to know where to find them. So, we've been already talking about community projects but how is project management different from like corporate environments to community projects? Who in here is a project or program manager in a corporate sense, anyone? Okay, raise your hand Yaroslav, I know what you do. Okay, so we have a few. So, you know, it's not quite the same. As far as I know within Red Hat's program management team, I'm the only person who's like directly in communities. Everyone else is working more on the Red Hat products. So, even some of my coworkers don't always quite understand what's different about what I do. So, like in companies, people just don't like process and bureaucracy, it's not fun, it's not exciting, nobody opens up their laptop and says, boy, I was really gonna write some code and have fun but first I wanna fill out this paperwork. That's not a thing people do. In companies, you may or may not have direct authority and in open source projects you almost never do. And even in companies, a lot of times it's, you don't get to tell people what to do, you get to tell their manager, hey, so and so is not doing their thing, can you please like go yell at them or something? But in any sense, project management is still all about communication and coordination. It's really about being that conduit of information and being able to synthesize information from different people and publish it in a way that serves the community. But in communities, you can only lead by influence. And that's kind of a lie a little bit in the sense that in Fedora, because there are some people within Red Hat who are paid to contribute to it, sometimes for certain things, we can go to somebody's manager and say, look, this person promised us they were gonna fix this thing like three months ago and they haven't, can you talk to them? Is there something going on or we just need to assume that it's not gonna happen? Things like that. But mostly, it's your personal charm and ability to influence people that is the only way you can actually get them to do what you think they should be doing. And it does take time to build that credibility, right? I mean, you can't just show up in a project to day one like, hey, I'm the new project manager, you need to do what I say. That doesn't work. For me, I was a Fedora contributor for about nine years before I got hired into this role. Just as a member of the community. But I was sort of on the edges of a lot of stuff and I was never really like a big, like most people probably didn't know my name. So when I started the job, I didn't, again, it was, I can't just come in and be like, we're doing this, this, this and this and you need to come along with it. It was only very recently, somebody sent a change proposal in. It was after the deadline. I was like, I'm gonna go ahead and process it because I feel like it's kind of an important thing. And some of the discussion, people are like, well, we should go ahead and accept it because they've already put it into Fedora Rahide and like that's the wrong answer. We should accept it because it's important, not because they screwed up the process and it's really important to not screw up the process because this is how people know what's happening. And as I, after I sent that email, which is a little more verbosely worded, but I realized, wow, it's taken me seven months to get to the point where I just feel comfortable saying no, that's the wrong way to do it. And I was right and that was the wrong way to do it. But if it had been a week into my job, I would not have felt comfortable saying that because I had to establish a little bit of credibility in the community first, which hopefully I've done. They've seen that there's value in what I do. And of course I had predecessors who have shown value to the community. So they understand that this role does important things. But even though they might understand the role of those important things, they still don't know me and they need to get to know me first. So I use this in the change process talk and it's always nice to reuse some of your work. I think the guiding principle for project management, especially in open source communities where you have volunteer contributors who can just get up and walk away at any point in their life because they don't need you to put food on the table. The process is here to serve the community. The community is not here to serve the process. And the only way you're gonna get project management to work in a volunteer community is if people see the value. They have to understand that even if this particular thing that they're doing is kind of annoying, not doing it is worse, right? This is a good thing for our community and for me as the contributor. And with that, that's all I've got for you. And we have about five minutes left for questions. Brian, so the question was for purely volunteer communities, what elements would I say are the most important because you don't have a 40 hour a week project manager? I would answer that with a non-answer and say it depends on what your project is doing and what your project needs. Definitely I think the schedule management is a big one because that helps not only your developers and your contributors, but it's useful to your, if you have downstream projects or just your user community to have a sense of here's what's coming and when, so they can plan. Especially for downstream developers, they might want to release close to you and so if there are certain API changes or something that they need to be aware of, it's good to have that be public. I would also say that you could potentially take four or five people and cobble together something approaching a full time. I would give each person a different part of the task. I don't know that there are a ton of people out there who are involved in open source that are super excited to do project management work. On the other hand, maybe that's an area of recruitment that communities can undertake where yeah, we've got a lot of developers and there's people trying to reach out and get some marketing people, get some designers to do some of the artwork and stuff. Why not try and find people who are project managers who might want to contribute in some way? So that's a way you can address that. Can you expand on that a little bit? I'm not sure what you're asking. Okay, so the question is, does this apply to people who just, I've got this one thing I really need, I want to fix because it's gonna make my life better. So you're asking, does my answer to the previous question, yeah, I'd say so. One of the great things and one of the challenges about open source projects in general is the drive by contributor. People who want to come in, make one contribution and then move on. I think the ideal situation is you can take those people and trick them into being long-term contributors. Doesn't always work. But I think if you have, again, it's specific to your project. If you have the project set up in a way that people can come make drive by contributions, I think that sort of explicitly recruiting them is helpful. If it takes three weeks to figure out how the code gets developed and committed and tested and all that, then it doesn't really matter if you try and recruit those people or not because they're not gonna be able to do it. We have time for one quick question. Or zero quick questions, that's also good. Okay, thank you everyone. Oh, the question is, I talked about having the public issue trackers and things like that as part of the job to go to other teams within the project and say, or other projects and say, hey, you're not public enough. And I would say, absolutely, the answer is yes. Specifically within Fedora, that's one of the things that the council is trying to work on is making it more visible. We have a lot of different sub-teams and special interest groups that sort of come and go and it's not always easy to find them. The Wiki pages are out of date and maybe they don't even exist or whatever. So we're trying, that's one of the things we're working on this year is really trying to make it more visible to newcomers say, oh, I'm interested in the KDE environment. So I'm gonna go talk to these people. Here's where they communicate, here's their trackers, things like that. It's a hard problem to fix in a large environment, but it's definitely an important part of it. All right, thank you everyone.