Allocate budget to Edition/Project Goals teams in support of program management

[traviscross]

With the anticipated chartering of teams for the edition and for project goals, and with the ongoing successful collaboration between teams in our project and community customers of Rust such as Rust for Linux, the Safety-Critical Initiative, and the C/C++ Interoperability Initiative, our project suddenly has a meaningful amount of program/project/product management work to do (henceforth called program management).

While we have highly-capable volunteer contributors who have proven the value of this work and have developed extensive processes and standards for it, the day to day execution of this work could be usefully delegated.

We have a budget that's been entrusted to the council to invest in support of the Rust Project. We propose that a meaningful part of this budget be allocated to the edition and project goals teams to support that work, and, at the joint discretion of those leads, the hiring of one or more associate program managers to work at their discretion.

We suggest a budget of 200k USD for the remainder of 2025. We would delegate all the details and the responsibility for follow-up action, including coordination with the Foundation, jointly to T-edition and T-project-goals.

It's hoped and anticipated that the success of this work will lead to further support of this work by the Foundation, either directly or by helping to justify continued support for the project's budget, and interest by financial sponsors of the Foundation in making contributions to support this work.

See also:

• Chartering the Edition Team #149
• Chartering the Project Goals Team #150

cc @nikomatsakis @ehuss @rust-lang/leadership-council

[nikomatsakis]

I can attest to the value of this.

[traviscross]

We discussed this briefly in the council meeting today. People saw value in the work, and also had some questions and wanted some time to process those and to review this -- admittedly substantial -- ask with the teams that they represent. We'll leave this nominated to discuss again.

One particular question that came up related to the program management of items such as Rust for Linux, the Safety-Critical Initiative, the C/C++ Interoperability Initiative, the various security initiatives, etc. Some of these initiatives are separately funded, and we discussed whether our expectation is that such separate funding should also cover the program management of these.

The answer is that I may have erred by bringing these examples up, though they fall within the domain of project goals, as these are not the main focus here. The purpose in mentioning them is simply to highlight some specific and visible ways that explicit program management has been valuable to the project. In that set, I'd particularly highlight the work with Rust for Linux. For a large number of developers, the first interaction they will have with Rust is going to be working on the Linux kernel, and so we have a shared interest with the RfL team in working to make that a good experience. That work is not separately funded, and the not-insubstantial program management for it has been falling on volunteer contributors.

That aside, I agree that where there is funding for such initiatives, that it's a reasonable expectation that part of such funding be directed to cover program management expenses. To that end, what I mention about seeing this as a step in encouraging further financial support for this kind of work applies.

In particular, I think, it's important to demonstrate that we can manage this kind of work within the project. And, too, I believe it's important that we do manage this kind of work within the project so that we're able to best direct the outcomes toward our actual priorities and direct the processes and behaviors to best support our contributors and our expectations about how work is done here.

The main focus of this proposal, though, is the routine general ongoing program management work across a wide range of items required to ship editions successfully and to make project goals an ongoing success.

[oli-obk]

That work is not separately funded, and the not-insubstantial program management for it has been falling on volunteer contributors.

Aren't most of the rfl folk employed at major corporations? Specifically ones who do not have employees that do reviews

[traviscross]

Aren't most of the rfl folk employed at major corporations? Specifically ones who do not have employees that do reviews

Actually, I don't know. But in any case, we're not engaging with them for the benefit of those people, their employers, or even their project. We're doing it in the interests of our own project. There is a large group of developers for whom their first experience with Rust is going to be via working on the Linux kernel. We want that experience to be a good one and one that demonstrates our key values like stability.

The Linux kernel adopting Rust is a huge and very public win for us as a project. It's already influencing other significant organizations to commit to Rust. We want that adoption of Rust to go well. If it doesn't, and Linus decides to pull it all out, that will equally be a very public failure for us.

The Rust for Linux project is a customer of our project. They're a community customer, but still a customer. As we're both open source projects, the lines are fuzzy, of course, and many of their contributors do make direct valuable contributors to our project too, but it's still worth I think keeping this distinction in mind. They're not, as a rule, necessarily interested in being part of our project -- they have their own project to worry with. They just want to work with us toward outcomes that are in the mutual benefit of our project and theirs.

That interaction, on those terms, has been rather successful, and is I think a useful model for us in other areas.

At the same time, the problem of reviewer capacity, which you mention, is also a key item, and something on which we should spend time and attention. We could think, e.g., about how we might use each of our public successes as a project to encourage further support from current or new project sponsors to be directed toward this key constraint.

[oli-obk]

At the same time, the problem of reviewer capacity, which you mention, is also a key item, and something on which we should spend time and attention. We could think, e.g., about how we might use each of our public successes as a project to encourage further support from current or new project sponsors to be directed toward this key constraint.

We could tie hiring a manager (that will streamline work and thus result in more review capacity being needed) to paying an existing reviewer in the community. These things will never balance, but proactively avoiding

is probably a good idea 😆.

Jokes aside, I don't know what the solution here is. Maybe it's proactively reserving some money to let such new managers/the team(s) they do program management for give to reviewers that have gh sponsors and are doing something that drives their goals forward.

No matter how good you manage a program, either you repeatedly tell those that want you to do features that there's no reviewer capacity for it (for which we don't need a manager, we can just state this), or you manage the code contributors and planning of everything and then don't succeed because all the code just rots in PRs.

