Rust Project Management pre-RFC

Summary

1. Create a new top-level Project Management Pilot Working Group, aka WG-PjM, with a strategic mandate to improve project management practices across the Rust Project through scoped, defined initiatives.This team will collaborate with and within existing teams and act as a central forum for discussion and information exchange about project management across the Project.
2. Significant governance reforms or product-focused work, such as designing a new subgroup structure or collecting user feedback, are explicitly out of scope from WG-PjM’s mandate.
3. WG-PjM will not own anything other than its own work. It will have no ability to make technical, prioritization, or process, or any other kind of decision—unless authority is delegated by another team.
   1. Exception: The “I Just Did It” Rule: WG-PjM members can still Just Do things that anybody can do.
   2. Exception: The “Does Anybody Mind?” Rule: If WG-PjM wants to do a process-related thing, and nobody is willing to claim ownership and say it’s allowed, but nobody minds, then WG-PjM is explicitly allowed to do the process-related thing.
4. WG-PjM is explicitly a pilot group. The working group will be reviewed six months after it is established. Its mandate will expire one year after it’s established unless it’s renewed or replaced with something else.

Motivation

“I mean honestly I don't even know what RFCs are open” —Niko Matsakis

The Rust Project suffers broadly from a wide variety of logistical and communications challenges. Most can be broken into :

• People have a hard time knowing what they can do to be effective.
  • I want to help out, where’s a good place to start?
  • What features are ready for stabilization?
  • Which RFCs are just waiting to be implemented, vs. have major unresolved questions?
  • What is the highest-priority work for a given team?
• Projects often get blocked for a long time.
  • One team needs input from another team, but the other team doesn’t know that.
  • One team puts a lot of work into something, but another team’s component of the project is much lower priority.
  • A new contributor needs help resolving a blocking issue but doesn’t know how to ask for it.
  • A team is overloaded with work, so much so that it can’t effectively onboard new people to help with the load.
  • Someone has a good idea on how to make something better, and while most people agree it will make things better, nobody is able to confidently say “yes, do it”, and/or to help flesh it out.. Eventually the person with the idea gets bored and forgets about it.
• Work often gets left unfinished.
  • Volunteers will naturally leave the project over time.
  • Volunteers are easily distracted by new work within the project.
  • Nobody is systematically following up on unfinished work.
  • Github notifications for most team members are out of control and become noise; the workload required to manage them is too high for the number of people.

Historically, efforts to solve these problems have usually fallen victim to them. Project management is not sexy in Rust. It’s ad hoc drudge work done by team members on the side.

Delegation is hard, as project management is often conflated with decision making. But, in a volunteer-driven environment, telling people “work on this now” simply doesn’t work. Project management is a support role. It requires enough technical acumen to understand what’s going on, but ultimately must defer to subject matter experts. Automate everything: make the good things easy and the bad things hard.

We want to break out of these patterns, and show people that there can be a Better Way. We want to celebrate fixing workflow papercuts, communicating progress/goals/challenges, and making everyone’s contributing experience just a little better.

Mandate

WG-PjM will have a strategic mandate to improve project management practices across the Rust Project through scoped, defined initiatives and by collaborating with and within existing teams and by acting as a central forum for discussion and information exchange about project management across the Project.

1. The mandate is strategic. WG-PjM is not intended to become a load-bearing component of individual teams’ project management. If we do this, then there is a high probability that we will end up stuck on steady state work from an early project, and never be able to move on to other work.
   
   WG-PjM may consider taking on steady-state work that cuts across many teams, such as managing a single unified process for many teams, but this would be dependent on volunteer engagement and care would need to be taken to protect the group’s strategic work.

2. The core of the mandate is to improve project management practices. Give a team a crab, and they will argue about it for a day. Teach a team how to make crab pots, and they will argue about the best design for the rest of their lives. Or something like that.
   
   A necessary corollary of this is that we will need to improve recruitment and volunteerism for project management. This will be part of our ongoing work managing the team itself.

3. The team will operate through scoped, defined initiatives rather than simply being a catch-all. We believe this is critical to protecting our precious volunteer effort and engagement. Volunteer motivation does not necessarily translate well from one piece of work to another. Project management work is often unsexy. And there is more of it than we could ever hope to do right now.

4. WG-PjM will collaborate with and within existing teams. We are not going to replace teams’ existing project management systems. We are not going to impose project management on teams. We would love to work with people already doing existing project management work within their teams and recognize them by giving them a shiny hat saying “member of WG-PjM”.

5. WG-PjM will also act as a central forum for people doing project management work, even if they aren’t working on anything specifically related to the group. We want to encourage people to share ideas and tips and tricks with each other, and foster a sense that project management is important to the community. We want to explicitly promote project management as Important and Cool. We will have the best karaoke at RustConf.

