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 the leads of 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.