[jamesmunns]

(edit: moved down so it gets picked up by rfcbot)

[jamesmunns]

Separate from my concern, I wonder if we should orient this more as a "context manager" role, rather than as a "program driver" role. Said differently, I would like to see more of an "observer + scribe" role, rather than acting as a "leader" of these tasks.

I think the distinction matters, particularly with volunteer contributors. There is a VERY real "asymmetrical power" when it comes to having time: someone able to spend 40 hours a week is much more able to push a conversation and decision making in a certain direction than someone who only has 1-5 hours per week, just in terms of sheer volume. For that reason, I think we need to be very careful to scope the role appropriately.

This would mean making it clear that the expectation of this role is to:

• Make it easier for people with less time to quickly be able to see the current state of open tasks, and be effective in conversation or implementation with a shorter "spin-up" or "context switch" time.
• Ensure that the current state, including in-progress items and blockers, is well documented and maintained
• Assist in keeping issues, pull requests, and documentation up to date, to make contribution easier for others.
• Assist in keeping issues and RFCs up to date when there are open concerns or discussions
• Keeping context public and up to date when discussions are had in various public and private venues.

And specifically enumerate these as ANTI goals:

• Making decisions of priority, particularly when there are open discussions
• Making design/implementation decisions
• Making go/no-go calls
• Pushing contributors to complete certain tasks
• Pushing contributors to NOT complete certain tasks, or discourage them from raising issues or concerns that may lead to delays of landing features

[Mark-Simulacrum]

@rfcbot merge

I'm kicking off merge, but will raise some concerns as well.

[rfcbot]

Team member @Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Mark-Simulacrum
• @eholk
• @ehuss
• @jamesmunns
• @m-ou-se
• @oli-obk
• @traviscross

Concerns:

• checkins (Allocate budget to Edition/Project Goals teams in support of program management #151 (comment))
• delegate-to-teams resolved by Allocate budget to Edition/Project Goals teams in support of program management #151 (comment)
• oversight-and-accountability (Allocate budget to Edition/Project Goals teams in support of program management #151 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Mark-Simulacrum]

@rfcbot concern delegate-to-teams

We would delegate all the details and the responsibility for follow-up action, including coordination with the Foundation, jointly to the leads of T-edition and T-project-goals.

In the past, we delegated to T-compiler leads for the compiler-ops role. I think that was probably a mistake (not that I want to go back and revise it) -- I think we should delegate to the teams and let those teams figure out the best way to execute. That may well be that they internally trust their leads or some other subset to make decisions here, but I think at a Council level we'd expect that the team as a whole is happy with the eventual hire(s) here. My guess is this changes very little in practice, but I'd like to see that confirmed.

[Mark-Simulacrum]

@rfcbot concern checkins

I think we should explicitly write down an expectation from the owners/teams on check-in points. I think we discussed a few thoughts in our meeting today (e.g., "solicited interest from the project", "found candidates", "have agreement from the Foundation")... I could also see framing this as requiring a (say) monthly or bimonthly update to the Council, similar to how project goals ask for regular updates from goal owners on the current progress. It sounded like @traviscross expects that to happen, but I'd like to see that reflected formally here.

[Mark-Simulacrum]

Not raising a concern for this, but I think it would be good for the teams to explicitly include in their discussions with the Foundation an ask that they help us formulate meaningful milestones or achievements that would/could help solicit further investment in this role, or roles like it, in future years. It may be useful to have a formal delegation/ask from the Council to that effect; it is perhaps implied, but I think editing it into the ask here would be a good idea.

[traviscross]

@rfcbot concern delegate-to-teams

We would delegate all the details and the responsibility for follow-up action, including coordination with the Foundation, jointly to the leads of T-edition and T-project-goals.

In the past, we delegated to T-compiler leads for the compiler-ops role. I think that was probably a mistake (not that I want to go back and revise it) -- I think we should delegate to the teams and let those teams figure out the best way to execute. That may well be that they internally trust their leads or some other subset to make decisions here, but I think at a Council level we'd expect that the team as a whole is happy with the eventual hire(s) here. My guess is this changes very little in practice, but I'd like to see that confirmed.

Agreed. I've updated the PR description to read:

We would delegate all the details and the responsibility for follow-up action, including coordination with the Foundation, jointly to T-edition and T-project-goals.

(I thought about adding a bit about the delegation being to the teams with the leads being accountable to ensure this follow-up action occurs, but actually I think that's just inherent to the role of team lead, so I left it out.)

[Mark-Simulacrum]

@rfcbot resolve delegate-to-teams

[jamesmunns]

(note: restating post-fcp-merge)

@rfcbot concern oversight-and-accountability

In general I am VERY in favor of using funds to handle the work that makes things go smoother. I think that "project management" definitely falls in the "requires serious effort to maintain context" and "not very fun as a volunteer", which makes it a good fit for paid work.

I would like to see some more discussion of how we ensure that this new project management role has oversight and accountability to all of the top level teams (either to team leads of top level teams, or via the council representatives of each top level team). This may also be something to address in the proposed edition/goals teams charters themselves.

[traviscross]

@rfcbot reviewed

The conversation with the Foundation has started, and we'll follow up on these other items that have been raised.