We don’t want to limit how WG-PjM will do things. For instance, even though the mandate will be focused on project management, we expect that building tooling to reduce workflow friction will be an important part of the work.

Structure

Alexis Hunt (@alercah) and Joshua Nelson (@jyn514) will serve as the Co-Leads. There is no formal process for decision-making in WG-PjM, because this is an experimental pilot, and we do not want process to get in the way of fixing process. For this reason, the Co-Leads are also called the Benevolent Dictators for Now, or BDFNs. While the BDFNs are responsible for working together collaboratively, quorum for decisions is 1.

The BDFNs will be expected to experiment with governance and process for the working group. In an ideal world, by the time the first review happens, the working group will already operate with a larger group making decisions, and the review can ratify it as the structure going forward. But the group should prioritize good initial results over self-governance, so this may not happen.

WG-PjM’s work will be organised into initiatives. Each initiative covers a single thing that WG-PjM is taking on. As a group, WG-PjM will not be responsible for work that falls outside the scope of an active initiative. Individual members are free to, and encouraged to, contribute improvements outside of initiatives. Initiatives have brief charters approved, and updated as needed, by the BDFNs, covering things such as:

1. The goals & scope of the initiative.
2. The proposed collaborating teams.
3. The initiative lead(s) and, if applicable, team members.
4. Brief details on what exactly the initiative will do.
5. Hand-off plans and/or the steady-state work expectations.

Initiatives represent the WG-PjM’s interest in a work only, and not other teams’. The initial work on an initiative might be to hash out details with a collaborating team.

In general, the creation of initiatives will be governed by the availability and interest of people to work on them. They don’t exist to gatekeep people who want to help with our work. They exist to inform teams who want us to do work for them, and also so that our work can be tracked. If someone is going to do a large project on their own, fitting in our mandate, we would rather call it an initiative so that it can be tracked, unless there are serious concerns that it might become a long-term responsibility of others who may not want it. Existing project management work within other teams will not be made into initiatives of WG-PjM, unless the team requests help with it.

Subject to usual moderation concerns, and the BDFNs’ dictatorial powers to change the rules later, membership in WG-PjM will be open to anyone who is actively involved in project management in any capacity in the Rust Project and who either is working on an active initiative or regularly contributes in conversation.

Time Limit

WG-PjM is an experimental pilot project. We want to try new things out. We want to move quickly. And we don’t want to build something that doesn’t work and get stuck with it.

So WG-PjM will be reviewed after six months. At the very least, the BDFNs will have to update this proposal to match reality, and then make the case that the experiment should be extended. At some point, there will likely come a proposal to make the group permanent, once it is working well.

And to ensure that the group does not become abandoned with nobody deciding to get rid of it, if no decision has been made by the end of one year, the group is automatically abandoned and dissolved. Poof!

Success Criteria

WG-PjM could hardly be expected to help other teams with their problems if they can’t keep their own house in order. So the BDFNs will be expected to project manage the WG-PjM’s own initiatives.

The experiment will be judged based on questions like these:

• Whether WG-PjM succeeded in its core mandate:
  • What tangible results came out of initiatives?
  • Were we able to get more people involved?
  • Did we get in the way anywhere?
  • Was WG-PjM able to project manage its own work?
• How much WG-PjM was able to keep its strategic focus:
  • Is WG-PjM the owner of any steady-state work, officially or unofficially?
  • Are there any commitments by other teams to take on ongoing work that weren’t fulfilled?
• How much WG-PjM was able to act as a central touchpoint:
  • Did we get people already doing project management work to start talking to each other?
  • Did we create resources other teams can refer to for project management?
  • Did we create enthusiasm about project management for Rust?
  • Did we have any problems collaborating with other teams?
  • Did we have the best karaoke night at RustConf?

Powers & Ownership

WG-PjM has no formal powers besides running its own stuff. Its success and failure will be determined entirely by whether it can collaborate with other teams. It will get a channel on zulip, probably #wg-pjm or #wg-project-management.

There are two exceptions.

The “I Just Did It” Rule: WG-PjM members can still Just Do things that anybody can do. This rule isn’t really an exception. It’s just emphasizing that the existence of a working group shouldn’t stop anyone from doing anything. If it gets in the way, that’s a problem.

The “Does Anybody Mind?” Rule: If WG-PjM wants to do a thing, and nobody is willing to claim ownership and say it’s allowed, but nobody minds, then WG-PjM is explicitly allowed to do the thing. This space has a lot of things without clear owners or forward progress, so we expect to regularly encounter situations where nobody is confident in saying yes, but nobody wants to say no either. We’d like to skip the part where several weeks go by before someone finally works up the courage to say yes, so we’re making it explicit.

Caveats for the “Does Anybody Mind?” Rule:

