[From rustNL 2024](https://hackmd.io/@jdonszelmann/Hyzn9M5fC)

# Project Management

## Problems

- Teams aren't aware of what other teams are doing
- Very easy to stall something by having 2 teams involved in something. Coordination across team meetings is hard. Neither team can make progess in their *own* meeting until a few rounds of back-and-forth.
- Every team uses their own process, hard to work across teams
- We suck at onboarding
- Many processes for getting forward progress on something are "ask your friends / the people you know"
- Nobody is responsible for deciding "this is important", and communicating that to the rest of the project, and getting consensus on that, and prioritizing things accordingly
- Few teams actually have goals
- "What are you planning for this year?" "Trying not to drown."
- When someone does visibly drive a goal forward, it's appealing for others to try to shoehorn their problems/goals into that, turning it into an amalgam that can't get done.
- Companies want to support specific features, not maintenance work/moderation/project mangagement
- Project is built from the bottom up
- Sometimes a team makes a decision nominally on behalf of the project, trying to accomplish something, and it ends up happening but wasn't exactly consensus.
- People who try to seek project consensus don't get things done (because we have no clear processes to get project consensus), whereas people who just use soft power and charisma will (sometimes) get things accomplished (because they ignore the lack of process and consensus). This is not a good set of incentives!
- We never put old work aside to do new initiatives:
- We're always drawing from the same limited pool of resources.
- Bad at both increasing leadership pool, and bad at dropping old work
- Donors don't understand the way the rust project works, and they don't understand the value.
- They don't want to throw money into the rust project, because who knows where it goes and it's not clearly connected to accomplishing their goals
- So instead it goes in through other means (or not at all)
- No-ones communicating what we did recently.
- The project has no (functional) front door, only back doors. Organizations / companies hire project members who know how to navigate the chaos and operate in a process vacuum and still get things done.
- If bevy want variadics they can't submit an RFC, they need to go to conferences and make friends who know how to get variadics through.
- There's enough negative in the project organization that it's contemplatable to fork the whole thing and change it, even though you'd lose so much good along with the bad. This shouldn't be something we're even close to considering!
- Users who'd be interested in contributing to the projects are put off by the fact that it's very visiably a mess.
- If there were a front door, we could see it publicly and review submissions publicly, without any concern about hidden agendas. Because people operate through process vacuum there's less oversight.
- "Graduating" from organization to development work - we need people doing organization who are not looking to "graduate" to something "better" or more glamorous
- GitHub comments are a terrible mechanism for discussion.
- Poor ability to attract/retain people who are good at management work.
- People are invited to teams based on visibility and knowing people at to invite them.

## Possible solutions

- Make sure that people who are doing work are writing about it in a public place
- A culture of showing what you're doing
- There's a lot of information, though. Need to get it in a form that people can digest without following *everything*.
- This shouldn't be a "reporting" style, don't want to do "flooding"
- This should be "journalism" - Someone to talk to the people doing the work, write it up in a legible fashion to other teams and people funding Rust and the broader Rust community.
- Project goals have owners, owners are supposed to communicate status and regular updates
- Grants have a concept of "overhead" taken out for administrative work. Should we have a standardized mechanism and policy for using a cut of money given to the project (branded in a better way) to use for organization?
- Can we get the infra people to get GitHub to not hide all the comments on GitHub?
-
- The Rust Newspaper? / TWiR?
- LWN is a cool model here.
- A spotlight to focus on someone specific
- Quality over quantity
-
- Hire a person to help. Doing what?

### A full-time person thoughts

- Embed in one of the teams and work on pushing features towards stabilization
- So painful to keep track of what need to be done
- Keep track of a small number of features.
- Because we can tie hiring to concrete stabilization, this is visiable to funders.
- Should also be cross-team
- Future-compatibility warnings

Two different problems:
- What's the most important thing the project needs?
- How easily can we "sell" that or make it visible enough to fund and be seen as valuable?

Work on ensuring we don't regress/break backcompat isn't visible at all. Hightly valuable, but not super legible to stakeholders.

Can we hire someone to think about how to do project mangement?

A practical tension:
- We can't hire someone whose job is so narrow that we'd need a hundred people to solve all the different problems
- We can't hire someone and expect them to do All The Things

Hire someone to manage the editions. (TPM)
- This role can then expand over time to solve the very similar recurring problems that aren't tied to an edition.

Question of trust:
- The people we trust are busy with other things
- The people we'd hire from outside aren't instantly trusted

Don't have candidates within the project, as all the current people are super busy
- Should fund TC's work though. It's important, but not this.
- Need to ensure culture fit, opensource PM stuff is super different.

How do we give this person feedback?
- They might not get it right on the first try, but that doesn't mean they're out. Maybe they cannot be *expected* to get it right on the first try. nobody can.

Bec/Foundation doesn't want to hire someone unless they can know what will make someone sucessfull in there roll.

There will be 200 people giving conflicting feedback on the PM and what they should be doing and how they should be doing it". How to disambiguate?

A person who asks you once in a while "how are you doing", it's OK if you're *not* doing OK, can help get you out of a review queue or help get things off your plate, but it should be someone's job.

Observe things in many different teams
- See where there may be process gaps, suggest solutions for those gaps
- Might be a toxic contributor, you can observe this by the fallout around them

We can hold people responsible for the things they said they'd be responsible for
- They can still have something come up that means they can't be responsible for it anymore (but that then needs to be known)

Tendency that people who want to fix this come in and try to make big changes. Maybe we should start with small incremental things like pushing triage forward, as opposed to massive governance reforms.

The first hire needs to be the most skilled, most versatile, most willing to be thrown into the deep end. Once we have one, we can potentially hire the next role much more easily.
- "nucleation" around the first person in the role. Second/subsequent people can get help/advice navigating, can see how the role works and how it's respected...
- Bevy has a load of budding project mangers because Alice has shown it's a role that can exist and thrive there.

Branding is important - "Project Manager"/"Program Manager" has baggage from people's past bad experiences
- Facilitator
- Edition Crustacean
- Edition Shepherd
- Crustacean Connector

Different role, council staff person/team
- Operations Architect ([fedora](https://docs.fedoraproject.org/en-US/council/foa/))
- Chief of Staff, which hopefully gets additional staff to be a chief of
- This role needs to have enough status to appeal to the people working on it
- Can't *just* be the execution without any of the ownership
- Could give a person the actual ownership of designing the solution *and* executing on it

Different different role:
- Head of design, CTO, etc

Experience from other teams:
- Single points of decision-making for a project has been a failure
- There are benefits to having it; "I speak for the project" is really powerful
- There are risks here
- It's not clear that project spokesperson is project director

## Misc notes

Why hasn't this happened yet?

- The desire to make big changes sucks the desire out of the room to make small changes
- e.g. trying to fix governance took up all the energy that would have been used for other things