• This rule can only be used reasonably. Reasonable efforts must be made to query teams likely to care about things, and give a reasonable time, usually at least a week, for objections. And it doesn’t apply to things clearly outside WG-PjM’s mandate.
  • If someone objects after the fact, the situation will be considered on a case by case basis. But the WG-PjM, unless it acted unreasonably, is allowed to say “It has been approved, sorry you missed your chance.” in the same way that other teams can.
• Objections can’t be purely on process grounds, such as saying “I’m not comfortable with the WG-PjM making this decision”, without pointing to someone else who can make the decision and who agrees that they should be the one making it.
  • If there’s a general consensus that a proposed change is big enough to require an RFC process, or something along those lines, that will be respected, but the rule could still be invoked to let WG-PjM approve the RFC if there aren’t other approvers.

Initial Initiatives

The initial initiatives will be:

1. The Initiative Initiative. This is the meta-initiative for tracking WG-PjM’s own work.
2. The RFC Tracking Initiative. This will be a collaboration, primarily with the lang team, but possibly with other teams involved in implementing RFCs, to track all open RFCs. We want to provide critical information about RFCs at a glance, so that project members and observers can quickly get answers to questions like “What’s the status of this RFC?”, “How many open RFCs are there?”, “What’s the status of this RFC?”, “How many RFCs are blocked on Chalk?”, and of course the perennial favourite, “What’s the status of this RFC?”.
3. The Onboarding Initiative. This will be a series of work to make it easier for new contributors to start working on the project. Some example goals include improving documentation, making it easier to find issues to work on, and making the process for joining teams and reviewing code more clear.

FAQ

Q: You’re hardly proposing a lot of real work. Why make a whole working group right now, instead of starting small?

A: Primarily visibility and culture shift. The Rust Project is full of project management initiatives, sometimes entire subteams of them. There’s the Prioritization Working Group under the Compiler Team and the Triage Working Group under the Release Team, which are fairly visible, but the project management work that each of the devtools subteams do to manage their own workload is not very visible at all.

Past efforts to start a new project management initiative from scratch have mostly fizzled, so it seems counterintuitive to start with a new working group to solve that. But while those sorts of plans fail to build momentum, probably in part due to the friction of the existing work being done by teams, we intend to leverage the momentum that’s already there by inviting everyone working on project management to come hang out and talk about things. We can’t do that with another disconnected initiative. We need a home.

More importantly, whatever we come up with needs to last. If we want to make significant, lasting changes to the Project, we need more people. We need to figure out how to get more folks involved in project management. And we know that this is a big enough problem for Rust that it warrants being in the places where it will get the most attention: the “Official” section of This Week in Rust, the official blog, the Governance page. We want people to know that the Rust Project needs their help.

Q: Why a top-level group? There’s no process for that. Why not just nest as a subteam under Lang or another team?

Our long-term goal is a team that cuts across all the existing teams. A working group from all subteams, and from none. The only real reason not to start there is because there’s no good process for it, but that should not be allowed to be an obstacle.

If it ends up being needed then we could be nested. But that would imply some relationship that isn’t really supposed to be there. Would we be expected to focus most on initiatives that help our parent team? To report to them and be accountable to them? Well, no, obviously, but people might think that, or get confused, and that will make it harder to sell a convincing story.

For example, putting it under lang team would make it look like “lang team needs help with project management” and not “Rust needs help with project management”.

Q: Why put a time limit on it? If it’s so good, shouldn’t it be forever?

Yes, it should. But history tells us these kinds of projects usually fail, and while we are going to try hard not to share that fate, an exit plan is a good idea. And this way we can answer a bunch of questions with “This is just an experimental prototype, we want to move quickly, and it doesn’t really matter since it’s temporary anyway.”

Q: Are you planning other initiatives besides RFC Tracking and patting yourselves on the back?

We have a number of ideas, but we don’t know what the volunteer uptake is going to be like. So we’re going to limit our scope to what we know we can focus on. Much better than trying to do everything, getting spread too thin, and getting nothing done.

Q: Why haven’t you described the group’s processes in more detail? Why do the BDFNs have so much power?

This is just an experimental prototype, we want to move quickly, and it doesn’t really matter since it’s temporary anyway.

Q: You said this group will have no power, but the “Does Anybody Mind” rule is real power, isn’t it?

Yes, but does anybody mind?

Q: What if none of the teams like your ideas and they don’t want to work with you?

That will be very useful data for our experiment!

Q: How can we be sure that this isn’t going to make things worse?

This is just an experi—oh wait, that doesn’t work here.

We can’t, obviously. But we’re going to tread carefully and work in collaboration with other teams. We don’t, and can’t, impose anything. So hopefully other teams will defend the parts of their process that work well.

Q: Can we call it WG-Pyjamas?

If you like, but we might show up to karaoke wearing pyjamas. You’ve been warned.