From 5b878611f6f33c03be60399ba85f0876bf9f09b7 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 25 Feb 2026 20:38:22 -0500 Subject: [PATCH 01/18] undirected funds RFC draft --- rfcs/undirected-funds-rfc.md | 226 +++++++++++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 rfcs/undirected-funds-rfc.md diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md new file mode 100644 index 0000000..fa2c3dd --- /dev/null +++ b/rfcs/undirected-funds-rfc.md @@ -0,0 +1,226 @@ +- Feature Name: `rust_maintainer_fund` +- Start Date: 2026-02-23 +- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) + +# Summary +[summary]: #summary + +The Rust Foundation Maintainer Fund (RFMF) is a joint effort by the Rust Project and the Rust Foundation to fund full-time Rust maintainers, called Maintainers in Residence. This RFC proposes how the Maintainer in Residence program should work: how candidates are selected, what's expected of them, and how the Foundation manages the relationship. + +This RFC builds on the Grants team established by [RFC 3919]. This RFC extends the Grants team's role to also vet candidates for Maintainer in Residence positions funded through the RFMF. The Grants team identifies which areas need support and returns a prioritized recommendation to the Foundation; the Foundation makes the final hiring decision and handles contracting, compensation, and funder relations. + +This RFC does not specify how much funding the RFMF has or where that funding comes from. It describes how the Project and Foundation would work together to make the best use of whatever funding is available for Maintainer in Residence positions. + +[RFC 3919]: https://github.com/rust-lang/rfcs/pull/3919 + +# Motivation +[motivation]: #motivation + +The Rust Foundation is establishing a Maintainer Fund to provide long-term funding for full-time Rust maintainers. The Leadership Council commissioned this RFC to recommend how those funds should be used. Our recommendation is that these funds should be used to hire full-time maintainers, called "Maintainers in Residence". + +## Why full-time maintainers in residence? + +In preparing this recommendation, we interviewed team leads across the Project. The message was clear: *"what's needed is people with the focus to drive longer-scale projects."* Volunteer maintenance keeps the lights on, but larger-scale work — clearing review backlogs, driving cross-cutting refactors, carrying context across a complex codebase — stalls because nobody has the sustained focus to push it through. The Clippy team put it simply: *"all the time that reviewers have goes into reviewing, triaging, and so on, and then the interesting longer-term projects just fall under the table."* + +The rust-analyzer experience shows what full-time presence makes possible — and what happens when it disappears. When a funded reviewer was working on r-a, the PR backlog stayed around 10. After that person changed jobs, it climbed to over 110: *"solving the review problem definitely requires money I think, there's no big question there."* Short-term grants help but aren't enough — the Clippy team received Foundation grants that let *"one person work almost full time on Clippy, but it was only for 6 months — it was hard to make long-term plans."* The problems teams describe require sustained, long-term presence. + +## Why companies should fund the maintainer fund + +We expect two kinds of donors to this fund. First, individuals and organizations that value Rust and want to support its long-term health — these are generally smaller-dollar donors contributing to a project they believe in. + +Second, and likely the larger source of funding, are companies that employ developers or contributors working full-time to improve Rust. These companies already invest in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" — reviewing other people's PRs, mentoring newcomers, fixing regressions, driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. + +What do funders get in return? Maintainers are always prioritizing — there are always more PRs to review, more bugs to triage, more work than time. Funders can reasonably expect that their bug reports get looked at, their PRs get reviewed, and their questions get answered. This costs the project essentially nothing: it's reprioritization within work the maintainer would do anyway. The PSF's experience after five years of its Developer in Residence program confirms that this kind of influence is normal and healthy. As one of their Developers in Residence put it when asked about sponsors influencing prioritization: *"Yes, of course, and I think that is entirely ethical."* Bloomberg, one of the PSF's sponsors, gives active feedback on how their sponsored maintainer spends time — *"they can't tell him that he MUST, but if they care about a thing, and it'll make them renew the contract for another 12 months, good to know."* + +The boundary is clear: funders can influence prioritization, but they can't direct the work or bypass project processes. No amount of sponsorship makes an RFC get accepted or a design decision go a particular way. + +## Why the Project should drive the selection + +Other funding mechanisms exist (or are being proposed) to fund development work that ties clearly to Project Goals roadmaps. But if we only fund goal-directed work, we miss a lot of what makes the Project healthy. Some teams don't directly deliver goals at all: moderation, infrastructure, release. Other work is cross-cutting and doesn't belong to any single goal but makes everyone's work go faster, such as major refactoring or CI improvements. + +The RFMF exists to cover this gap. But deciding where that funding has the most impact requires visibility into which teams are struggling, where dependencies are blocking, and where a single full-time person would have the most leverage, which is why we recommend that the Grants team (composed of active project members selected by the leadership council) drive the selection of who to award with a maintainer contract. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +The RFMF funds experienced, self-directed Maintainers in Residence who do the work that keeps Rust healthy: reviews, design guidance, mentorship, unblocking, regressions, refactorings, and so forth. + +Maintainers in Residence are team members, not outsiders. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. The difference is that they can commit sustained time to the work that volunteers can't. + +## Design axioms + +### The Project vets, the Foundation hires + +The RFMF is a joint effort. The Grants team (established by [RFC 3919]) identifies which areas need support, vets applicants, and returns a prioritized recommendation to the Foundation. The Foundation makes the final hiring decision and handles contracting, compensation, and funder relations. This separation keeps the Project focused on technical judgment and the Foundation focused on operational execution. + +### Funders get prioritization, not direction + +Funders can reasonably expect that their bug reports, PRs, and questions get attention — this is reprioritization within work the maintainer would do anyway, and it costs the project essentially nothing. What funders cannot do is direct a maintainer's work or bypass project processes. Maintainers in Residence decide how to spend their time based on what they and their teams think is most important. + +### Maintainers are team members, not outsiders + +Funded maintainers participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. They are not a separate class of contributor — they're team members who can commit sustained time. + +### Not one size fits all + +The RFMF doesn't try to be the sole employer of funded Rust maintainers. The Maintainer in Residence program fills a specific role: allowing project teams to select and direct maintainers toward the areas they identify as most critical. Other structures — the Rust-Analyzer Open Collective, the proposed RustNL Maintainer Fund, company employment — serve complementary roles. + +### The Project helps maintainers demonstrate their impact + +The Project provides scaffolding — goals, program management, reporting infrastructure — so maintainers can focus on the work while funders get visibility into outcomes. + +## The Grants team + +The Grants team chartered by [RFC 3919] — five members, appointed by the Leadership Council, organized as a Launching Pad subteam — takes on vetting Maintainer in Residence candidates as an additional responsibility alongside its existing grants work. This avoids creating parallel committees with overlapping membership and similar mandates. + +## Long-term contracts focused on maintenance, but with time for exploration + +Contract terms are expected to be around one year with annual renewal, though exact terms can be customized to the circumstance. Maintainers are expected to devote approximately half their time to maintenance in their area of focus, with the other half for work of their choosing. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +## The Grants team + +The Grants team's Maintainer in Residence responsibilities are: staying on top of the state of the Project by meeting regularly with teams and team leads, vetting applicants, and providing a prioritized recommendation list to the Foundation. This ongoing contact helps them assess where and how funds should be distributed. The Grants team does not make hiring decisions; that is the Foundation's domain. The Grants team also does not manage funded maintainers after they're hired; its role ends with the recommendation. + +## Application and vetting process + +The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply. Broad applications help surface needs and candidates the Grants team might not have identified on its own. + +Applicants provide a summary of their experience with the Rust project along with a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "refactor the codebase to be more accessible"). + +The Grants team prioritizes applications based on: + +1. conversations with team leads and team members to assess what support is most urgently needed; +2. the applicant's history with the project; +3. the work that was proposed; +4. the results of interviews or conversations with the applicant; and +5. any history of interpersonal or Code-of-Conduct issues known to the moderation team. + +The Grants team evaluates applicants on three dimensions: technical depth in the relevant area, community standing and trust within the Project, and maintenance orientation (whether the candidate's track record suggests they'll thrive in a role focused on reviews, mentorship, unblocking, and sustained technical work rather than feature implementation). + +The resulting prioritized list is returned to the Foundation. The final decision on who receives the contract is made by the Foundation staff. The expectation is that the Foundation will take the top candidate(s), but this is not a strict requirement. There may be practical reasons (salary expectations, availability, fit) to reach further down the list. The fact that applications are open is public; the prioritized recommendations and individual feedback are confidential between the Grants team and the Foundation. + +## Contract terms and renewal + +Contract terms are expected to be 1-year and to be renewed year-over-year, though exact terms can be customized to the circumstance. This is long enough to make leaving another job worthwhile and to build the context that makes someone effective. The PSF's experience confirms that contracts of this length with annual renewal provide reasonable stability while keeping the fund flexible. + +Renewal is not guaranteed: + +* There may not be adequate funds available to continue the existing maintainer contracts. +* The Grants team may feel that there are urgent unmet needs within the project that prompt a change in maintainer. +* The maintainer may not be doing an adequate job (though this scenario is typically managed separately; see performance management below). + +In advance of contract renewal, the Foundation will consult with the Grants team. The Grants team will assess the needs of the project and decide whether a change should be made. If they do decide to change things, they will issue a new call for applications. If desired, the current maintainer may re-apply. + +## Maintainer in Residence expectations + +Maintainers in Residence are expected to: + +* devote approximately half of their paid time to *maintenance* in their area of focus, with the other half being for work of their choosing; +* resolve time-critical issues such as newly reported bugs; +* champion project goals supported by their respective teams. + +## Responding to funder requests + +As described in the [motivation][motivation], funders can reasonably expect prioritization: a bug report looked at, a PR reviewed, a question answered. This is reprioritization within work the maintainer would do anyway — any maintainer would bump a bug report from an active user. + +Requests that go beyond prioritization — "develop this feature" or "devote sustained time to our priority" — are outside the scope of this relationship. The Foundation manages funder expectations and serves as a buffer so that maintainers aren't negotiating these boundaries directly. + +## Reporting and impact visibility + +Funded maintainers participate in the Project Goals process the same way any other team member does. If they champion a goal, they show up in the goal's tracking and reporting. If they provide review bandwidth for a goal, that's reflected in the goal's progress updates. There is no separate reporting track for funded maintainers; the Goals program is the reporting infrastructure. + +To ensure continued funding, it is important that the RFMF is able to demonstrate impact and value to its funders. The entire Project has a stake in maintainers demonstrating impact, and other teams are expected to assist: + +* The Goals team will prepare an initial draft by examining GitHub activity (PR reviews, etc.) and via updates on project goals championed by the maintainer. +* The Content team will interview maintainers and highlight their work. + +Program managers collect progress updates from goal owners (funded or not) on a regular cadence and prepare summaries. For funded maintainers, these summaries serve double duty: they give the Project visibility into goal progress, and the Foundation can use them to prepare funder-facing reports. + +The reporting expectations for funded maintainers are not more onerous than for volunteer contributors. The point is to reduce burden, not add it. + +## Performance management + +The Foundation staff and the Grants team will monitor the maintainer's work and periodically solicit feedback from contributors and other team members. If they do not feel that a maintainer is doing a good job, Foundation staff are expected to provide constructive feedback to the maintainer. If the maintainer's performance does not improve, their contract will not be renewed, and in extreme cases (e.g., code-of-conduct violations) could be terminated early. The Project does not decide whether a contract gets renewed; it provides input. + +# Frequently asked questions +[faq]: #faq + +## Why reuse the Grants team rather than create a new committee? + +Creating a new committee would mean a parallel body with overlapping membership and a similar mandate. The Grants team already has selection infrastructure and an LC appointment process. Adding RFMF-specific responsibilities to the same team is simpler and avoids fragmenting attention. + +## What does it look like to have a Maintainer in Residence on my team? + +The same as having any other team member. They show up in reviews, participate in design discussions, mentor newcomers, and work on what the team needs. The PSF's experience after nearly five years is instructive: the Developer in Residence does roughly 50/50 maintenance and proactive work, and the role feels like "just another team member" rather than an outside presence. The difference is that they can commit sustained time to problems that volunteers can't — the deep refactors, the 6-month projects, the work that's been stuck because nobody has bandwidth. + +## Why not a flexible contractor pool instead of long-term maintainers? + +Context and trust take time to build. The maintenance problems we heard about in team lead interviews (review backlogs, cross-team blocking, complex refactors that need months of sustained attention) require sustained presence, not project-scoped interventions. Contractors for scoped work is a valid model, but it's a different program solving a different problem. + +## How will we find the people for the grants team? + +That is a challenge. However, the grants team is expected to be a rewarding activity, as it gives team members the opportunity to support one another. + +## What if a Maintainer in Residence underperforms? + +Performance management is the Foundation's responsibility, not the Project's. The Project treats funded maintainers the same as any team member: Code of Conduct enforcement, team membership decisions, and the normal expectations that come with being on a team. The lines are clear: the Project evaluates candidates going in; the Foundation manages the relationship after. + +## What about people who only want to work part time? + +The RFMF targets long-term, sustained maintainers, the kind of commitment that's hard to do part time. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], $1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds deep, sustained maintenance work. + +## What does this RFC deliberately not specify? + +This RFC defines how the Project and Foundation work together to select and manage full-time funded maintainers. It deliberately does not specify how much funding the RFMF has, where that funding comes from, or how funders are solicited. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, part-time vs. full-time arrangements, evaluation criteria specifics, and reporting templates. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. + +## What happens if we don't do this? + +The Foundation will still operate its fund, but without structured Project input on who to hire or where to focus. There is more risk of misaligned funding, with money going to visible features rather than the invisible maintenance work that keeps Rust healthy. Teams continue to be precarious and isolated, and the Project misses the chance to build a coordination layer that connects willing funders to the work that needs doing. + +# Prior art +[prior-art]: #prior-art + +## Python Software Foundation: lessons from a mature program + +The PSF started its Developer in Residence program in 2021. After nearly five years, it now funds multiple maintainers, each sponsored by a specific company (Meta, Bloomberg, Alpha-Omega, Vercel, among others). Contracts are for 12 months, renewable based on continued sponsor funding. Maintainers are employees or contractors of the PSF, reporting to both the Executive Director and the Steering Council. + +The program's evolution taught us several lessons we've incorporated into this RFC. First, pure maintenance work becomes draining over time. The first Developer in Residence started doing only reviews, backports, and CI, and found that after a year or two, "there's not much joy in that." Allowing feature work alongside maintenance "made all the difference." We've reflected this in the RFMF design by recommending open-ended maintenance roles rather than prescribing a rigid split. + +Second, sponsors attach to people, not positions. In practice, a sponsor funding a position filled by a particular person will want to continue sponsoring that person specifically if they're happy with the work, rather than funding an abstract role. This has implications for how the Foundation thinks about sponsor relationships: sponsors care about outcomes and the people producing them. + +Third, different sponsors want very different levels of engagement. Some are hands-off; others want detailed quarterly reports and input on how maintainers spend their time. The Foundation as an intermediary is valuable here. It buffers the relationship between sponsors and maintainers, so that maintainers aren't managing sponsor expectations directly. + +## Django Fellowship: weekly reports and community-focused maintenance + +The Django Fellowship program has been running since 2014, predating the PSF program and providing the longest track record of any comparable effort. Fellows are contractors (not employees), expected to commit at least 20 hours per week, with compensation explicitly described as "not competitive with full-time salaries in big cities." The position is ongoing until the Fellow chooses to step down. + +Fellows post weekly reports to the django-developers mailing list, a more frequent cadence than the PSF's approach. The work is more narrowly focused on "housekeeping and community support": monitoring security email, fixing release blockers, reviewing pull requests, and mentoring new contributors. The Django model demonstrates that a maintenance-focused role can work long-term even at lower compensation, but also suggests that the pool of people willing to accept those terms is limited. + +## Zig Software Foundation: lean and independent + +The ZSF takes a simpler approach: core team members bill hours directly to the foundation. As a 501(c)(3) non-profit founded in 2020, 92% of its spending goes directly to paying contributors, with minimal administrative overhead. It has no big tech companies on its board, an explicit design choice to maintain independence. + +The ZSF model is leaner and more informal than PSF or Django, but also smaller in scale and more dependent on individual large donations. It demonstrates that low-overhead models are possible, but the approach may not scale to the number of maintainers Rust needs. + +## TC's Project Grants Program: the committee model we're building on + +The Leadership Council's Project Grants Program ([RFC 3919]) establishes a $100K program supporting ~5 contributors at $1,500/month. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. + +We build on the Grants team structure directly. Rather than creating a parallel committee with overlapping membership and a similar mandate, the Maintainer in Residence vetting process uses the same Grants team with additional responsibilities. This gives us selection infrastructure and an LC appointment process that already exists, and avoids fragmenting the Project's attention across multiple bodies. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +None. + +# Future possibilities +[future-possibilities]: #future-possibilities + +## Extending the vetting service to other funding organizations + +The clearest message from our team lead interviews was that the most effective way to help teams is to add full-time, long-term maintainers. Short-term grants and scoped contracts have their place, but the problems teams described — review backlogs, cross-cutting refactors, carrying context across a complex codebase — require sustained presence. We encourage any organization looking to fund Rust maintenance to direct funding toward long-term Maintainer in Residence positions. + +This RFC defines the interface between the Rust Project and the RFMF specifically, but nothing about the process is inherently RFMF-specific. The Grants team's core service — assessing where full-time maintainers would have the most impact, evaluating candidates, and returning a prioritized recommendation — could be offered to other funding organizations that want to hire Maintainers in Residence. The value proposition is the same regardless of who's paying: the Project has visibility into which teams are struggling and which candidates have the trust and context to be effective, and funding organizations benefit from that assessment rather than making hiring decisions without it. From 5e3f9e05bb1eaf6066e428bf31fc520a5b61b6ff Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 2 Mar 2026 12:07:18 -0500 Subject: [PATCH 02/18] refactor: draft 2 --- rfcs/undirected-funds-rfc.md | 218 +++++++++++++++++++++++++---------- 1 file changed, 157 insertions(+), 61 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index fa2c3dd..48dd2ac 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -5,180 +5,260 @@ # Summary [summary]: #summary -The Rust Foundation Maintainer Fund (RFMF) is a joint effort by the Rust Project and the Rust Foundation to fund full-time Rust maintainers, called Maintainers in Residence. This RFC proposes how the Maintainer in Residence program should work: how candidates are selected, what's expected of them, and how the Foundation manages the relationship. +The Rust Foundation Maintainer Fund (RFMF) collects sponsorships from companies and individuals who want to support Rust's long-term health. Funds raised through the RFMF flow to the Leadership Council's Project Priorities budget. The Leadership Council determines how that budget is spent, deploying it through project grants, Maintainers in Residence, or other programs as needs evolve. -This RFC builds on the Grants team established by [RFC 3919]. This RFC extends the Grants team's role to also vet candidates for Maintainer in Residence positions funded through the RFMF. The Grants team identifies which areas need support and returns a prioritized recommendation to the Foundation; the Foundation makes the final hiring decision and handles contracting, compensation, and funder relations. +This RFC recommends that the primary use of RFMF funds should be hiring full-time Maintainers in Residence — experienced, self-directed maintainers who provide the sustained presence that teams need. This RFC describes what sponsors get in return for their contributions, how Maintainer in Residence candidates are selected, what's expected of them, and how the Foundation manages the relationship. -This RFC does not specify how much funding the RFMF has or where that funding comes from. It describes how the Project and Foundation would work together to make the best use of whatever funding is available for Maintainer in Residence positions. +This RFC defines a Funding team charter: staying in contact with teams to understand their needs, connecting teams to available resources, and working with the Foundation to identify and/or vet candidates for Maintainer in Residence positions. The Foundation makes the final hiring decision and handles contracting, compensation, and sponsor relations. [RFC 3919]: https://github.com/rust-lang/rfcs/pull/3919 +### Topics for discussion + +The following topics are not yet resolved and need committee input. Each has a corresponding FAQ entry with more detail. + +1. **[Who manages Maintainers in Residence after they're hired?][who-manages-mirs]** The RFC currently places performance management with the Foundation. An alternative is to have the Project handle it through a dedicated (funded) resource. See the FAQ for tradeoffs. +2. **[Should the Funding team be a new team or extend the Grants team?][funding-team-org]** The RFC defines the charter but leaves organizational form to the Leadership Council. The Grants team has existing infrastructure but a narrower mandate; the Funding team charter is broader. See the FAQ for tradeoffs. + # Motivation [motivation]: #motivation -The Rust Foundation is establishing a Maintainer Fund to provide long-term funding for full-time Rust maintainers. The Leadership Council commissioned this RFC to recommend how those funds should be used. Our recommendation is that these funds should be used to hire full-time maintainers, called "Maintainers in Residence". +The Rust Foundation is establishing a Maintainer Fund to collect sponsorships and provide long-term funding for Rust maintenance. Funds raised through the RFMF flow to the Leadership Council's Project Priorities budget, giving the Project control over how maintenance funding is deployed. The Leadership Council commissioned this RFC to recommend how those funds should be used. Our primary recommendation is that these funds should be used to hire full-time maintainers, called "Maintainers in Residence," though the Council retains flexibility to deploy funds through other programs as needs evolve. ## Why full-time maintainers in residence? -In preparing this recommendation, we interviewed team leads across the Project. The message was clear: *"what's needed is people with the focus to drive longer-scale projects."* Volunteer maintenance keeps the lights on, but larger-scale work — clearing review backlogs, driving cross-cutting refactors, carrying context across a complex codebase — stalls because nobody has the sustained focus to push it through. The Clippy team put it simply: *"all the time that reviewers have goes into reviewing, triaging, and so on, and then the interesting longer-term projects just fall under the table."* +In preparing this recommendation, we interviewed team leads across the Project. The message was clear: *"what's needed is people with the focus to drive longer-scale projects."* Volunteer maintenance keeps the lights on, but larger-scale work — clearing review backlogs, driving cross-cutting refactors, carrying context across a complex codebase — stalls because nobody has the sustained focus to push it through. As one (volunteer) team lead said, *"All the time that reviewers have goes into reviewing, triaging, and so on, and then the interesting longer-term projects just fall under the table."* -The rust-analyzer experience shows what full-time presence makes possible — and what happens when it disappears. When a funded reviewer was working on r-a, the PR backlog stayed around 10. After that person changed jobs, it climbed to over 110: *"solving the review problem definitely requires money I think, there's no big question there."* Short-term grants help but aren't enough — the Clippy team received Foundation grants that let *"one person work almost full time on Clippy, but it was only for 6 months — it was hard to make long-term plans."* The problems teams describe require sustained, long-term presence. +The rust-analyzer experience shows what full-time presence makes possible, and what happens when it disappears: -## Why companies should fund the maintainer fund +* When a funded reviewer was working on r-a, the PR backlog stayed around 10. After that person changed jobs, it climbed to over 110: *"solving the review problem definitely requires money I think, there's no big question there."* +* Short-term grants help but aren't enough. The Clippy team received Foundation grants that let *"one person work almost full time on Clippy, but it was only for 6 months — it was hard to make long-term plans."* -We expect two kinds of donors to this fund. First, individuals and organizations that value Rust and want to support its long-term health — these are generally smaller-dollar donors contributing to a project they believe in. +The problems teams describe require sustained, long-term presence. -Second, and likely the larger source of funding, are companies that employ developers or contributors working full-time to improve Rust. These companies already invest in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" — reviewing other people's PRs, mentoring newcomers, fixing regressions, driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. +## Why companies should sponsor the maintainer fund -What do funders get in return? Maintainers are always prioritizing — there are always more PRs to review, more bugs to triage, more work than time. Funders can reasonably expect that their bug reports get looked at, their PRs get reviewed, and their questions get answered. This costs the project essentially nothing: it's reprioritization within work the maintainer would do anyway. The PSF's experience after five years of its Developer in Residence program confirms that this kind of influence is normal and healthy. As one of their Developers in Residence put it when asked about sponsors influencing prioritization: *"Yes, of course, and I think that is entirely ethical."* Bloomberg, one of the PSF's sponsors, gives active feedback on how their sponsored maintainer spends time — *"they can't tell him that he MUST, but if they care about a thing, and it'll make them renew the contract for another 12 months, good to know."* +We expect two kinds of sponsors. First, individuals and organizations that value Rust and want to support its long-term health without any particular expectations. These will generally be smaller-dollar sponsors contributing to a project they believe in. -The boundary is clear: funders can influence prioritization, but they can't direct the work or bypass project processes. No amount of sponsorship makes an RFC get accepted or a design decision go a particular way. +Second, and important for the fund's sustainability, are companies that employ developers or contributors working full-time to improve Rust. These companies are invested in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" like reviewing other people's PRs, mentoring newcomers, fixing regressions, and driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. + +What do sponsors get in return (besides PR and good vibes)? First, a connection to the project: RFMF sponsors will meet with project leadership, team leads, and maintainers over the course of the year. This will help them stay abreast of what is happening in the project and also let the project hear from them about their needs and priorities. Experience at other language communities shows the importance of these efforts. The Scala Center experience shows that sponsors often value hearing from their peers — other Rust-using organizations — as much as they do hearing from the project itself. Knowing what is important to sponsors is good signal on what matters to users, but it's also important for maintaining a good relationship. As one Python Developer in Residence put it, *"In terms of how \[a Developer in Residence spends their time\], sponsors can't make them do anything, but if they care about a thing, and it'll make them renew the contract for another 12 months, good to know."* Sponsors can also reach out about specific PRs or bugs that need attention (this is best effort, not an SLA). + +The project also highlights the work of funded maintainers via the content and project goals teams (these updates are made publicly available as well). Speaking with sponsors at the PSF confirms the importance of that kind of accountability: sponsors want to know what work would stop happening if they stopped funding. *"Very quickly that becomes the value prop when they are discussing internally whether to put in the $$."* ## Why the Project should drive the selection -Other funding mechanisms exist (or are being proposed) to fund development work that ties clearly to Project Goals roadmaps. But if we only fund goal-directed work, we miss a lot of what makes the Project healthy. Some teams don't directly deliver goals at all: moderation, infrastructure, release. Other work is cross-cutting and doesn't belong to any single goal but makes everyone's work go faster, such as major refactoring or CI improvements. +A companion effort — the proposed Project Goals Funding program (see [Future possibilities][]) — would provide directed grants tied to specific goals, roadmaps, and application areas. But if we only fund goal-directed work, we miss a lot of what makes the Project healthy. Some teams don't directly deliver goals at all: moderation, infrastructure, release. Other work is cross-cutting and doesn't belong to any single goal but makes everyone's work go faster, such as major refactoring or CI improvements. -The RFMF exists to cover this gap. But deciding where that funding has the most impact requires visibility into which teams are struggling, where dependencies are blocking, and where a single full-time person would have the most leverage, which is why we recommend that the Grants team (composed of active project members selected by the leadership council) drive the selection of who to award with a maintainer contract. +The RFMF exists to cover this gap. Its funds flow to the Leadership Council's Project Priorities budget, giving the Project control over how maintenance funding is deployed. But deciding where that funding has the most impact requires visibility into which teams are struggling, where dependencies are blocking, and where a single full-time person would have the most leverage, which is why we recommend that the Funding team (composed of active project members selected by the Leadership Council) drive the selection of who to award with a maintainer contract. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -The RFMF funds experienced, self-directed Maintainers in Residence who do the work that keeps Rust healthy: reviews, design guidance, mentorship, unblocking, regressions, refactorings, and so forth. +The RFMF collects sponsorships from companies and individuals and directs those funds to the Leadership Council's Project Priorities budget. The Council deploys these funds to maintain Rust's health — primarily through Maintainers in Residence, but also through project grants, travel funding, and other programs as needs dictate. -Maintainers in Residence are team members, not outsiders. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. The difference is that they can commit sustained time to the work that volunteers can't. +Maintainers in Residence are the flagship program: experienced, self-directed maintainers who do the work that keeps Rust healthy — reviews, design guidance, mentorship, unblocking, regressions, refactorings, and so forth. They are team members, not outsiders. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. The difference is that they can commit sustained time to the work that volunteers can't. ## Design axioms -### The Project vets, the Foundation hires +### The RFMF is a collaboration between the Project and the Foundation -The RFMF is a joint effort. The Grants team (established by [RFC 3919]) identifies which areas need support, vets applicants, and returns a prioritized recommendation to the Foundation. The Foundation makes the final hiring decision and handles contracting, compensation, and funder relations. This separation keeps the Project focused on technical judgment and the Foundation focused on operational execution. +The Project brings knowledge of team health and needs; the Foundation brings logistics, sponsor relationships, and operational capacity. The Funding team (see below) identifies which areas need support and works with the Foundation to select candidates. The Foundation makes the final hiring decision and handles contracting, compensation, and sponsor relations. This is a partnership, not a handoff — both sides contribute throughout. -### Funders get prioritization, not direction +### Engaging RFMF sponsors is a whole-project affair -Funders can reasonably expect that their bug reports, PRs, and questions get attention — this is reprioritization within work the maintainer would do anyway, and it costs the project essentially nothing. What funders cannot do is direct a maintainer's work or bypass project processes. Maintainers in Residence decide how to spend their time based on what they and their teams think is most important. +The Leadership Council, team leads, and Maintainers in Residence all participate in sponsor engagement — attending meetings, discussing project direction, and learning about sponsor pain points. This benefits everyone: sponsors get a direct connection to the people doing the work, and the project learns firsthand what Rust-using organizations need. Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. ### Maintainers are team members, not outsiders -Funded maintainers participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. They are not a separate class of contributor — they're team members who can commit sustained time. +Maintainer in Residence candidates must already be members of the relevant Rust team(s) with the permissions needed for the work — reviewing PRs, championing goals, and performing actions limited to official team members. This is a hard requirement, not just an expectation. Funded maintainers are not a separate class of contributor — they're existing team members who can now commit sustained time. ### Not one size fits all -The RFMF doesn't try to be the sole employer of funded Rust maintainers. The Maintainer in Residence program fills a specific role: allowing project teams to select and direct maintainers toward the areas they identify as most critical. Other structures — the Rust-Analyzer Open Collective, the proposed RustNL Maintainer Fund, company employment — serve complementary roles. +The RFMF doesn't try to be the sole channel for funding Rust maintenance. The Maintainer in Residence program fills a specific role: allowing project teams to select and direct maintainers toward the areas they identify as most critical. Other structures — the proposed Project Goals Funding program for directed grants (see [Future possibilities][]), the Project Grants Program for contributor stipends, the Rust-Analyzer Open Collective, the proposed RustNL Maintainer Fund, company employment — serve complementary roles. ### The Project helps maintainers demonstrate their impact -The Project provides scaffolding — goals, program management, reporting infrastructure — so maintainers can focus on the work while funders get visibility into outcomes. +The Project provides scaffolding — goals, program management, reporting infrastructure — so maintainers can focus on the work while sponsors get visibility into outcomes. + +## What sponsors get +[what-sponsors-get]: #what-sponsors-get + +RFMF sponsors contribute to a general fund and don't direct where the money goes or who gets hired. Every contribution helps fund the sustained maintenance that keeps Rust healthy. All sponsors receive public recognition and visibility into how funds are being used through regular public reports. + +The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. Higher tiers provide additional benefits: + +* **A community of sponsors.** The Foundation builds a community of sponsoring organizations. Sponsors meet regularly with project leadership (Leadership Council, team leads), maintainers, and each other. The Scala Center experience shows that sponsors often value hearing from their peers — other Rust-using organizations — as much as they do hearing from project leadership itself. +* **Regular engagement with project leadership and maintainers.** Meetings with Leadership Council members, team leads, and Maintainers in Residence to discuss project direction, sponsor experiences, and pain points. Maintainers also benefit from these meetings — they learn firsthand what sponsors need, which informs their priorities naturally. +* **Best-effort attention.** Sponsors can reach out to the Foundation or project contacts about PRs or bugs that need attention. There is no SLA or guarantee — any maintainer would bump a bug report from an active user, and sponsors can reasonably expect the same consideration. + +This RFC does not define the tiers — that is the Foundation's domain. + +The Leadership Council and Rust team members are generally expected to participate in sponsor engagement activities — attending meetings, having discussions with sponsors — as it is in the project's overall interest to encourage sponsorship. This does not imply that team members should make any technical decisions (e.g., RFC or PR approvals) that they would not have made otherwise. The project also benefits from closer contact with sponsoring organizations: they are by definition Rust-using organizations that value open-source maintenance, and it is helpful to learn about their pain points, successes, and other lessons. -## The Grants team +What sponsors do not get: the ability to direct a maintainer's work, pick who gets hired, bypass project processes, or influence technical decisions. -The Grants team chartered by [RFC 3919] — five members, appointed by the Leadership Council, organized as a Launching Pad subteam — takes on vetting Maintainer in Residence candidates as an additional responsibility alongside its existing grants work. This avoids creating parallel committees with overlapping membership and similar mandates. +## The Funding team -## Long-term contracts focused on maintenance, but with time for exploration +This RFC defines a set of responsibilities we call the "Funding team" charter: -Contract terms are expected to be around one year with annual renewal, though exact terms can be customized to the circumstance. Maintainers are expected to devote approximately half their time to maintenance in their area of focus, with the other half for work of their choosing. +1. **Staying in regular contact with teams** to understand their needs and the state of the project. +2. **Connecting teams to available resources** even outside MiR hiring — e.g., redirecting an existing maintainer to help with a situation, connecting a team lead to the Foundation, etc. +3. **Working with the Foundation to select MiR candidates** when positions become available, choosing candidates who'll have the most overall impact based on project needs. + +This RFC defines the charter — the responsibilities — but leaves the organizational structure to the Leadership Council. The Funding team could be a new team, or it could be an extension of the existing Grants team established by [RFC 3919]. See [Unresolved questions][] for more discussion. + +## Full-time positions with balanced expectations + +Maintainers in Residence are expected to spend 100% of their funded time working to improve the Rust project. Within that: + +* ~50% on **team priorities** — whatever the team needs. This could be development work (refactoring a major subsystem, rewriting the trait solver) or reactive work (reviews, mentoring, bug-fixing, triage). +* ~50% on **individual priorities of their choosing** within the project. + +This split is about team-directed vs. self-directed, not "maintenance vs. features." If the team needs the trait solver rewritten, that's team priorities. The PSF's experience after nearly five years confirms that allowing this balance "made all the difference" — pure maintenance work becomes draining over time. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -## The Grants team +## The Funding team -The Grants team's Maintainer in Residence responsibilities are: staying on top of the state of the Project by meeting regularly with teams and team leads, vetting applicants, and providing a prioritized recommendation list to the Foundation. This ongoing contact helps them assess where and how funds should be distributed. The Grants team does not make hiring decisions; that is the Foundation's domain. The Grants team also does not manage funded maintainers after they're hired; its role ends with the recommendation. +The Funding team's role is to keep a pulse on the project and work with the Foundation to select which maintainers to hire. Its core responsibilities are: + +1. **Staying in regular contact with teams** — meeting regularly with team leads and members to understand their needs, health, and where support would have the most impact. +2. **Connecting teams to available resources** — even outside MiR hiring. This might mean redirecting an existing maintainer to help with a situation, connecting a team lead to the Foundation, or surfacing resources a team didn't know existed. +3. **Working with the Foundation to select MiR candidates** — when positions become available, evaluating applicants and selecting candidates who'll have the most overall impact based on project needs. + +The Funding team does not make hiring decisions; that is the Foundation's domain. The Funding team also does not manage funded maintainers after they're hired; its role ends with the selection. ## Application and vetting process -The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply. Broad applications help surface needs and candidates the Grants team might not have identified on its own. +The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. However, successful candidates must already be members of the relevant Rust team(s) with the permissions needed for the work. Applicants provide a summary of their experience with the Rust project along with a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "refactor the codebase to be more accessible"). -The Grants team prioritizes applications based on: +The Funding team prioritizes applications based on: 1. conversations with team leads and team members to assess what support is most urgently needed; 2. the applicant's history with the project; -3. the work that was proposed; +3. any specific work that was proposed in the application; 4. the results of interviews or conversations with the applicant; and 5. any history of interpersonal or Code-of-Conduct issues known to the moderation team. -The Grants team evaluates applicants on three dimensions: technical depth in the relevant area, community standing and trust within the Project, and maintenance orientation (whether the candidate's track record suggests they'll thrive in a role focused on reviews, mentorship, unblocking, and sustained technical work rather than feature implementation). +The Funding team evaluates applicants on three dimensions: technical depth in the relevant area, community standing and trust within the Project, and sustained work orientation (whether the candidate's track record suggests they'll thrive in a role focused on reviews, mentorship, unblocking, and the kind of long-term technical work that requires deep context). -The resulting prioritized list is returned to the Foundation. The final decision on who receives the contract is made by the Foundation staff. The expectation is that the Foundation will take the top candidate(s), but this is not a strict requirement. There may be practical reasons (salary expectations, availability, fit) to reach further down the list. The fact that applications are open is public; the prioritized recommendations and individual feedback are confidential between the Grants team and the Foundation. +The Funding team works with the Foundation to select from the applicant pool. The Foundation makes the final decision on who receives the contract, but the expectation is that it will follow the Funding team's recommendation. There may be practical reasons (salary expectations, availability, fit) that lead to a different choice. The fact that applications are open is public; the prioritized recommendations and individual feedback are confidential between the Funding team and the Foundation. ## Contract terms and renewal -Contract terms are expected to be 1-year and to be renewed year-over-year, though exact terms can be customized to the circumstance. This is long enough to make leaving another job worthwhile and to build the context that makes someone effective. The PSF's experience confirms that contracts of this length with annual renewal provide reasonable stability while keeping the fund flexible. +The precise terms of the arrangement are not defined by this RFC. The arrangement is likely to begin as year-long contracts but may change to other durations, regular employment, or vary by locale. The important points are: it is a **full-time position**, and it is expected to **continue as long as both sides are satisfied and funding is available**. Compensation should be a flat rate within a small number of bands (e.g., junior and senior), rather than individually negotiated. Flat rates keep the program simple and avoid the perception that some maintainers are valued more than others for equivalent work. The compensation structure is publicly advertised as part of the call for applications. The Foundation determines the specific rates and may adjust them over time as the program learns what works and what's needed to attract strong candidates. Renewal is not guaranteed: * There may not be adequate funds available to continue the existing maintainer contracts. -* The Grants team may feel that there are urgent unmet needs within the project that prompt a change in maintainer. +* The Funding team may feel that there are urgent unmet needs within the project that prompt a change in maintainer (but this is in tension with the primary goal of this RFC of providing long-term, funded maintenance; see below). * The maintainer may not be doing an adequate job (though this scenario is typically managed separately; see performance management below). -In advance of contract renewal, the Foundation will consult with the Grants team. The Grants team will assess the needs of the project and decide whether a change should be made. If they do decide to change things, they will issue a new call for applications. If desired, the current maintainer may re-apply. +Deciding not to renew a well-performing maintainer in order to fund a different area should not be done lightly. Sustained presence is the core value proposition of the program — startup overhead is real, context takes time to build, and the problems this program targets require continuity. The Funding team should strive to maintain existing maintainers and grow the program to meet new needs rather than redirecting existing positions. Given limited funding, the Funding team can also encourage existing maintainers to pick up work in new areas rather than replacing them. + +In advance of contract renewal, the Foundation will consult with the Funding team. The Funding team will assess the needs of the project and decide whether a change should be made. If they do decide to change things, they will issue a new call for applications. If desired, the current maintainer may re-apply. ## Maintainer in Residence expectations -Maintainers in Residence are expected to: +Maintainers in Residence are expected to spend 100% of their funded time working to improve the Rust project. Within that: + +* ~50% on **team priorities** — whatever the team identifies as most important. This includes reviews, mentoring, bug-fixing, triage, and larger development work like refactors or subsystem rewrites. +* ~50% on **individual priorities of their choosing** within the project. + +Maintainers in Residence are also expected to: -* devote approximately half of their paid time to *maintenance* in their area of focus, with the other half being for work of their choosing; * resolve time-critical issues such as newly reported bugs; -* champion project goals supported by their respective teams. +* champion Project Goals supported by their respective teams, even if they themselves might not have championed that goal as an individual; +* work with the Project to ensure their work gets regularly reported on; +* remain a member of the Project and relevant teams, in good standing. -## Responding to funder requests +## Responding to sponsor requests -As described in the [motivation][motivation], funders can reasonably expect prioritization: a bug report looked at, a PR reviewed, a question answered. This is reprioritization within work the maintainer would do anyway — any maintainer would bump a bug report from an active user. +Sponsors can reach out to the Foundation or project contacts about PRs or bugs that need attention. This is best effort, not an SLA — any maintainer would bump a bug report from an active user, and sponsors can reasonably expect the same consideration. -Requests that go beyond prioritization — "develop this feature" or "devote sustained time to our priority" — are outside the scope of this relationship. The Foundation manages funder expectations and serves as a buffer so that maintainers aren't negotiating these boundaries directly. +Requests that go beyond this — "develop this feature" or "devote sustained time to our priority" — are outside the scope of this relationship. (The [Future possibilities][] section describes a Project Goal Funding program that could support sponsors seeking that level of direction in the future.) The Foundation manages sponsor expectations and serves as a buffer so that maintainers aren't negotiating these boundaries directly. ## Reporting and impact visibility Funded maintainers participate in the Project Goals process the same way any other team member does. If they champion a goal, they show up in the goal's tracking and reporting. If they provide review bandwidth for a goal, that's reflected in the goal's progress updates. There is no separate reporting track for funded maintainers; the Goals program is the reporting infrastructure. -To ensure continued funding, it is important that the RFMF is able to demonstrate impact and value to its funders. The entire Project has a stake in maintainers demonstrating impact, and other teams are expected to assist: +To ensure continued funding, it is important that the RFMF is able to demonstrate impact and value to its sponsors. The entire Project has a stake in maintainers demonstrating impact, and other teams are expected to assist: -* The Goals team will prepare an initial draft by examining GitHub activity (PR reviews, etc.) and via updates on project goals championed by the maintainer. +* The program management team will prepare an initial draft by examining GitHub activity (PR reviews, etc.) and via updates on Project Goals championed by the maintainer. * The Content team will interview maintainers and highlight their work. -Program managers collect progress updates from goal owners (funded or not) on a regular cadence and prepare summaries. For funded maintainers, these summaries serve double duty: they give the Project visibility into goal progress, and the Foundation can use them to prepare funder-facing reports. +Program managers collect progress updates from goal owners (funded or not) on a regular cadence and prepare summaries. For funded maintainers, these summaries serve double duty: they give the Project visibility into goal progress, and the Foundation can use them to prepare sponsor-facing reports. The reporting expectations for funded maintainers are not more onerous than for volunteer contributors. The point is to reduce burden, not add it. ## Performance management -The Foundation staff and the Grants team will monitor the maintainer's work and periodically solicit feedback from contributors and other team members. If they do not feel that a maintainer is doing a good job, Foundation staff are expected to provide constructive feedback to the maintainer. If the maintainer's performance does not improve, their contract will not be renewed, and in extreme cases (e.g., code-of-conduct violations) could be terminated early. The Project does not decide whether a contract gets renewed; it provides input. +The Foundation staff and the Funding team will monitor the maintainer's work and periodically solicit feedback from contributors and other team members. If they do not feel that a maintainer is doing a good job, Foundation staff are expected to provide constructive feedback to the maintainer. If the maintainer's performance does not improve, their contract will not be renewed. + +Separately, Code of Conduct violations that result in removal from the Project immediately terminate the contract. Team membership is a hard requirement for the role; a maintainer who is no longer a project member cannot continue as a Maintainer in Residence. + +The Project does not decide whether a contract gets renewed; it provides input. # Frequently asked questions [faq]: #faq -## Why reuse the Grants team rather than create a new committee? +## How will the Funding team be organized? +[funding-team-org]: #how-will-the-funding-team-be-organized + +This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. There are two main options: + +**Extend the Grants team.** The Grants team established by [RFC 3919] already has an LC appointment process, selection infrastructure, and conflict-of-interest policies. Extending it avoids fragmenting volunteer attention across overlapping committees. + +**Create a new team.** The Funding team's charter is broader than selecting recipients — it includes staying in regular contact with teams, connecting them to resources, and understanding project health holistically. MiR selection is only one part of that mandate. A new team with a broader mandate may be a better fit than extending a team whose focus is choosing grant recipients. -Creating a new committee would mean a parallel body with overlapping membership and a similar mandate. The Grants team already has selection infrastructure and an LC appointment process. Adding RFMF-specific responsibilities to the same team is simpler and avoids fragmenting attention. +We expect the Leadership Council to determine the right organizational form. ## What does it look like to have a Maintainer in Residence on my team? -The same as having any other team member. They show up in reviews, participate in design discussions, mentor newcomers, and work on what the team needs. The PSF's experience after nearly five years is instructive: the Developer in Residence does roughly 50/50 maintenance and proactive work, and the role feels like "just another team member" rather than an outside presence. The difference is that they can commit sustained time to problems that volunteers can't — the deep refactors, the 6-month projects, the work that's been stuck because nobody has bandwidth. +In one sense, the same as having any other team member. They show up in reviews, participate in design discussions, mentor newcomers, and work on what the team needs. The PSF's experience after nearly five years is instructive: the Developer in Residence does roughly 50/50 maintenance and proactive work, and the role feels like "just another team member" rather than an outside presence. + +But there is an important difference beyond just having more time. Most team members are volunteers, and team leads can't ask volunteers to take on specific tasks — they can only hope someone steps up. A Maintainer in Residence, by contrast, has dedicated half their time to team priorities. Team leadership should feel free to ask a MiR to take on high-priority work that nobody else can tackle — championing a goal, driving a critical refactor, clearing a review backlog — so long as it fits within that team-priorities capacity. This is a resource that team leads have never had before, and it changes the dynamic from "hoping someone volunteers" to "directing sustained effort where it's needed most." ## Why not a flexible contractor pool instead of long-term maintainers? Context and trust take time to build. The maintenance problems we heard about in team lead interviews (review backlogs, cross-team blocking, complex refactors that need months of sustained attention) require sustained presence, not project-scoped interventions. Contractors for scoped work is a valid model, but it's a different program solving a different problem. -## How will we find the people for the grants team? +## How will we find the people for the Funding team? + +The same way we find people for any other team. Funding team work is expected to be rewarding, as it gives team members the opportunity to understand the project holistically and support one another. + +## Who manages Maintainers in Residence after they're hired? +[who-manages-mirs]: #who-manages-maintainers-in-residence-after-theyre-hired + +The Funding team's role ends with the recommendation. Someone needs to synthesize feedback from the Project and make the call on performance. There are two main options: + +**Foundation manages (current RFC position).** Management and performance feedback are skills, and the Foundation has professional staff experienced in them. This shouldn't be a heavy lift early on — we're selecting experienced, self-directed maintainers who are unlikely to have significant performance issues. The Foundation gathers input from the Project (team leads, collaborators) and synthesizes it. This may need to evolve as the program scales. -That is a challenge. However, the grants team is expected to be a rewarding activity, as it gives team members the opportunity to support one another. +**Project manages.** The Project has deeper technical context to evaluate whether work is landing well. But Project-side management means either a volunteer committee handles it (likely unskilled at management, outside the Funding team's competency) or a dedicated person is hired for it (high overhead relative to the program size, especially early on). ## What if a Maintainer in Residence underperforms? -Performance management is the Foundation's responsibility, not the Project's. The Project treats funded maintainers the same as any team member: Code of Conduct enforcement, team membership decisions, and the normal expectations that come with being on a team. The lines are clear: the Project evaluates candidates going in; the Foundation manages the relationship after. +Performance management is the Foundation's responsibility, not the Project's. The Project treats funded maintainers the same as any team member: Code of Conduct enforcement, team membership decisions, and the normal expectations that come with being on a team. The lines are clear: the Project evaluates candidates going in; the Foundation manages the relationship after. (See also [Who manages Maintainers in Residence after they're hired?][who-manages-mirs] for discussion of alternatives.) ## What about people who only want to work part time? The RFMF targets long-term, sustained maintainers, the kind of commitment that's hard to do part time. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], $1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds deep, sustained maintenance work. +## What about sponsors who want to pay for a particular item to get done? + +That's outside the scope of the RFMF, which is undirected funding — sponsors contribute to a general fund and the Leadership Council decides how to deploy it. A companion effort, the proposed Project Goals Funding program (see [Future possibilities][]), is designed for exactly this: sponsors direct funding at specific Project Goals, and the Foundation issues grants to advance that work. Sponsors seeking that level of direction should look there rather than the RFMF. + ## What does this RFC deliberately not specify? -This RFC defines how the Project and Foundation work together to select and manage full-time funded maintainers. It deliberately does not specify how much funding the RFMF has, where that funding comes from, or how funders are solicited. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, part-time vs. full-time arrangements, evaluation criteria specifics, and reporting templates. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. +This RFC defines how the RFMF collects sponsorships, what kinds of things sponsors receive in return, and how the Project and Foundation work together to select and manage Maintainers in Residence. It deliberately does not specify how much funding the RFMF has, specific sponsorship tier structures, or detailed solicitation strategy. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, evaluation criteria specifics, and reporting templates. How the Project Priorities budget is spent is determined by the Leadership Council. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. ## What happens if we don't do this? -The Foundation will still operate its fund, but without structured Project input on who to hire or where to focus. There is more risk of misaligned funding, with money going to visible features rather than the invisible maintenance work that keeps Rust healthy. Teams continue to be precarious and isolated, and the Project misses the chance to build a coordination layer that connects willing funders to the work that needs doing. +The Foundation will still operate its fund, but without structured Project input on who to hire or where to focus, and without a clear channel for funds to flow to the Project Priorities budget. There is more risk of misaligned funding, with money going to visible features rather than the invisible maintenance work that keeps Rust healthy. Teams continue to be precarious and isolated, and the Project misses the chance to build a coordination layer that connects willing sponsors to the work that needs doing. # Prior art [prior-art]: #prior-art @@ -187,17 +267,19 @@ The Foundation will still operate its fund, but without structured Project input The PSF started its Developer in Residence program in 2021. After nearly five years, it now funds multiple maintainers, each sponsored by a specific company (Meta, Bloomberg, Alpha-Omega, Vercel, among others). Contracts are for 12 months, renewable based on continued sponsor funding. Maintainers are employees or contractors of the PSF, reporting to both the Executive Director and the Steering Council. -The program's evolution taught us several lessons we've incorporated into this RFC. First, pure maintenance work becomes draining over time. The first Developer in Residence started doing only reviews, backports, and CI, and found that after a year or two, "there's not much joy in that." Allowing feature work alongside maintenance "made all the difference." We've reflected this in the RFMF design by recommending open-ended maintenance roles rather than prescribing a rigid split. +The program's evolution taught us several lessons we've incorporated into this RFC. First, pure maintenance work becomes draining over time. The first Developer in Residence started doing only reviews, backports, and CI, and found that after a year or two, "there's not much joy in that." Allowing feature work alongside maintenance "made all the difference." We've reflected this in the RFMF design: Maintainers in Residence split their time roughly 50/50 between team priorities and individual priorities of their choosing, rather than being assigned purely to maintenance. Second, sponsors attach to people, not positions. In practice, a sponsor funding a position filled by a particular person will want to continue sponsoring that person specifically if they're happy with the work, rather than funding an abstract role. This has implications for how the Foundation thinks about sponsor relationships: sponsors care about outcomes and the people producing them. +One key difference between the PSF model and what we propose: the PSF ties each position to a specific sponsor, while the RFMF pools sponsorships and the Project decides how to allocate them. Pool funding gives the Project more flexibility — it can fund positions based on where the need is greatest rather than where a particular sponsor's interest lies, and it can sustain positions even if an individual sponsor drops out. The Scala Center provides precedent that a pool-funded model can work: sponsors contribute to a general fund at tiered levels, and the Center decides how to allocate it — an Advisory Board of sponsors makes non-binding recommendations on priorities, and the Center's leadership decides on execution and hiring. That said, we may need to adjust if pool funding proves difficult to raise — the PSF's experience shows that earmarked sponsorship can be an easier sell. The Foundation should be prepared to adapt. + Third, different sponsors want very different levels of engagement. Some are hands-off; others want detailed quarterly reports and input on how maintainers spend their time. The Foundation as an intermediary is valuable here. It buffers the relationship between sponsors and maintainers, so that maintainers aren't managing sponsor expectations directly. ## Django Fellowship: weekly reports and community-focused maintenance -The Django Fellowship program has been running since 2014, predating the PSF program and providing the longest track record of any comparable effort. Fellows are contractors (not employees), expected to commit at least 20 hours per week, with compensation explicitly described as "not competitive with full-time salaries in big cities." The position is ongoing until the Fellow chooses to step down. +The Django Fellowship program has been running since 2014, predating the PSF program and providing the longest track record of any comparable effort. Fellows are contractors (not employees) who post weekly reports. The work is focused on "housekeeping and community support": monitoring security email, fixing release blockers, reviewing pull requests, and mentoring new contributors. -Fellows post weekly reports to the django-developers mailing list, a more frequent cadence than the PSF's approach. The work is more narrowly focused on "housekeeping and community support": monitoring security email, fixing release blockers, reviewing pull requests, and mentoring new contributors. The Django model demonstrates that a maintenance-focused role can work long-term even at lower compensation, but also suggests that the pool of people willing to accept those terms is limited. +The program originally required a minimum of 20 hours per week, with compensation described as "not competitive with full-time salaries in big cities." Over time it has evolved: the program now has three Fellows, some working full-time, with compensation adjusted annually. The Django model demonstrates that a maintenance-focused role can work long-term, and that programs naturally evolve toward more hours and more competitive compensation as they prove their value — a trajectory we expect the RFMF to follow as well, starting with full-time positions from the outset. ## Zig Software Foundation: lean and independent @@ -205,16 +287,26 @@ The ZSF takes a simpler approach: core team members bill hours directly to the f The ZSF model is leaner and more informal than PSF or Django, but also smaller in scale and more dependent on individual large donations. It demonstrates that low-overhead models are possible, but the approach may not scale to the number of maintainers Rust needs. -## TC's Project Grants Program: the committee model we're building on +## Scala Center: pool-funded with sponsor engagement + +The Scala Center, housed at EPFL, takes a pool-funded approach that contrasts with the PSF's per-sponsor-per-position model. Corporate sponsors contribute to a general fund at tiered levels and send representatives to quarterly Advisory Board meetings. The Advisory Board makes non-binding recommendations on priorities; the Center's leadership decides on execution and hiring. Sponsors influence direction through discussion but don't direct specific positions or hires. + +Two aspects of the Scala Center model have been particularly influential on this RFC. First, the sponsor meeting structure: sponsors meet regularly with maintainers and with each other, and these meetings have been described as a "big win" for selling the program internally. Having sponsor representatives commit to attend regular meetings makes the program legible to upper management. Second, sponsors often value hearing from their peers — other organizations using the language — as much as from the project itself. Both of these insights shaped the RFMF's sponsor engagement design. + +The Scala Center employs engineers directly as university employees, which provides stability but depends on university infrastructure. That structural detail doesn't transfer to Rust, but the pool-funding model and sponsor engagement approach do. The Scala Center demonstrates that sponsors will contribute to a general fund without earmarking, provided they get meaningful engagement in return. + +## TC's Project Grants Program: a related committee model The Leadership Council's Project Grants Program ([RFC 3919]) establishes a $100K program supporting ~5 contributors at $1,500/month. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. -We build on the Grants team structure directly. Rather than creating a parallel committee with overlapping membership and a similar mandate, the Maintainer in Residence vetting process uses the same Grants team with additional responsibilities. This gives us selection infrastructure and an LC appointment process that already exists, and avoids fragmenting the Project's attention across multiple bodies. +The Grants team's charter overlaps significantly with the Funding team charter we define here — both involve assessing project needs and selecting candidates. The Leadership Council may choose to extend the Grants team with the Funding team's responsibilities rather than creating a separate body, which would avoid fragmenting the Project's attention across multiple committees with overlapping mandates. # Unresolved questions [unresolved-questions]: #unresolved-questions -None. +## Organizational form of the Funding team + +This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. The Funding team could be a new team, or it could be an extension of the existing Grants team established by [RFC 3919]. Future possibilities include merging the two teams or generalizing the Funding team into a broader team for supporting Rust teams. We expect the Leadership Council to determine the right organizational form. # Future possibilities [future-possibilities]: #future-possibilities @@ -223,4 +315,8 @@ None. The clearest message from our team lead interviews was that the most effective way to help teams is to add full-time, long-term maintainers. Short-term grants and scoped contracts have their place, but the problems teams described — review backlogs, cross-cutting refactors, carrying context across a complex codebase — require sustained presence. We encourage any organization looking to fund Rust maintenance to direct funding toward long-term Maintainer in Residence positions. -This RFC defines the interface between the Rust Project and the RFMF specifically, but nothing about the process is inherently RFMF-specific. The Grants team's core service — assessing where full-time maintainers would have the most impact, evaluating candidates, and returning a prioritized recommendation — could be offered to other funding organizations that want to hire Maintainers in Residence. The value proposition is the same regardless of who's paying: the Project has visibility into which teams are struggling and which candidates have the trust and context to be effective, and funding organizations benefit from that assessment rather than making hiring decisions without it. +This RFC defines the interface between the Rust Project and the RFMF specifically, but nothing about the process is inherently RFMF-specific. The Funding team's core service — assessing where full-time maintainers would have the most impact, evaluating candidates, and selecting the best candidates — could be offered to other funding organizations that want to hire Maintainers in Residence. The value proposition is the same regardless of who's paying: the Project has visibility into which teams are struggling and which candidates have the trust and context to be effective, and funding organizations benefit from that assessment rather than making hiring decisions without it. + +## Project Goals Funding program + +The RFMF provides undirected funding — sponsors contribute to a general fund and the Leadership Council decides how to deploy it. There are ongoing plans to propose a Project Goals Funding program that would allow sponsors to direct funding at specific Project Goals. Sponsors would choose goals, roadmaps, or application areas to fund, and the Foundation would issue grants to contributors working on that work. A fixed percentage of directed funding (likely 10% to start) would flow to the Leadership Council's Project Priorities budget, where it can be used to fund maintenance, project management, or other activities. Together, the two programs cover the full spectrum of sponsor needs: undirected funding for those who want to support Rust's overall health, and directed funding for those who want to accelerate specific work. From c270afd51ccf401fe077572f541fec2208238258 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 11 Mar 2026 20:07:13 -0400 Subject: [PATCH 03/18] refact: address feedback from last week --- rfcs/undirected-funds-rfc.md | 116 +++++++++++++++++------------------ 1 file changed, 57 insertions(+), 59 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 48dd2ac..ac2208b 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -5,27 +5,26 @@ # Summary [summary]: #summary -The Rust Foundation Maintainer Fund (RFMF) collects sponsorships from companies and individuals who want to support Rust's long-term health. Funds raised through the RFMF flow to the Leadership Council's Project Priorities budget. The Leadership Council determines how that budget is spent, deploying it through project grants, Maintainers in Residence, or other programs as needs evolve. +This RFC defines the relationship between the Rust Foundation Maintainer Fund (RFMF) and the open-source Rust project. The RFMF is a dedicated fund used to support Rust maintenance: open-ended, multiplicative work that improves Rust and its codebase and makes it more accessible. -This RFC recommends that the primary use of RFMF funds should be hiring full-time Maintainers in Residence — experienced, self-directed maintainers who provide the sustained presence that teams need. This RFC describes what sponsors get in return for their contributions, how Maintainer in Residence candidates are selected, what's expected of them, and how the Foundation manages the relationship. +RFMF funds are directed to the Leadership Council's Project Priorities budget and earmarked for maintainer sponsorship. The Leadership Council is empowered to design programs for using those funds — examples include the program management team and the Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. -This RFC defines a Funding team charter: staying in contact with teams to understand their needs, connecting teams to available resources, and working with the Foundation to identify and/or vet candidates for Maintainer in Residence positions. The Foundation makes the final hiring decision and handles contracting, compensation, and sponsor relations. +This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Residence work full-time (or close to full-time) on some part of the Rust project — reviews, design guidance, mentorship, refactoring, and the kind of sustained technical work that volunteers can't commit to. Their time is split roughly 50/50: half on priorities selected by team leads in their area of focus, half on priorities of their own choosing within the project. -[RFC 3919]: https://github.com/rust-lang/rfcs/pull/3919 - -### Topics for discussion +This RFC defines a Funding team charter to govern MiR selection: staying in contact with teams to understand their needs and working with the Foundation to identify and vet candidates. The Funding team and Foundation collaborate on the hiring decision; the Foundation handles contracting, compensation, and sponsor relations. We leave it to the Leadership Council to decide whether the Funding team should be merged with the Grants team proposed in [RFC 3919] or kept separate, as the Funding team's responsibilities would be a substantial increase in scope. -The following topics are not yet resolved and need committee input. Each has a corresponding FAQ entry with more detail. +Finally, this RFC describes what sponsors receive in return for their contributions. When sponsors contribute undirected funding, they are placing a bet on the Rust project as a whole — and the project should meet them in good faith. The full weight of demonstrating value should not fall on Maintainers in Residence alone; this is a program that supports the entire project, and the entire project benefits from its success. -1. **[Who manages Maintainers in Residence after they're hired?][who-manages-mirs]** The RFC currently places performance management with the Foundation. An alternative is to have the Project handle it through a dedicated (funded) resource. See the FAQ for tradeoffs. -2. **[Should the Funding team be a new team or extend the Grants team?][funding-team-org]** The RFC defines the charter but leaves organizational form to the Leadership Council. The Grants team has existing infrastructure but a narrower mandate; the Funding team charter is broader. See the FAQ for tradeoffs. +[RFC 3919]: https://github.com/rust-lang/rfcs/pull/3919 # Motivation [motivation]: #motivation -The Rust Foundation is establishing a Maintainer Fund to collect sponsorships and provide long-term funding for Rust maintenance. Funds raised through the RFMF flow to the Leadership Council's Project Priorities budget, giving the Project control over how maintenance funding is deployed. The Leadership Council commissioned this RFC to recommend how those funds should be used. Our primary recommendation is that these funds should be used to hire full-time maintainers, called "Maintainers in Residence," though the Council retains flexibility to deploy funds through other programs as needs evolve. +The Rust Foundation is establishing a Maintainer Fund to collect sponsorships and provide long-term funding for Rust maintenance. Funds raised through the RFMF are earmarked to fund Rust maintainers under the supervision of the Leadership Council. The Leadership Council commissioned this RFC to recommend how those funds should be used. -## Why full-time maintainers in residence? +Our primary recommendation is that these funds should be used to hire maintainers — called "Maintainers in Residence" — on a full-time or substantial part-time basis, though the Council retains flexibility to deploy funds in other forms such as project grants. + +## Why sustained maintainers in residence? In preparing this recommendation, we interviewed team leads across the Project. The message was clear: *"what's needed is people with the focus to drive longer-scale projects."* Volunteer maintenance keeps the lights on, but larger-scale work — clearing review backlogs, driving cross-cutting refactors, carrying context across a complex codebase — stalls because nobody has the sustained focus to push it through. As one (volunteer) team lead said, *"All the time that reviewers have goes into reviewing, triaging, and so on, and then the interesting longer-term projects just fall under the table."* @@ -36,38 +35,38 @@ The rust-analyzer experience shows what full-time presence makes possible, and w The problems teams describe require sustained, long-term presence. -## Why companies should sponsor the maintainer fund +## What kind of sponsors do we expect We expect two kinds of sponsors. First, individuals and organizations that value Rust and want to support its long-term health without any particular expectations. These will generally be smaller-dollar sponsors contributing to a project they believe in. Second, and important for the fund's sustainability, are companies that employ developers or contributors working full-time to improve Rust. These companies are invested in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" like reviewing other people's PRs, mentoring newcomers, fixing regressions, and driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. -What do sponsors get in return (besides PR and good vibes)? First, a connection to the project: RFMF sponsors will meet with project leadership, team leads, and maintainers over the course of the year. This will help them stay abreast of what is happening in the project and also let the project hear from them about their needs and priorities. Experience at other language communities shows the importance of these efforts. The Scala Center experience shows that sponsors often value hearing from their peers — other Rust-using organizations — as much as they do hearing from the project itself. Knowing what is important to sponsors is good signal on what matters to users, but it's also important for maintaining a good relationship. As one Python Developer in Residence put it, *"In terms of how \[a Developer in Residence spends their time\], sponsors can't make them do anything, but if they care about a thing, and it'll make them renew the contract for another 12 months, good to know."* Sponsors can also reach out about specific PRs or bugs that need attention (this is best effort, not an SLA). +## Why would companies sponsor the fund + +For companies that depend on Rust, what matters most is knowing that the daily work of the project continues — that good ideas won't wither on the vine for lack of reviewer bandwidth, and that bugs will be fixed promptly, particularly bugs they themselves are hitting. Sponsoring the maintainer fund is a direct investment in that capacity. -The project also highlights the work of funded maintainers via the content and project goals teams (these updates are made publicly available as well). Speaking with sponsors at the PSF confirms the importance of that kind of accountability: sponsors want to know what work would stop happening if they stopped funding. *"Very quickly that becomes the value prop when they are discussing internally whether to put in the $$."* +For the fund to be sustainable, sponsors also need to be able to report the impact of their contributions. This means the project needs to treat demonstrating impact as a whole-project responsibility, not something that falls on Maintainers in Residence alone. See [What sponsors get][] for concrete details on what we envision. ## Why the Project should drive the selection -A companion effort — the proposed Project Goals Funding program (see [Future possibilities][]) — would provide directed grants tied to specific goals, roadmaps, and application areas. But if we only fund goal-directed work, we miss a lot of what makes the Project healthy. Some teams don't directly deliver goals at all: moderation, infrastructure, release. Other work is cross-cutting and doesn't belong to any single goal but makes everyone's work go faster, such as major refactoring or CI improvements. +Much of the work that keeps Rust healthy is not obvious from the outside. Some teams don't directly deliver user-facing features at all: moderation, infrastructure, release. Other critical work is cross-cutting — clearing review backlogs, driving CI improvements, carrying context across a complex codebase. Knowing where a single dedicated person would have the most leverage requires visibility into which teams are struggling and where dependencies are blocking. -The RFMF exists to cover this gap. Its funds flow to the Leadership Council's Project Priorities budget, giving the Project control over how maintenance funding is deployed. But deciding where that funding has the most impact requires visibility into which teams are struggling, where dependencies are blocking, and where a single full-time person would have the most leverage, which is why we recommend that the Funding team (composed of active project members selected by the Leadership Council) drive the selection of who to award with a maintainer contract. +Part of the value proposition for sponsors is that they don't have to learn the intimate details of Rust project structure — they can delegate that to the Project. This is why we recommend that the Funding team (composed of active project members selected by the Leadership Council) drive the selection of who to award with a maintainer contract. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -The RFMF collects sponsorships from companies and individuals and directs those funds to the Leadership Council's Project Priorities budget. The Council deploys these funds to maintain Rust's health — primarily through Maintainers in Residence, but also through project grants, travel funding, and other programs as needs dictate. - -Maintainers in Residence are the flagship program: experienced, self-directed maintainers who do the work that keeps Rust healthy — reviews, design guidance, mentorship, unblocking, regressions, refactorings, and so forth. They are team members, not outsiders. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. The difference is that they can commit sustained time to the work that volunteers can't. +The RFMF collects sponsorships from companies and individuals. Funds support project grants, project management, and the flagship program: Maintainers in Residence — experienced, self-directed maintainers who do the work that keeps Rust healthy. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. ## Design axioms ### The RFMF is a collaboration between the Project and the Foundation -The Project brings knowledge of team health and needs; the Foundation brings logistics, sponsor relationships, and operational capacity. The Funding team (see below) identifies which areas need support and works with the Foundation to select candidates. The Foundation makes the final hiring decision and handles contracting, compensation, and sponsor relations. This is a partnership, not a handoff — both sides contribute throughout. +The Project brings knowledge of team health and needs; the Foundation brings logistics, sponsor relationships, and operational capacity. The Funding team (see below) identifies which areas need support and works with the Foundation to select candidates. The Foundation is involved in the hiring decision and handles contracting, compensation, and sponsor relations. This is a partnership, not a handoff — both sides contribute throughout. ### Engaging RFMF sponsors is a whole-project affair -The Leadership Council, team leads, and Maintainers in Residence all participate in sponsor engagement — attending meetings, discussing project direction, and learning about sponsor pain points. This benefits everyone: sponsors get a direct connection to the people doing the work, and the project learns firsthand what Rust-using organizations need. Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. +Sponsor engagement is not something Maintainers in Residence do alone — the Leadership Council, team leads, and MiRs all participate. See [What sponsors get][] for details. Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. ### Maintainers are team members, not outsiders @@ -86,36 +85,24 @@ The Project provides scaffolding — goals, program management, reporting infras RFMF sponsors contribute to a general fund and don't direct where the money goes or who gets hired. Every contribution helps fund the sustained maintenance that keeps Rust healthy. All sponsors receive public recognition and visibility into how funds are being used through regular public reports. -The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. Higher tiers provide additional benefits: +The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. Possible benefits include: -* **A community of sponsors.** The Foundation builds a community of sponsoring organizations. Sponsors meet regularly with project leadership (Leadership Council, team leads), maintainers, and each other. The Scala Center experience shows that sponsors often value hearing from their peers — other Rust-using organizations — as much as they do hearing from project leadership itself. -* **Regular engagement with project leadership and maintainers.** Meetings with Leadership Council members, team leads, and Maintainers in Residence to discuss project direction, sponsor experiences, and pain points. Maintainers also benefit from these meetings — they learn firsthand what sponsors need, which informs their priorities naturally. +* **Sponsor meetings.** The Foundation builds a community of sponsoring organizations that meets with project leadership (Leadership Council, team leads) and Maintainers in Residence a few times a year to discuss project direction, sponsor experiences, and pain points. Project leadership gains insight into the needs of major Rust users; sponsors get visibility into the roadmap and the opportunity to hear from other Rust-adopting companies. * **Best-effort attention.** Sponsors can reach out to the Foundation or project contacts about PRs or bugs that need attention. There is no SLA or guarantee — any maintainer would bump a bug report from an active user, and sponsors can reasonably expect the same consideration. This RFC does not define the tiers — that is the Foundation's domain. -The Leadership Council and Rust team members are generally expected to participate in sponsor engagement activities — attending meetings, having discussions with sponsors — as it is in the project's overall interest to encourage sponsorship. This does not imply that team members should make any technical decisions (e.g., RFC or PR approvals) that they would not have made otherwise. The project also benefits from closer contact with sponsoring organizations: they are by definition Rust-using organizations that value open-source maintenance, and it is helpful to learn about their pain points, successes, and other lessons. +Sponsor priorities and pain points are an input to the Leadership Council and Funding team when making funding decisions — not as direction, but as signal about what matters to users. -What sponsors do not get: the ability to direct a maintainer's work, pick who gets hired, bypass project processes, or influence technical decisions. +*What sponsors do not get:* the ability to direct a maintainer's work, pick who gets hired, bypass project processes, or influence technical decisions. ## The Funding team -This RFC defines a set of responsibilities we call the "Funding team" charter: - -1. **Staying in regular contact with teams** to understand their needs and the state of the project. -2. **Connecting teams to available resources** even outside MiR hiring — e.g., redirecting an existing maintainer to help with a situation, connecting a team lead to the Foundation, etc. -3. **Working with the Foundation to select MiR candidates** when positions become available, choosing candidates who'll have the most overall impact based on project needs. +This RFC defines a set of responsibilities we call the "Funding team" charter: staying in contact with teams, connecting them to resources, and working with the Foundation to select MiR candidates. The organizational structure is left to the Leadership Council. See the [reference-level explanation][reference-level-explanation] for details and [Unresolved questions][] for discussion of organizational form. -This RFC defines the charter — the responsibilities — but leaves the organizational structure to the Leadership Council. The Funding team could be a new team, or it could be an extension of the existing Grants team established by [RFC 3919]. See [Unresolved questions][] for more discussion. +## Sustained positions with balanced expectations -## Full-time positions with balanced expectations - -Maintainers in Residence are expected to spend 100% of their funded time working to improve the Rust project. Within that: - -* ~50% on **team priorities** — whatever the team needs. This could be development work (refactoring a major subsystem, rewriting the trait solver) or reactive work (reviews, mentoring, bug-fixing, triage). -* ~50% on **individual priorities of their choosing** within the project. - -This split is about team-directed vs. self-directed, not "maintenance vs. features." If the team needs the trait solver rewritten, that's team priorities. The PSF's experience after nearly five years confirms that allowing this balance "made all the difference" — pure maintenance work becomes draining over time. +Maintainers in Residence split their time roughly 50/50: half on team priorities (whatever the team needs most), half on individual priorities of their choosing within the project. This split is about team-directed vs. self-directed, not "maintenance vs. features." The PSF's experience after nearly five years confirms that allowing this balance "made all the difference" — pure maintenance work becomes draining over time. See [Maintainer in Residence expectations](#maintainer-in-residence-expectations) for details. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -128,13 +115,15 @@ The Funding team's role is to keep a pulse on the project and work with the Foun 2. **Connecting teams to available resources** — even outside MiR hiring. This might mean redirecting an existing maintainer to help with a situation, connecting a team lead to the Foundation, or surfacing resources a team didn't know existed. 3. **Working with the Foundation to select MiR candidates** — when positions become available, evaluating applicants and selecting candidates who'll have the most overall impact based on project needs. -The Funding team does not make hiring decisions; that is the Foundation's domain. The Funding team also does not manage funded maintainers after they're hired; its role ends with the selection. +The Funding team works with the Foundation on hiring decisions but does not handle contracting or compensation; that is the Foundation's domain. After hiring, the Funding team receives concerns about MiR conduct or performance and works with the Foundation to resolve them; over time, a dedicated manager role may be created (see [Who manages Maintainers in Residence after they're hired?][who-manages-mirs]). + +Beyond individual hiring decisions, the Funding team has ownership of the program's long-term health: apportioning available funds across positions, ensuring that funded work gets reported on, demonstrating return on investment to sponsors, and sustaining and growing the program over time. The RFC specifies the inputs and constraints for these decisions — project needs, team health, sponsor priorities, candidate qualifications — but delegates the decision process itself to the team, which is expected to operate transparently and document how it makes decisions. ## Application and vetting process The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. However, successful candidates must already be members of the relevant Rust team(s) with the permissions needed for the work. -Applicants provide a summary of their experience with the Rust project along with a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "refactor the codebase to be more accessible"). +Applicants provide their background and experience — both within the Rust project and professionally — along with a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "split the project into multiple independent libraries"). The Funding team prioritizes applications based on: @@ -150,9 +139,11 @@ The Funding team works with the Foundation to select from the applicant pool. Th ## Contract terms and renewal -The precise terms of the arrangement are not defined by this RFC. The arrangement is likely to begin as year-long contracts but may change to other durations, regular employment, or vary by locale. The important points are: it is a **full-time position**, and it is expected to **continue as long as both sides are satisfied and funding is available**. Compensation should be a flat rate within a small number of bands (e.g., junior and senior), rather than individually negotiated. Flat rates keep the program simple and avoid the perception that some maintainers are valued more than others for equivalent work. The compensation structure is publicly advertised as part of the call for applications. The Foundation determines the specific rates and may adjust them over time as the program learns what works and what's needed to attract strong candidates. +The precise terms of the arrangement are not defined by this RFC. The arrangement is likely to begin as year-long contracts but may change to other durations, regular employment, or vary by locale. The important points are: it is a **substantial commitment** (full-time or significant part-time), and it is expected to **continue as long as both sides are satisfied and funding is available**. Some areas may not require a full person's time; it is fine to have one person cover two areas, or two people each contribute part-time to a single area, so long as there is enough concentrated time to build and maintain deep context. -Renewal is not guaranteed: +Compensation should be a flat rate within a small number of bands (e.g., junior and senior), rather than individually negotiated. Flat rates keep the program simple and avoid the perception that some maintainers are valued more than others for equivalent work. The compensation structure is publicly advertised as part of the call for applications. The Foundation determines the specific rates and may adjust them over time as the program learns what works and what's needed to attract strong candidates. + +Renewal of contracts is expected but not guaranteed: * There may not be adequate funds available to continue the existing maintainer contracts. * The Funding team may feel that there are urgent unmet needs within the project that prompt a change in maintainer (but this is in tension with the primary goal of this RFC of providing long-term, funded maintenance; see below). @@ -193,11 +184,12 @@ To ensure continued funding, it is important that the RFMF is able to demonstrat Program managers collect progress updates from goal owners (funded or not) on a regular cadence and prepare summaries. For funded maintainers, these summaries serve double duty: they give the Project visibility into goal progress, and the Foundation can use them to prepare sponsor-facing reports. -The reporting expectations for funded maintainers are not more onerous than for volunteer contributors. The point is to reduce burden, not add it. +The reporting expectations for funded maintainers are not substantively more onerous than for volunteer contributors. The point is to reduce burden, not add it. ## Performance management The Foundation staff and the Funding team will monitor the maintainer's work and periodically solicit feedback from contributors and other team members. If they do not feel that a maintainer is doing a good job, Foundation staff are expected to provide constructive feedback to the maintainer. If the maintainer's performance does not improve, their contract will not be renewed. +As the program grows, we may wish to transition this role from a responsibility of the Foundation staff to a dedicated manager working within the project. See [the FAQ on this topic.][who-manages-mirs] Separately, Code of Conduct violations that result in removal from the Project immediately terminate the contract. Team membership is a hard requirement for the role; a maintainer who is no longer a project member cannot continue as a Maintainer in Residence. @@ -211,9 +203,9 @@ The Project does not decide whether a contract gets renewed; it provides input. This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. There are two main options: -**Extend the Grants team.** The Grants team established by [RFC 3919] already has an LC appointment process, selection infrastructure, and conflict-of-interest policies. Extending it avoids fragmenting volunteer attention across overlapping committees. +**Extend the Grants team.** The Grants team proposed in [RFC 3919] already has an LC appointment process, selection infrastructure, and conflict-of-interest policies. Extending it avoids fragmenting volunteer attention across overlapping committees. -**Create a new team.** The Funding team's charter is broader than selecting recipients — it includes staying in regular contact with teams, connecting them to resources, and understanding project health holistically. MiR selection is only one part of that mandate. A new team with a broader mandate may be a better fit than extending a team whose focus is choosing grant recipients. +**Create a new team.** The Funding team's charter is broader than selecting recipients — it includes staying in regular contact with teams, connecting them to resources, and understanding project health holistically. MiR selection is only one part of that mandate. A new team with a broader mandate may be a better fit than extending a team whose focus is choosing grant recipients. There is also a difference in operating cadence: the Grants program has predictable cycles, while the Funding team may need to react promptly when new funding becomes available rather than waiting for the next scheduled round. Current Grants team members may not have signed up for that kind of bandwidth or latency. We expect the Leadership Council to determine the right organizational form. @@ -236,29 +228,37 @@ The same way we find people for any other team. Funding team work is expected to The Funding team's role ends with the recommendation. Someone needs to synthesize feedback from the Project and make the call on performance. There are two main options: -**Foundation manages (current RFC position).** Management and performance feedback are skills, and the Foundation has professional staff experienced in them. This shouldn't be a heavy lift early on — we're selecting experienced, self-directed maintainers who are unlikely to have significant performance issues. The Foundation gathers input from the Project (team leads, collaborators) and synthesizes it. This may need to evolve as the program scales. +**Foundation manages (current RFC position).** Management and performance feedback are skills, and the Foundation has professional staff experienced in them. This shouldn't be a heavy lift early on — we're selecting experienced, self-directed maintainers who are unlikely to have significant performance issues. The Foundation gathers input from the Project (team leads, collaborators) and synthesizes it. **Project manages.** The Project has deeper technical context to evaluate whether work is landing well. But Project-side management means either a volunteer committee handles it (likely unskilled at management, outside the Funding team's competency) or a dedicated person is hired for it (high overhead relative to the program size, especially early on). +In practice, we expect this to be a phased approach. While the program has relatively few maintainers, the Foundation provides management skill and the Funding team provides feedback as an input. As the program grows, a dedicated support role may emerge — someone who meets with MiRs regularly, helps them build a portfolio of their work, and serves as the point of contact when teams have concerns. Whether that role lives within the Foundation, the Project, or somewhere in between is a question that becomes more important at scale and can be revisited as the program learns what it needs. + ## What if a Maintainer in Residence underperforms? -Performance management is the Foundation's responsibility, not the Project's. The Project treats funded maintainers the same as any team member: Code of Conduct enforcement, team membership decisions, and the normal expectations that come with being on a team. The lines are clear: the Project evaluates candidates going in; the Foundation manages the relationship after. (See also [Who manages Maintainers in Residence after they're hired?][who-manages-mirs] for discussion of alternatives.) +See the ["Who manages MiR"][who-manages-mirs] question. ## What about people who only want to work part time? -The RFMF targets long-term, sustained maintainers, the kind of commitment that's hard to do part time. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], $1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds deep, sustained maintenance work. +Maintainers in Residence can work substantial part-time — the key requirement is enough concentrated time to build and maintain deep context, not necessarily a 40-hour week. Some areas may not need a full person's time, and it's fine to have one person cover two areas or two people each contribute part-time to a single area. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], $1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds sustained maintenance work from people with deep context. ## What about sponsors who want to pay for a particular item to get done? That's outside the scope of the RFMF, which is undirected funding — sponsors contribute to a general fund and the Leadership Council decides how to deploy it. A companion effort, the proposed Project Goals Funding program (see [Future possibilities][]), is designed for exactly this: sponsors direct funding at specific Project Goals, and the Foundation issues grants to advance that work. Sponsors seeking that level of direction should look there rather than the RFMF. +## Why are RFMF funds earmarked for maintainers? + +Sponsors contributing to the RFMF want to know their money is going directly to fund maintainers. Earmarking gives the fund a clear value proposition: every dollar goes to paying people who maintain Rust. Without earmarking, the Leadership Council could use RFMF funds for any purpose — travel grants, event sponsorship, infrastructure — all valuable, but harder to explain to a company evaluating its return on investment. Since money is fungible, earmarking RFMF funds for maintainers also frees up other budget for those other purposes. + +The earmark is broad: Maintainers in Residence, project grants, and the program management overhead needed to support them. The Leadership Council determines the specific form. This gives the Council real flexibility while keeping the fund's purpose legible to sponsors. + ## What does this RFC deliberately not specify? -This RFC defines how the RFMF collects sponsorships, what kinds of things sponsors receive in return, and how the Project and Foundation work together to select and manage Maintainers in Residence. It deliberately does not specify how much funding the RFMF has, specific sponsorship tier structures, or detailed solicitation strategy. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, evaluation criteria specifics, and reporting templates. How the Project Priorities budget is spent is determined by the Leadership Council. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. +This RFC defines how the RFMF collects sponsorships, what kinds of things sponsors receive in return, and how the Project and Foundation work together to select and manage Maintainers in Residence. It deliberately does not specify how much funding the RFMF has, specific sponsorship tier structures, or detailed solicitation strategy. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, evaluation criteria specifics, and reporting templates. RFMF funds are earmarked for funding maintainers, but the Leadership Council determines the specific form. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. ## What happens if we don't do this? -The Foundation will still operate its fund, but without structured Project input on who to hire or where to focus, and without a clear channel for funds to flow to the Project Priorities budget. There is more risk of misaligned funding, with money going to visible features rather than the invisible maintenance work that keeps Rust healthy. Teams continue to be precarious and isolated, and the Project misses the chance to build a coordination layer that connects willing sponsors to the work that needs doing. +The Foundation will still operate its fund, but without structured Project input on who to hire or where to focus, and without a clear earmark ensuring funds go to maintainers. There is more risk of misaligned funding, with money going to visible features rather than the invisible maintenance work that keeps Rust healthy. Teams continue to be precarious and isolated, and the Project misses the chance to build a coordination layer that connects willing sponsors to the work that needs doing. # Prior art [prior-art]: #prior-art @@ -279,7 +279,7 @@ Third, different sponsors want very different levels of engagement. Some are han The Django Fellowship program has been running since 2014, predating the PSF program and providing the longest track record of any comparable effort. Fellows are contractors (not employees) who post weekly reports. The work is focused on "housekeeping and community support": monitoring security email, fixing release blockers, reviewing pull requests, and mentoring new contributors. -The program originally required a minimum of 20 hours per week, with compensation described as "not competitive with full-time salaries in big cities." Over time it has evolved: the program now has three Fellows, some working full-time, with compensation adjusted annually. The Django model demonstrates that a maintenance-focused role can work long-term, and that programs naturally evolve toward more hours and more competitive compensation as they prove their value — a trajectory we expect the RFMF to follow as well, starting with full-time positions from the outset. +The program originally required a minimum of 20 hours per week, with compensation described as "not competitive with full-time salaries in big cities." Over time it has evolved: the program now has three Fellows, some working full-time, with compensation adjusted annually. The Django model demonstrates that a maintenance-focused role can work long-term, and that programs naturally evolve toward more hours and more competitive compensation as they prove their value. ## Zig Software Foundation: lean and independent @@ -297,7 +297,7 @@ The Scala Center employs engineers directly as university employees, which provi ## TC's Project Grants Program: a related committee model -The Leadership Council's Project Grants Program ([RFC 3919]) establishes a $100K program supporting ~5 contributors at $1,500/month. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. +The Leadership Council's Project Grants Program ([RFC 3919]) proposes a $100K program supporting ~5 contributors at $1,500/month. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. The Grants team's charter overlaps significantly with the Funding team charter we define here — both involve assessing project needs and selecting candidates. The Leadership Council may choose to extend the Grants team with the Funding team's responsibilities rather than creating a separate body, which would avoid fragmenting the Project's attention across multiple committees with overlapping mandates. @@ -306,17 +306,15 @@ The Grants team's charter overlaps significantly with the Funding team charter w ## Organizational form of the Funding team -This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. The Funding team could be a new team, or it could be an extension of the existing Grants team established by [RFC 3919]. Future possibilities include merging the two teams or generalizing the Funding team into a broader team for supporting Rust teams. We expect the Leadership Council to determine the right organizational form. +This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. The Funding team could be a new team, or it could be an extension of the Grants team proposed in [RFC 3919]. Future possibilities include merging the two teams or generalizing the Funding team into a broader team for supporting Rust teams. We expect the Leadership Council to determine the right organizational form. # Future possibilities [future-possibilities]: #future-possibilities ## Extending the vetting service to other funding organizations -The clearest message from our team lead interviews was that the most effective way to help teams is to add full-time, long-term maintainers. Short-term grants and scoped contracts have their place, but the problems teams described — review backlogs, cross-cutting refactors, carrying context across a complex codebase — require sustained presence. We encourage any organization looking to fund Rust maintenance to direct funding toward long-term Maintainer in Residence positions. - -This RFC defines the interface between the Rust Project and the RFMF specifically, but nothing about the process is inherently RFMF-specific. The Funding team's core service — assessing where full-time maintainers would have the most impact, evaluating candidates, and selecting the best candidates — could be offered to other funding organizations that want to hire Maintainers in Residence. The value proposition is the same regardless of who's paying: the Project has visibility into which teams are struggling and which candidates have the trust and context to be effective, and funding organizations benefit from that assessment rather than making hiring decisions without it. +This RFC defines the interface between the Rust Project and the RFMF specifically, but nothing about the process is inherently RFMF-specific. The Funding team's core service — assessing where dedicated maintainers would have the most impact, evaluating candidates, and selecting the best candidates — could be offered to other funding organizations that want to hire Maintainers in Residence. The value proposition is the same regardless of who's paying: the Project has visibility into which teams are struggling and which candidates have the trust and context to be effective, and funding organizations benefit from that assessment rather than making hiring decisions without it. ## Project Goals Funding program -The RFMF provides undirected funding — sponsors contribute to a general fund and the Leadership Council decides how to deploy it. There are ongoing plans to propose a Project Goals Funding program that would allow sponsors to direct funding at specific Project Goals. Sponsors would choose goals, roadmaps, or application areas to fund, and the Foundation would issue grants to contributors working on that work. A fixed percentage of directed funding (likely 10% to start) would flow to the Leadership Council's Project Priorities budget, where it can be used to fund maintenance, project management, or other activities. Together, the two programs cover the full spectrum of sponsor needs: undirected funding for those who want to support Rust's overall health, and directed funding for those who want to accelerate specific work. +The RFMF provides undirected funding — sponsors contribute to a general fund earmarked to fund Rust maintainers, with the Leadership Council deciding the specific form. There are ongoing plans to propose a Project Goals Funding program that would allow sponsors to direct funding at specific Project Goals. Sponsors would choose goals, roadmaps, or application areas to fund, and the Foundation would issue grants to contributors working on that work. A fixed percentage of directed funding (likely 10% to start) would flow to the Leadership Council's Project Priorities budget, where it can be used to fund maintenance, project management, or other activities. Together, the two programs cover the full spectrum of sponsor needs: undirected funding for those who want to support Rust's overall health, and directed funding for those who want to accelerate specific work. From 84cba63c658616d7c32bffcadca9475e1e0cbbe5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 12 Mar 2026 14:17:13 -0400 Subject: [PATCH 04/18] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jakub Beránek --- rfcs/undirected-funds-rfc.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index ac2208b..e11c631 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -7,9 +7,9 @@ This RFC defines the relationship between the Rust Foundation Maintainer Fund (RFMF) and the open-source Rust project. The RFMF is a dedicated fund used to support Rust maintenance: open-ended, multiplicative work that improves Rust and its codebase and makes it more accessible. -RFMF funds are directed to the Leadership Council's Project Priorities budget and earmarked for maintainer sponsorship. The Leadership Council is empowered to design programs for using those funds — examples include the program management team and the Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. +The Leadership Council has a Project Priorities budget, which is used to fund various initiatives, such as travel grants or program management. RFMF funds will be directed to this budget, but they will be earmarked for maintainer sponsorship. That means that they can be used only for activities that directly support Rust Project maintainers, which might include the program management program or the Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. We propose a new funding program for supporting maintainers described below, which should be the primary target of these earmarked funds. -This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Residence work full-time (or close to full-time) on some part of the Rust project — reviews, design guidance, mentorship, refactoring, and the kind of sustained technical work that volunteers can't commit to. Their time is split roughly 50/50: half on priorities selected by team leads in their area of focus, half on priorities of their own choosing within the project. +This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Residence work full-time (or close to full-time) on some part of the Rust project — reviews, design guidance, mentorship, refactoring, and the kind of sustained technical work that volunteers can't commit to. Their time is split roughly 50/50: half on priorities guided by team leads in their area of focus, half on priorities of their own choosing within the project. This RFC defines a Funding team charter to govern MiR selection: staying in contact with teams to understand their needs and working with the Foundation to identify and vet candidates. The Funding team and Foundation collaborate on the hiring decision; the Foundation handles contracting, compensation, and sponsor relations. We leave it to the Leadership Council to decide whether the Funding team should be merged with the Grants team proposed in [RFC 3919] or kept separate, as the Funding team's responsibilities would be a substantial increase in scope. @@ -102,7 +102,7 @@ This RFC defines a set of responsibilities we call the "Funding team" charter: s ## Sustained positions with balanced expectations -Maintainers in Residence split their time roughly 50/50: half on team priorities (whatever the team needs most), half on individual priorities of their choosing within the project. This split is about team-directed vs. self-directed, not "maintenance vs. features." The PSF's experience after nearly five years confirms that allowing this balance "made all the difference" — pure maintenance work becomes draining over time. See [Maintainer in Residence expectations](#maintainer-in-residence-expectations) for details. +Maintainers in Residence split their time roughly 50/50: half on team priorities (whatever the team needs most), half on individual priorities of their choosing within the project (with the expectation that most of it will be near the designated area). This split is about team-directed vs. self-directed, not "maintenance vs. features." The PSF's experience after nearly five years confirms that allowing this balance "made all the difference" — pure maintenance work becomes draining over time. See [Maintainer in Residence expectations](#maintainer-in-residence-expectations) for details. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -240,7 +240,7 @@ See the ["Who manages MiR"][who-manages-mirs] question. ## What about people who only want to work part time? -Maintainers in Residence can work substantial part-time — the key requirement is enough concentrated time to build and maintain deep context, not necessarily a 40-hour week. Some areas may not need a full person's time, and it's fine to have one person cover two areas or two people each contribute part-time to a single area. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], $1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds sustained maintenance work from people with deep context. +Maintainers in Residence can work substantial part-time — the key requirement is enough concentrated time to build and maintain deep context, not necessarily a 40-hour week. Some areas may not need a full person's time, and it's fine to have one person cover two areas or two people each contribute part-time to a single area. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], ~$1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds sustained maintenance work from people with deep context. ## What about sponsors who want to pay for a particular item to get done? @@ -295,7 +295,7 @@ Two aspects of the Scala Center model have been particularly influential on this The Scala Center employs engineers directly as university employees, which provides stability but depends on university infrastructure. That structural detail doesn't transfer to Rust, but the pool-funding model and sponsor engagement approach do. The Scala Center demonstrates that sponsors will contribute to a general fund without earmarking, provided they get meaningful engagement in return. -## TC's Project Grants Program: a related committee model +## Project Grants Program: a related committee model The Leadership Council's Project Grants Program ([RFC 3919]) proposes a $100K program supporting ~5 contributors at $1,500/month. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. From 772d81a1bbd08b6d7081a7f30c80d47d13a1b70f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 12 Mar 2026 17:25:40 -0400 Subject: [PATCH 05/18] fix: updates based on our discussion today --- rfcs/undirected-funds-rfc.md | 117 ++++++++++++++++++++--------------- 1 file changed, 66 insertions(+), 51 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index e11c631..639e05f 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -9,11 +9,11 @@ This RFC defines the relationship between the Rust Foundation Maintainer Fund (R The Leadership Council has a Project Priorities budget, which is used to fund various initiatives, such as travel grants or program management. RFMF funds will be directed to this budget, but they will be earmarked for maintainer sponsorship. That means that they can be used only for activities that directly support Rust Project maintainers, which might include the program management program or the Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. We propose a new funding program for supporting maintainers described below, which should be the primary target of these earmarked funds. -This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Residence work full-time (or close to full-time) on some part of the Rust project — reviews, design guidance, mentorship, refactoring, and the kind of sustained technical work that volunteers can't commit to. Their time is split roughly 50/50: half on priorities guided by team leads in their area of focus, half on priorities of their own choosing within the project. +This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Residence have dedicated time to focus on some part of the Rust project. Their time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the project. -This RFC defines a Funding team charter to govern MiR selection: staying in contact with teams to understand their needs and working with the Foundation to identify and vet candidates. The Funding team and Foundation collaborate on the hiring decision; the Foundation handles contracting, compensation, and sponsor relations. We leave it to the Leadership Council to decide whether the Funding team should be merged with the Grants team proposed in [RFC 3919] or kept separate, as the Funding team's responsibilities would be a substantial increase in scope. +Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" appointed by the Leadership Council. This Funding team will weigh the set of applications against the project's needs and priorities. -Finally, this RFC describes what sponsors receive in return for their contributions. When sponsors contribute undirected funding, they are placing a bet on the Rust project as a whole — and the project should meet them in good faith. The full weight of demonstrating value should not fall on Maintainers in Residence alone; this is a program that supports the entire project, and the entire project benefits from its success. +The Funding team is additionally charged with ensuring the program's overall success. When sponsors contribute undirected funding, they are investing in the Rust project as a whole — and the project should meet them in good faith. The rest of the project is expected to help the Funding team manage sponsor relations, e.g., by meeting with sponsors or providing other reasonable sponsor benefits. [RFC 3919]: https://github.com/rust-lang/rfcs/pull/3919 @@ -41,6 +41,8 @@ We expect two kinds of sponsors. First, individuals and organizations that value Second, and important for the fund's sustainability, are companies that employ developers or contributors working full-time to improve Rust. These companies are invested in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" like reviewing other people's PRs, mentoring newcomers, fixing regressions, and driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. +Additionally, the proposed Project Goals Funding program (see [Future possibilities][]) would direct a percentage of directed funding into the RFMF, providing another revenue stream for maintenance work. + ## Why would companies sponsor the fund For companies that depend on Rust, what matters most is knowing that the daily work of the project continues — that good ideas won't wither on the vine for lack of reviewer bandwidth, and that bugs will be fixed promptly, particularly bugs they themselves are hitting. Sponsoring the maintainer fund is a direct investment in that capacity. @@ -64,11 +66,11 @@ The RFMF collects sponsorships from companies and individuals. Funds support pro The Project brings knowledge of team health and needs; the Foundation brings logistics, sponsor relationships, and operational capacity. The Funding team (see below) identifies which areas need support and works with the Foundation to select candidates. The Foundation is involved in the hiring decision and handles contracting, compensation, and sponsor relations. This is a partnership, not a handoff — both sides contribute throughout. -### Engaging RFMF sponsors is a whole-project affair +### The Project helps maintainers demonstrate their impact -Sponsor engagement is not something Maintainers in Residence do alone — the Leadership Council, team leads, and MiRs all participate. See [What sponsors get][] for details. Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. +Sponsor engagement is not something Maintainers in Residence do alone — the Leadership Council, team leads, and MiRs all participate. The Project provides scaffolding — goals, program management, reporting infrastructure — so maintainers can focus on the work while sponsors get visibility into outcomes. See [What sponsors get][] for details. Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. -### Maintainers are team members, not outsiders +### Maintainers are team members Maintainer in Residence candidates must already be members of the relevant Rust team(s) with the permissions needed for the work — reviewing PRs, championing goals, and performing actions limited to official team members. This is a hard requirement, not just an expectation. Funded maintainers are not a separate class of contributor — they're existing team members who can now commit sustained time. @@ -76,33 +78,36 @@ Maintainer in Residence candidates must already be members of the relevant Rust The RFMF doesn't try to be the sole channel for funding Rust maintenance. The Maintainer in Residence program fills a specific role: allowing project teams to select and direct maintainers toward the areas they identify as most critical. Other structures — the proposed Project Goals Funding program for directed grants (see [Future possibilities][]), the Project Grants Program for contributor stipends, the Rust-Analyzer Open Collective, the proposed RustNL Maintainer Fund, company employment — serve complementary roles. -### The Project helps maintainers demonstrate their impact - -The Project provides scaffolding — goals, program management, reporting infrastructure — so maintainers can focus on the work while sponsors get visibility into outcomes. - ## What sponsors get [what-sponsors-get]: #what-sponsors-get RFMF sponsors contribute to a general fund and don't direct where the money goes or who gets hired. Every contribution helps fund the sustained maintenance that keeps Rust healthy. All sponsors receive public recognition and visibility into how funds are being used through regular public reports. -The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. Possible benefits include: +The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. The specific tiers are best determined over time by the Foundation and Funding team, but they could include benefits like the following: * **Sponsor meetings.** The Foundation builds a community of sponsoring organizations that meets with project leadership (Leadership Council, team leads) and Maintainers in Residence a few times a year to discuss project direction, sponsor experiences, and pain points. Project leadership gains insight into the needs of major Rust users; sponsors get visibility into the roadmap and the opportunity to hear from other Rust-adopting companies. +* **Impact reporting.** Regular reports on what funded maintainers are working on, progress on Project Goals, and how the program is contributing to Rust's health. These reports are prepared with help from the program management team and made publicly available. * **Best-effort attention.** Sponsors can reach out to the Foundation or project contacts about PRs or bugs that need attention. There is no SLA or guarantee — any maintainer would bump a bug report from an active user, and sponsors can reasonably expect the same consideration. -This RFC does not define the tiers — that is the Foundation's domain. +These are reasonable expectations that don't compromise the Project's independence — they represent the kind of engagement any healthy open-source project should provide to its supporters. -Sponsor priorities and pain points are an input to the Leadership Council and Funding team when making funding decisions — not as direction, but as signal about what matters to users. +*What sponsors do not get:* the ability to unilaterally direct a maintainer's work, pick who gets hired, pick who gets added to project teams, bypass project processes, or influence technical decisions. -*What sponsors do not get:* the ability to direct a maintainer's work, pick who gets hired, bypass project processes, or influence technical decisions. +## Selection process is driven by a team within the project, supported by Foundation staff -## The Funding team +When funding is available, the Funding team and Foundation put out an open call for applications. The Funding team and Foundation staff review applications, consider the project's needs, and then the Foundation makes offers to the strongest candidates. + +## The Funding team owns the project's long-term success and interfaces with maintainers-in-residence + +The Funding team owns the program's overall success. They keep up with teams to understand where support is needed and how well the program is working; they can adjust aspects of the program to make it work better over time. + +If there are concerns about a MiR, they can be raised to the funding team. The team will gather context and work with the Foundation manager to resolve the concern. Typically this means a conversation that brings about a change in behavior. In extreme cases, this might include performance management options like terminating a contract or opting not to renew. -This RFC defines a set of responsibilities we call the "Funding team" charter: staying in contact with teams, connecting them to resources, and working with the Foundation to select MiR candidates. The organizational structure is left to the Leadership Council. See the [reference-level explanation][reference-level-explanation] for details and [Unresolved questions][] for discussion of organizational form. +*Unresolved question:* We are describing the Funding team as if they are a distinct team. As described in the [Unresolved questions][], the Leadership Council may opt to instead grow the scope of an existing team like the Grants team. -## Sustained positions with balanced expectations +## What Maintainers in Residence do -Maintainers in Residence split their time roughly 50/50: half on team priorities (whatever the team needs most), half on individual priorities of their choosing within the project (with the expectation that most of it will be near the designated area). This split is about team-directed vs. self-directed, not "maintenance vs. features." The PSF's experience after nearly five years confirms that allowing this balance "made all the difference" — pure maintenance work becomes draining over time. See [Maintainer in Residence expectations](#maintainer-in-residence-expectations) for details. +Maintainers in Residence split their time between team priorities and individual priorities of their own choosing within their area of focus. The exact balance varies depending on the individual, their experience, and the needs of the team — the important thing is that both team-directed and self-directed work are expected. This is about "team-directed vs. self-directed," not "maintenance vs. features." The PSF's experience after nearly five years confirms that focusing purely on team-directed needs and multiplicative maintenance can be very draining; giving time for self-directed projects "made all the difference" in satisfaction. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -114,28 +119,31 @@ The Funding team's role is to keep a pulse on the project and work with the Foun 1. **Staying in regular contact with teams** — meeting regularly with team leads and members to understand their needs, health, and where support would have the most impact. 2. **Connecting teams to available resources** — even outside MiR hiring. This might mean redirecting an existing maintainer to help with a situation, connecting a team lead to the Foundation, or surfacing resources a team didn't know existed. 3. **Working with the Foundation to select MiR candidates** — when positions become available, evaluating applicants and selecting candidates who'll have the most overall impact based on project needs. +4. **Collecting feedback on how well the program and the MiRs are working** — as the team responsible for selecting which maintainers to hire, the Funding team is also the team responsible for fielding feedback on how well those decisions work out and making adjustments as needed. -The Funding team works with the Foundation on hiring decisions but does not handle contracting or compensation; that is the Foundation's domain. After hiring, the Funding team receives concerns about MiR conduct or performance and works with the Foundation to resolve them; over time, a dedicated manager role may be created (see [Who manages Maintainers in Residence after they're hired?][who-manages-mirs]). +The Foundation supports the Funding team with logistics. The Foundation issues contracts or manages employment. They provide managerial support to convey feedback. + +We expect that initially this managerial work can be managed by existing Foundation staff. If the program grows to a large number of MiR, however, we recommend that the Leadership Council use some portion of the RFMF funds to hire a dedicated manager who would work closely with the Funding team (see [Who manages Maintainers in Residence after they're hired?][who-manages-mirs]). Beyond individual hiring decisions, the Funding team has ownership of the program's long-term health: apportioning available funds across positions, ensuring that funded work gets reported on, demonstrating return on investment to sponsors, and sustaining and growing the program over time. The RFC specifies the inputs and constraints for these decisions — project needs, team health, sponsor priorities, candidate qualifications — but delegates the decision process itself to the team, which is expected to operate transparently and document how it makes decisions. ## Application and vetting process -The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. However, successful candidates must already be members of the relevant Rust team(s) with the permissions needed for the work. +The process of contracting a new Maintainer in Residence begins with an open call for applications. Any member of a Rust team or person to whom team membership has been offered can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. -Applicants provide their background and experience — both within the Rust project and professionally — along with a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "split the project into multiple independent libraries"). +Applicants provide (1) their background and experience — both within the Rust project and professionally; (2) their availability (full-time, part-time, etc); and (3) a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "split project `foo` into multiple independent libraries `bar` and `baz`"). The Funding team prioritizes applications based on: 1. conversations with team leads and team members to assess what support is most urgently needed; 2. the applicant's history with the project; 3. any specific work that was proposed in the application; -4. the results of interviews or conversations with the applicant; and -5. any history of interpersonal or Code-of-Conduct issues known to the moderation team. +4. the applicant's availability and whether it suffices for the tasks they expect to perform; +5. the results of interviews or conversations with the applicant; and +6. any history of interpersonal or Code-of-Conduct issues known to the moderation team. -The Funding team evaluates applicants on three dimensions: technical depth in the relevant area, community standing and trust within the Project, and sustained work orientation (whether the candidate's track record suggests they'll thrive in a role focused on reviews, mentorship, unblocking, and the kind of long-term technical work that requires deep context). +The Funding team works with the Foundation to select from the applicant pool and to extend offers. The Funding team is looking for maintainers that have technical depth in the relevant area, community standing and trust within the Project, and sustained work orientation (a track record that suggests they'll thrive in a role focused on reviews, mentorship, unblocking, and the kind of long-term technical work that requires deep context). -The Funding team works with the Foundation to select from the applicant pool. The Foundation makes the final decision on who receives the contract, but the expectation is that it will follow the Funding team's recommendation. There may be practical reasons (salary expectations, availability, fit) that lead to a different choice. The fact that applications are open is public; the prioritized recommendations and individual feedback are confidential between the Funding team and the Foundation. ## Contract terms and renewal @@ -155,14 +163,16 @@ In advance of contract renewal, the Foundation will consult with the Funding tea ## Maintainer in Residence expectations -Maintainers in Residence are expected to spend 100% of their funded time working to improve the Rust project. Within that: +Maintainers in Residence are expected to spend 100% of their funded time working to improve the Rust project. That funded time can be split between: + +* **Team priorities** — items that are prioritized by the team(s) that the maintainer belongs to. This includes reviews, mentoring, bug-fixing, triage, and larger development work like refactors or subsystem rewrites. +* **Self-selected items** — work of the individual's choosing. -* ~50% on **team priorities** — whatever the team identifies as most important. This includes reviews, mentoring, bug-fixing, triage, and larger development work like refactors or subsystem rewrites. -* ~50% on **individual priorities of their choosing** within the project. +We expect an approximately 50/50 split between these two, but the exact split will vary depending on the individual, their experience, and the needs of the team. The Funding team should monitor and make sure that team priorities are being adequately served, while also ensuring that MiR have the opportunity to pursue self-selected work. If both cannot be done, that likely indicates the need for another MiR in that area. Maintainers in Residence are also expected to: -* resolve time-critical issues such as newly reported bugs; +* resolve time-critical issues such as urgent bugs; * champion Project Goals supported by their respective teams, even if they themselves might not have championed that goal as an individual; * work with the Project to ensure their work gets regularly reported on; * remain a member of the Project and relevant teams, in good standing. @@ -175,20 +185,22 @@ Requests that go beyond this — "develop this feature" or "devote sustained tim ## Reporting and impact visibility -Funded maintainers participate in the Project Goals process the same way any other team member does. If they champion a goal, they show up in the goal's tracking and reporting. If they provide review bandwidth for a goal, that's reflected in the goal's progress updates. There is no separate reporting track for funded maintainers; the Goals program is the reporting infrastructure. -To ensure continued funding, it is important that the RFMF is able to demonstrate impact and value to its sponsors. The entire Project has a stake in maintainers demonstrating impact, and other teams are expected to assist: +While MiR are expected to help collect data for reporting, they will be supported by the project, and the overall reporting expectations should not be substantively more onerous than for volunteer contributors. The point is to reduce burden, not add it. + +Examples of project support include: * The program management team will prepare an initial draft by examining GitHub activity (PR reviews, etc.) and via updates on Project Goals championed by the maintainer. * The Content team will interview maintainers and highlight their work. Program managers collect progress updates from goal owners (funded or not) on a regular cadence and prepare summaries. For funded maintainers, these summaries serve double duty: they give the Project visibility into goal progress, and the Foundation can use them to prepare sponsor-facing reports. -The reporting expectations for funded maintainers are not substantively more onerous than for volunteer contributors. The point is to reduce burden, not add it. - ## Performance management -The Foundation staff and the Funding team will monitor the maintainer's work and periodically solicit feedback from contributors and other team members. If they do not feel that a maintainer is doing a good job, Foundation staff are expected to provide constructive feedback to the maintainer. If the maintainer's performance does not improve, their contract will not be renewed. +The Foundation staff and the Funding team will monitor the maintainer's work and periodically solicit feedback from contributors and other team members. The moderation team is encouraged to inform the Funding team and/or Foundation about any reported issues relevant to a MiR's conduct. + +If a maintainer is not performing well, Foundation staff are expected to provide constructive feedback. If performance does not improve, the Foundation may decline to renew the contract or, in serious cases, terminate it early. The Foundation is responsible for the operational side of these decisions (contract changes, termination). + As the program grows, we may wish to transition this role from a responsibility of the Foundation staff to a dedicated manager working within the project. See [the FAQ on this topic.][who-manages-mirs] Separately, Code of Conduct violations that result in removal from the Project immediately terminate the contract. Team membership is a hard requirement for the role; a maintainer who is no longer a project member cannot continue as a Maintainer in Residence. @@ -198,22 +210,13 @@ The Project does not decide whether a contract gets renewed; it provides input. # Frequently asked questions [faq]: #faq -## How will the Funding team be organized? -[funding-team-org]: #how-will-the-funding-team-be-organized - -This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. There are two main options: - -**Extend the Grants team.** The Grants team proposed in [RFC 3919] already has an LC appointment process, selection infrastructure, and conflict-of-interest policies. Extending it avoids fragmenting volunteer attention across overlapping committees. - -**Create a new team.** The Funding team's charter is broader than selecting recipients — it includes staying in regular contact with teams, connecting them to resources, and understanding project health holistically. MiR selection is only one part of that mandate. A new team with a broader mandate may be a better fit than extending a team whose focus is choosing grant recipients. There is also a difference in operating cadence: the Grants program has predictable cycles, while the Funding team may need to react promptly when new funding becomes available rather than waiting for the next scheduled round. Current Grants team members may not have signed up for that kind of bandwidth or latency. - -We expect the Leadership Council to determine the right organizational form. - ## What does it look like to have a Maintainer in Residence on my team? In one sense, the same as having any other team member. They show up in reviews, participate in design discussions, mentor newcomers, and work on what the team needs. The PSF's experience after nearly five years is instructive: the Developer in Residence does roughly 50/50 maintenance and proactive work, and the role feels like "just another team member" rather than an outside presence. -But there is an important difference beyond just having more time. Most team members are volunteers, and team leads can't ask volunteers to take on specific tasks — they can only hope someone steps up. A Maintainer in Residence, by contrast, has dedicated half their time to team priorities. Team leadership should feel free to ask a MiR to take on high-priority work that nobody else can tackle — championing a goal, driving a critical refactor, clearing a review backlog — so long as it fits within that team-priorities capacity. This is a resource that team leads have never had before, and it changes the dynamic from "hoping someone volunteers" to "directing sustained effort where it's needed most." +But there is an important difference beyond just having more time. Most team members are volunteers, and teams can't ask volunteers to take on specific tasks — they can only hope someone steps up. A Maintainer in Residence, by contrast, has dedicated part of their time to team priorities. The team should feel free to ask a MiR to take on high-priority work that nobody else can tackle — championing a goal, driving a critical refactor, clearing a review backlog — so long as it fits within that team-priorities capacity. This is a resource that teams have never had before, and it changes the dynamic from "hoping someone volunteers" to "directing sustained effort where it's needed most." + +While MiRs should help teams with their needs, they also have a right to reserve time for their own priorities. MiR can feel free to decline to work on team priorities past a certain point. The Funding team will help to negotiate this balance as needed. ## Why not a flexible contractor pool instead of long-term maintainers? @@ -240,7 +243,7 @@ See the ["Who manages MiR"][who-manages-mirs] question. ## What about people who only want to work part time? -Maintainers in Residence can work substantial part-time — the key requirement is enough concentrated time to build and maintain deep context, not necessarily a 40-hour week. Some areas may not need a full person's time, and it's fine to have one person cover two areas or two people each contribute part-time to a single area. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919], ~$1,500/month) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds sustained maintenance work from people with deep context. +Maintainers in Residence can work substantial part-time — the key requirement is enough concentrated time to build and maintain deep context, not necessarily a 40-hour week. Some areas may not need a full person's time, and it's fine to have one person cover two areas or two people each contribute part-time to a single area. For contributors who want lighter-touch support, the LC's Project Grants Program ([RFC 3919]) is designed for exactly that. The two programs are complementary: grants support a broad base of contributors; the RFMF funds sustained maintenance work from people with deep context. ## What about sponsors who want to pay for a particular item to get done? @@ -254,7 +257,7 @@ The earmark is broad: Maintainers in Residence, project grants, and the program ## What does this RFC deliberately not specify? -This RFC defines how the RFMF collects sponsorships, what kinds of things sponsors receive in return, and how the Project and Foundation work together to select and manage Maintainers in Residence. It deliberately does not specify how much funding the RFMF has, specific sponsorship tier structures, or detailed solicitation strategy. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, evaluation criteria specifics, and reporting templates. RFMF funds are earmarked for funding maintainers, but the Leadership Council determines the specific form. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. +This RFC defines how the RFMF collects sponsorships, the benefits sponsors receive, and how the Project and Foundation work together to select and manage Maintainers in Residence. It deliberately does not specify how much funding the RFMF has, specific sponsorship tier structures, or detailed solicitation strategy. It also leaves operational details to the Foundation: compensation levels, detailed contract terms, evaluation criteria specifics, and reporting templates. RFMF funds are earmarked for funding maintainers, but the Leadership Council determines how much of those funds to use for MiR vs Project Grants vs other programs. The broad shape described here is a recommendation, subject to modification over time as the program learns what works. ## What happens if we don't do this? @@ -297,7 +300,7 @@ The Scala Center employs engineers directly as university employees, which provi ## Project Grants Program: a related committee model -The Leadership Council's Project Grants Program ([RFC 3919]) proposes a $100K program supporting ~5 contributors at $1,500/month. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. +The Project Grants Program ([RFC 3919]) proposes a program supporting a handful of contributors with modest monthly stipends. It charters a Grants team (5 members, LC-appointed, organized as a Launching Pad subteam) to select recipients and oversee the program. The RFC explicitly positions itself as "distinct from, but complementary to" the RFMF: grants are smaller-scale, flexible, Project-controlled support, while the RFMF targets larger-scale, sustained maintenance. The Grants team's charter overlaps significantly with the Funding team charter we define here — both involve assessing project needs and selecting candidates. The Leadership Council may choose to extend the Grants team with the Funding team's responsibilities rather than creating a separate body, which would avoid fragmenting the Project's attention across multiple committees with overlapping mandates. @@ -305,8 +308,15 @@ The Grants team's charter overlaps significantly with the Funding team charter w [unresolved-questions]: #unresolved-questions ## Organizational form of the Funding team +[funding-team-org]: #organizational-form-of-the-funding-team -This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. The Funding team could be a new team, or it could be an extension of the Grants team proposed in [RFC 3919]. Future possibilities include merging the two teams or generalizing the Funding team into a broader team for supporting Rust teams. We expect the Leadership Council to determine the right organizational form. +This RFC defines the Funding team's charter — its responsibilities — but leaves the organizational structure to the Leadership Council. There are two main options: + +**Extend the Grants team.** The Grants team proposed in [RFC 3919] already has an LC appointment process, selection infrastructure, and conflict-of-interest policies. Extending it avoids fragmenting volunteer attention across overlapping committees. + +**Create a new team.** The Funding team's charter is broader than selecting recipients — it includes staying in regular contact with teams, connecting them to resources, and understanding project health holistically. MiR selection is only one part of that mandate. A new team with a broader mandate may be a better fit than extending a team whose focus is choosing grant recipients. There is also a difference in operating cadence: the Grants program has predictable cycles, while the Funding team may need to react promptly when new funding becomes available rather than waiting for the next scheduled round. Current Grants team members may not have signed up for that kind of bandwidth or latency. + +We expect the Leadership Council to determine the right organizational form. # Future possibilities [future-possibilities]: #future-possibilities @@ -315,6 +325,11 @@ This RFC defines the Funding team's charter — its responsibilities — but lea This RFC defines the interface between the Rust Project and the RFMF specifically, but nothing about the process is inherently RFMF-specific. The Funding team's core service — assessing where dedicated maintainers would have the most impact, evaluating candidates, and selecting the best candidates — could be offered to other funding organizations that want to hire Maintainers in Residence. The value proposition is the same regardless of who's paying: the Project has visibility into which teams are struggling and which candidates have the trust and context to be effective, and funding organizations benefit from that assessment rather than making hiring decisions without it. +## Recording MiR affiliations + +If the Rust Project establishes a mechanism for recording affiliations of team members, Maintainers in Residence could record their RFMF funding as an affiliation. This would make funding relationships visible through the same infrastructure used for employer affiliations. + ## Project Goals Funding program -The RFMF provides undirected funding — sponsors contribute to a general fund earmarked to fund Rust maintainers, with the Leadership Council deciding the specific form. There are ongoing plans to propose a Project Goals Funding program that would allow sponsors to direct funding at specific Project Goals. Sponsors would choose goals, roadmaps, or application areas to fund, and the Foundation would issue grants to contributors working on that work. A fixed percentage of directed funding (likely 10% to start) would flow to the Leadership Council's Project Priorities budget, where it can be used to fund maintenance, project management, or other activities. Together, the two programs cover the full spectrum of sponsor needs: undirected funding for those who want to support Rust's overall health, and directed funding for those who want to accelerate specific work. +The RFMF provides undirected funding — sponsors contribute to a general fund earmarked to fund Rust maintainers, with the Leadership Council deciding the specific form. There are ongoing plans to propose a Project Goals Funding program that would allow sponsors to direct funding at specific Project Goals. Sponsors would choose goals, roadmaps, or application areas to fund, and the Foundation would issue grants to contributors working on that work. A percentage of directed funding would flow to the Leadership Council's Project Priorities budget, where it can be used to fund maintenance, project management, or other activities. Together, the two programs cover the full spectrum of sponsor needs: undirected funding for those who want to support Rust's overall health, and directed funding for those who want to accelerate specific work. + From 942a1815810c5cb363a5384a07f1f8f391262bad Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 12 Mar 2026 17:30:43 -0400 Subject: [PATCH 06/18] fix: further tweaks --- rfcs/undirected-funds-rfc.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 639e05f..3f2edea 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -37,11 +37,14 @@ The problems teams describe require sustained, long-term presence. ## What kind of sponsors do we expect -We expect two kinds of sponsors. First, individuals and organizations that value Rust and want to support its long-term health without any particular expectations. These will generally be smaller-dollar sponsors contributing to a project they believe in. +We expect three kinds of support. -Second, and important for the fund's sustainability, are companies that employ developers or contributors working full-time to improve Rust. These companies are invested in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" like reviewing other people's PRs, mentoring newcomers, fixing regressions, and driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. +First, small-dollar donations from individuals and organizations that value Rust and want to support its long-term health without any particular expectations. The Foundation will help get the word out via funding drives and PR campaigns. + +Second, when the Foundation takes in directed funding towards a particular goal, best practice will be to direct a percentage of that work into the RFMF, providing another revenue stream for maintenance work. (See the [Future Possibilities](#future-possibilities) section for more discussion in this direction.) + +The third category is companies that employ developers or contributors working full-time to improve Rust. These companies are invested in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" like reviewing other people's PRs, mentoring newcomers, fixing regressions, and driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy. -Additionally, the proposed Project Goals Funding program (see [Future possibilities][]) would direct a percentage of directed funding into the RFMF, providing another revenue stream for maintenance work. ## Why would companies sponsor the fund From ad257500e7fc75dc412958d815a1173fd1698e89 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 12 Mar 2026 17:32:38 -0400 Subject: [PATCH 07/18] Update rfcs/undirected-funds-rfc.md Co-authored-by: Tyler Mandry --- rfcs/undirected-funds-rfc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 3f2edea..1ef4cab 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -13,7 +13,7 @@ This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Resi Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" appointed by the Leadership Council. This Funding team will weigh the set of applications against the project's needs and priorities. -The Funding team is additionally charged with ensuring the program's overall success. When sponsors contribute undirected funding, they are investing in the Rust project as a whole — and the project should meet them in good faith. The rest of the project is expected to help the Funding team manage sponsor relations, e.g., by meeting with sponsors or providing other reasonable sponsor benefits. +The Funding team is additionally charged with ensuring the program's overall success. When sponsors contribute undirected funding, they are investing in the Rust project as a whole — and the project should meet them in good faith. Project teams receiving support from the program are expected to help the Funding team manage sponsor relations, e.g., by meeting with sponsors or providing other reasonable sponsor benefits. [RFC 3919]: https://github.com/rust-lang/rfcs/pull/3919 From 919f3579f98e011a32dfe6e95a7074181ec7fe75 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 11:17:30 -0400 Subject: [PATCH 08/18] Update rfcs/undirected-funds-rfc.md Co-authored-by: Josh Triplett --- rfcs/undirected-funds-rfc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 1ef4cab..4e25493 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -168,7 +168,7 @@ In advance of contract renewal, the Foundation will consult with the Funding tea Maintainers in Residence are expected to spend 100% of their funded time working to improve the Rust project. That funded time can be split between: -* **Team priorities** — items that are prioritized by the team(s) that the maintainer belongs to. This includes reviews, mentoring, bug-fixing, triage, and larger development work like refactors or subsystem rewrites. +* **Team priorities** — items that are prioritized by the team(s) that the maintainer was specifically hired to contribute to. This includes reviews, mentoring, bug-fixing, triage, and larger development work like refactors or subsystem rewrites. * **Self-selected items** — work of the individual's choosing. We expect an approximately 50/50 split between these two, but the exact split will vary depending on the individual, their experience, and the needs of the team. The Funding team should monitor and make sure that team priorities are being adequately served, while also ensuring that MiR have the opportunity to pursue self-selected work. If both cannot be done, that likely indicates the need for another MiR in that area. From 8e77468a741785a0b5e526b9ddefa5a4de71c57e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 12:08:37 -0400 Subject: [PATCH 09/18] rework axioms in response to tmandry's points --- rfcs/undirected-funds-rfc.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 4e25493..7fb6e46 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -67,11 +67,13 @@ The RFMF collects sponsorships from companies and individuals. Funds support pro ### The RFMF is a collaboration between the Project and the Foundation -The Project brings knowledge of team health and needs; the Foundation brings logistics, sponsor relationships, and operational capacity. The Funding team (see below) identifies which areas need support and works with the Foundation to select candidates. The Foundation is involved in the hiring decision and handles contracting, compensation, and sponsor relations. This is a partnership, not a handoff — both sides contribute throughout. +Neither the Foundation nor the Project can operate the RFMF on their own. The Foundation has a bank account, legal entity, and operational capacity, the Project has knowledge of team health and needs. The Foundation is the incoming channel by which most sponsors arrive, but the Project governs the codebase that sponsors want to support. This RFC proposes that both project members (the Funding team) and Foundation staff jointly make major decisions. This is a partnership, not a handoff. -### The Project helps maintainers demonstrate their impact +### The Funding team owns the program's success, but they can't do it alone -Sponsor engagement is not something Maintainers in Residence do alone — the Leadership Council, team leads, and MiRs all participate. The Project provides scaffolding — goals, program management, reporting infrastructure — so maintainers can focus on the work while sponsors get visibility into outcomes. See [What sponsors get][] for details. Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. +Together with Foundation staff, the Funding team owns sponsor relations and program success. As the team that selects maintainers and understands project needs, they're best positioned to communicate with sponsors about outcomes and priorities. However, they need support from the broader project — team leads providing updates, maintainers participating in sponsor meetings, and project infrastructure for reporting. + +Sponsor engagement does not imply that any technical decisions (RFC approvals, PR reviews, design choices) should be made differently than they would be otherwise. ### Maintainers are team members From 9ef290051e59a4909b629d35cd91d6952c8c74b2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 12:13:38 -0400 Subject: [PATCH 10/18] justify and clarify developer time split remove the 50/50 description, too specific. --- rfcs/undirected-funds-rfc.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 7fb6e46..d08296e 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -173,7 +173,9 @@ Maintainers in Residence are expected to spend 100% of their funded time working * **Team priorities** — items that are prioritized by the team(s) that the maintainer was specifically hired to contribute to. This includes reviews, mentoring, bug-fixing, triage, and larger development work like refactors or subsystem rewrites. * **Self-selected items** — work of the individual's choosing. -We expect an approximately 50/50 split between these two, but the exact split will vary depending on the individual, their experience, and the needs of the team. The Funding team should monitor and make sure that team priorities are being adequately served, while also ensuring that MiR have the opportunity to pursue self-selected work. If both cannot be done, that likely indicates the need for another MiR in that area. +Experience with the Python Developer-in-Residence program suggests that for long-term satisfaction, it's important that maintainers be given time to pursue self-selected projects. We've also seen over time that maintainers often develop good instincts for what would generally benefit Rust, and thus self-selected "passion projects" can turn into some of Rust's most impactful features. + +The split between team priorities and self-selected work will depend on the individual. The Funding team should monitor and make sure that team priorities are being adequately served, while also ensuring that MiRs have the opportunity to pursue self-selected work. If both cannot be done, that likely indicates the need for another MiR in that area. Maintainers in Residence are also expected to: From 6a7c1ded2b9cdb9f2de1b4135b63145aeab296c0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:07:22 -0400 Subject: [PATCH 11/18] adjust discussion of area selection --- rfcs/undirected-funds-rfc.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index d08296e..50410ab 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -88,13 +88,16 @@ The RFMF doesn't try to be the sole channel for funding Rust maintenance. The Ma RFMF sponsors contribute to a general fund and don't direct where the money goes or who gets hired. Every contribution helps fund the sustained maintenance that keeps Rust healthy. All sponsors receive public recognition and visibility into how funds are being used through regular public reports. -The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. The specific tiers are best determined over time by the Foundation and Funding team, but they could include benefits like the following: +The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. + +**This RFC does not specify tiers or associated benefits.** However, we give examples of benefits that the Funding team may opt to use. This is not meant to be an exclusive list, the Funding team may have new ideas that are not on this list; the list is instead meant to give a sense for the *kinds* of benefits that are reasonable: * **Sponsor meetings.** The Foundation builds a community of sponsoring organizations that meets with project leadership (Leadership Council, team leads) and Maintainers in Residence a few times a year to discuss project direction, sponsor experiences, and pain points. Project leadership gains insight into the needs of major Rust users; sponsors get visibility into the roadmap and the opportunity to hear from other Rust-adopting companies. * **Impact reporting.** Regular reports on what funded maintainers are working on, progress on Project Goals, and how the program is contributing to Rust's health. These reports are prepared with help from the program management team and made publicly available. -* **Best-effort attention.** Sponsors can reach out to the Foundation or project contacts about PRs or bugs that need attention. There is no SLA or guarantee — any maintainer would bump a bug report from an active user, and sponsors can reasonably expect the same consideration. - -These are reasonable expectations that don't compromise the Project's independence — they represent the kind of engagement any healthy open-source project should provide to its supporters. +* **Prioritized review and bug fixes.** Sponsors can reach out to the Foundation or project contacts about PRs or bugs that need attention, up to a certain frequency that is dependent on funding tier. This provides the sponsor with a form of "insurance" that they will get help resolving priority issues they encounter with Rust; however, this prioritization should be limited to small-scope fixes or reviews, not to larger feature development, and is in no way a promise that a PR will be *merged* (simply reviewed). +* **Prioritization for goal championing.** Sponsors who have proposed project goals might be able to request that teams use an affiliated MiR to champion their goals. If teams have concerns about the goals, they are not obligated to oblige these requests. +* **Area preferences for major sponsors.** If a sponsor or group of sponsors is willing to fund the entire cost of a MiR but only in a specific area, the Funding team could work with them to find a candidate for that particular area. + * For example, if a sponsor would specifically like to fund a cargo or rustfmt maintainer, the Funding team could work with them to make that happen. The role would still be a MiR like any other, following the same processes. *What sponsors do not get:* the ability to unilaterally direct a maintainer's work, pick who gets hired, pick who gets added to project teams, bypass project processes, or influence technical decisions. From cdce1bdc6e0afec8747001ea301e974a5a0c0b59 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:19:32 -0400 Subject: [PATCH 12/18] clarify team membership requirements --- rfcs/undirected-funds-rfc.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 50410ab..7ead8e9 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -77,7 +77,11 @@ Sponsor engagement does not imply that any technical decisions (RFC approvals, P ### Maintainers are team members -Maintainer in Residence candidates must already be members of the relevant Rust team(s) with the permissions needed for the work — reviewing PRs, championing goals, and performing actions limited to official team members. This is a hard requirement, not just an expectation. Funded maintainers are not a separate class of contributor — they're existing team members who can now commit sustained time. +Maintainer in Residence candidates must be established members of the Rust Project who either are already members of the relevant team(s) or have been approved by the team to become a member upon starting their MiR role. They need the permissions required for the work — reviewing PRs, championing goals, and performing actions limited to official team members. This is a hard requirement, not just an expectation. + +For candidates who are not yet members of the target team, the team must confirm they are willing to add the candidate as a member. In cases where a team is defunct, the parent team(s) can invite the candidate to join and help revive the team. + +Funded maintainers are not a separate class of contributor — they're project members who can now commit sustained time to team responsibilities. ### Not one size fits all @@ -137,7 +141,7 @@ Beyond individual hiring decisions, the Funding team has ownership of the progra ## Application and vetting process -The process of contracting a new Maintainer in Residence begins with an open call for applications. Any member of a Rust team or person to whom team membership has been offered can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. +The process of contracting a new Maintainer in Residence begins with an open call for applications. Any established member of the Rust Project can apply, whether they are already members of the relevant team(s) or would need team approval to join. Broad applications help surface needs and candidates the Funding team might not have identified on its own. Applicants provide (1) their background and experience — both within the Rust project and professionally; (2) their availability (full-time, part-time, etc); and (3) a high-level description of the kind of work they would like to do. This description can be quite general (e.g., "maintain rustfmt") but could also be specific (e.g., "split project `foo` into multiple independent libraries `bar` and `baz`"). From d92cbb0c8b358fb698223e1412dd403cbdd682d4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:29:18 -0400 Subject: [PATCH 13/18] be more consistent with pluralization --- rfcs/undirected-funds-rfc.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 7ead8e9..f1f0363 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -9,7 +9,7 @@ This RFC defines the relationship between the Rust Foundation Maintainer Fund (R The Leadership Council has a Project Priorities budget, which is used to fund various initiatives, such as travel grants or program management. RFMF funds will be directed to this budget, but they will be earmarked for maintainer sponsorship. That means that they can be used only for activities that directly support Rust Project maintainers, which might include the program management program or the Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. We propose a new funding program for supporting maintainers described below, which should be the primary target of these earmarked funds. -This RFC adds a new program: Maintainers in Residence (MiR). Maintainers in Residence have dedicated time to focus on some part of the Rust project. Their time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the project. +This RFC adds a new program: Maintainer in Residence (MiR). Maintainers in Residence have dedicated time to focus on some part of the Rust project. Their time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the project. Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" appointed by the Leadership Council. This Funding team will weigh the set of applications against the project's needs and priorities. @@ -24,7 +24,7 @@ The Rust Foundation is establishing a Maintainer Fund to collect sponsorships an Our primary recommendation is that these funds should be used to hire maintainers — called "Maintainers in Residence" — on a full-time or substantial part-time basis, though the Council retains flexibility to deploy funds in other forms such as project grants. -## Why sustained maintainers in residence? +## Why focus on long-term maintenance? In preparing this recommendation, we interviewed team leads across the Project. The message was clear: *"what's needed is people with the focus to drive longer-scale projects."* Volunteer maintenance keeps the lights on, but larger-scale work — clearing review backlogs, driving cross-cutting refactors, carrying context across a complex codebase — stalls because nobody has the sustained focus to push it through. As one (volunteer) team lead said, *"All the time that reviewers have goes into reviewing, triaging, and so on, and then the interesting longer-term projects just fall under the table."* @@ -61,7 +61,7 @@ Part of the value proposition for sponsors is that they don't have to learn the # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -The RFMF collects sponsorships from companies and individuals. Funds support project grants, project management, and the flagship program: Maintainers in Residence — experienced, self-directed maintainers who do the work that keeps Rust healthy. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. +The RFMF collects sponsorships from companies and individuals. Funds support project grants, project management, and the Maintainer in Residence program. Maintainers in Residence are experienced, self-directed maintainers who do the work that keeps Rust healthy. They participate in team discussions, review PRs, mentor newcomers, and work on what the team needs. ## Design axioms @@ -135,7 +135,7 @@ The Funding team's role is to keep a pulse on the project and work with the Foun The Foundation supports the Funding team with logistics. The Foundation issues contracts or manages employment. They provide managerial support to convey feedback. -We expect that initially this managerial work can be managed by existing Foundation staff. If the program grows to a large number of MiR, however, we recommend that the Leadership Council use some portion of the RFMF funds to hire a dedicated manager who would work closely with the Funding team (see [Who manages Maintainers in Residence after they're hired?][who-manages-mirs]). +We expect that initially this managerial work can be managed by existing Foundation staff. If the program grows to a large number of MiRs, however, we recommend that the Leadership Council use some portion of the RFMF funds to hire a dedicated manager who would work closely with the Funding team (see [Who manages Maintainers in Residence after they're hired?][who-manages-mirs]). Beyond individual hiring decisions, the Funding team has ownership of the program's long-term health: apportioning available funds across positions, ensuring that funded work gets reported on, demonstrating return on investment to sponsors, and sustaining and growing the program over time. The RFC specifies the inputs and constraints for these decisions — project needs, team health, sponsor priorities, candidate qualifications — but delegates the decision process itself to the team, which is expected to operate transparently and document how it makes decisions. From 62e060b15464705b396f2da0582c306575e5bcf2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:43:39 -0400 Subject: [PATCH 14/18] clarify mir target --- rfcs/undirected-funds-rfc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index f1f0363..a36b7a2 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -7,9 +7,9 @@ This RFC defines the relationship between the Rust Foundation Maintainer Fund (RFMF) and the open-source Rust project. The RFMF is a dedicated fund used to support Rust maintenance: open-ended, multiplicative work that improves Rust and its codebase and makes it more accessible. -The Leadership Council has a Project Priorities budget, which is used to fund various initiatives, such as travel grants or program management. RFMF funds will be directed to this budget, but they will be earmarked for maintainer sponsorship. That means that they can be used only for activities that directly support Rust Project maintainers, which might include the program management program or the Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. We propose a new funding program for supporting maintainers described below, which should be the primary target of these earmarked funds. +The Leadership Council has a Project Priorities budget, which is used to fund various initiatives, such as travel grants or program management. RFMF funds will be directed to this budget, but they will be earmarked for activities that direct funding directly to individual maintainers. This includes the existing program management program and would include the proposed Project Grants Program ([RFC 3919]), which provides modest stipends to recognize and support existing contributors. -This RFC adds a new program: Maintainer in Residence (MiR). Maintainers in Residence have dedicated time to focus on some part of the Rust project. Their time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the project. +This RFC additionally proposes a third program, the Maintainer in Residence program, dedicated to hiring long-term maintainers and funding their maintenance work in full. Maintainers' in Residence time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the project. Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" appointed by the Leadership Council. This Funding team will weigh the set of applications against the project's needs and priorities. From 52257154a6c3c9dee7a6654e339d1b6196a66fc4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:43:48 -0400 Subject: [PATCH 15/18] clarify reporting requirements --- rfcs/undirected-funds-rfc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index a36b7a2..cb2a3bd 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -50,7 +50,7 @@ The third category is companies that employ developers or contributors working f For companies that depend on Rust, what matters most is knowing that the daily work of the project continues — that good ideas won't wither on the vine for lack of reviewer bandwidth, and that bugs will be fixed promptly, particularly bugs they themselves are hitting. Sponsoring the maintainer fund is a direct investment in that capacity. -For the fund to be sustainable, sponsors also need to be able to report the impact of their contributions. This means the project needs to treat demonstrating impact as a whole-project responsibility, not something that falls on Maintainers in Residence alone. See [What sponsors get][] for concrete details on what we envision. +For the fund to be sustainable, sponsors also need to be able to report the impact of their contributions. This means the project needs to treat demonstrating impact as a whole-project responsibility, not something that falls on Maintainers in Residence alone. See [Sponsor benefits][] for concrete details on what we envision. ## Why the Project should drive the selection From 6fb2d9942485577b0b61cd72a4fc28bb2031ac05 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:43:56 -0400 Subject: [PATCH 16/18] clarify team membership requirements --- rfcs/undirected-funds-rfc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index cb2a3bd..ac9078b 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -77,7 +77,7 @@ Sponsor engagement does not imply that any technical decisions (RFC approvals, P ### Maintainers are team members -Maintainer in Residence candidates must be established members of the Rust Project who either are already members of the relevant team(s) or have been approved by the team to become a member upon starting their MiR role. They need the permissions required for the work — reviewing PRs, championing goals, and performing actions limited to official team members. This is a hard requirement, not just an expectation. +Maintainer in Residence candidates must be established members of the Rust Project who either are already members of the relevant team(s) or have been approved by the team(s) to become a member upon starting their MiR role. They need the permissions required for the work — reviewing PRs, championing goals, and performing actions limited to official team members. This is a hard requirement, not just an expectation. For candidates who are not yet members of the target team, the team must confirm they are willing to add the candidate as a member. In cases where a team is defunct, the parent team(s) can invite the candidate to join and help revive the team. From 34153cc07bbf7bc27182f23e7e9186afed751a48 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:44:05 -0400 Subject: [PATCH 17/18] rename sponsor benefit section --- rfcs/undirected-funds-rfc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index ac9078b..9224150 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -87,10 +87,10 @@ Funded maintainers are not a separate class of contributor — they're project m The RFMF doesn't try to be the sole channel for funding Rust maintenance. The Maintainer in Residence program fills a specific role: allowing project teams to select and direct maintainers toward the areas they identify as most critical. Other structures — the proposed Project Goals Funding program for directed grants (see [Future possibilities][]), the Project Grants Program for contributor stipends, the Rust-Analyzer Open Collective, the proposed RustNL Maintainer Fund, company employment — serve complementary roles. -## What sponsors get -[what-sponsors-get]: #what-sponsors-get +## Sponsor benefits +[sponsor-benefits]: #sponsor-benefits -RFMF sponsors contribute to a general fund and don't direct where the money goes or who gets hired. Every contribution helps fund the sustained maintenance that keeps Rust healthy. All sponsors receive public recognition and visibility into how funds are being used through regular public reports. +RFMF sponsors typically contribute to a general fund and don't direct where the money goes or who gets hired (though hiring a maintainer in a specific area may also be an option if the sponsor is willing to cover the full cost, see the [Sponsor benefits][] section). Every contribution helps fund the sustained maintenance that keeps Rust healthy. All sponsors receive public recognition and visibility into how funds are being used through regular public reports. The Foundation should establish sponsorship tiers to encourage larger contributions and year-over-year commitment, as sustained sponsorship permits more stability for the program. From d12c1880c6470dcee2083eed63cc7b033c7fbc65 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Mar 2026 13:44:19 -0400 Subject: [PATCH 18/18] clarify contract renewal --- rfcs/undirected-funds-rfc.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/rfcs/undirected-funds-rfc.md b/rfcs/undirected-funds-rfc.md index 9224150..e77174f 100644 --- a/rfcs/undirected-funds-rfc.md +++ b/rfcs/undirected-funds-rfc.md @@ -156,10 +156,9 @@ The Funding team prioritizes applications based on: The Funding team works with the Foundation to select from the applicant pool and to extend offers. The Funding team is looking for maintainers that have technical depth in the relevant area, community standing and trust within the Project, and sustained work orientation (a track record that suggests they'll thrive in a role focused on reviews, mentorship, unblocking, and the kind of long-term technical work that requires deep context). - ## Contract terms and renewal -The precise terms of the arrangement are not defined by this RFC. The arrangement is likely to begin as year-long contracts but may change to other durations, regular employment, or vary by locale. The important points are: it is a **substantial commitment** (full-time or significant part-time), and it is expected to **continue as long as both sides are satisfied and funding is available**. Some areas may not require a full person's time; it is fine to have one person cover two areas, or two people each contribute part-time to a single area, so long as there is enough concentrated time to build and maintain deep context. +The precise terms of the working arrangement are not defined by this RFC. The important points are: it is a **substantial commitment** (full-time or significant part-time), and it is expected to **continue (or be renewed) as long as both sides are satisfied and funding is available**. Some areas may not require a full person's time; it is fine to have one person cover two areas, or two people each contribute part-time to a single area, so long as there is enough concentrated time to build and maintain deep context. Compensation should be a flat rate within a small number of bands (e.g., junior and senior), rather than individually negotiated. Flat rates keep the program simple and avoid the perception that some maintainers are valued more than others for equivalent work. The compensation structure is publicly advertised as part of the call for applications. The Foundation determines the specific rates and may adjust them over time as the program learns what works and what's needed to attract strong candidates. @@ -199,12 +198,11 @@ Requests that go beyond this — "develop this feature" or "devote sustained tim ## Reporting and impact visibility +While MiR are expected to help collect data for reporting, they will be supported by the project's other infrastructure. The goal is that they can focus on doing maintenance and only have minimal reporting requirements. -While MiR are expected to help collect data for reporting, they will be supported by the project, and the overall reporting expectations should not be substantively more onerous than for volunteer contributors. The point is to reduce burden, not add it. - -Examples of project support include: +The project supports MiRs in reporting their impact in the following ways: -* The program management team will prepare an initial draft by examining GitHub activity (PR reviews, etc.) and via updates on Project Goals championed by the maintainer. +* The program management team will prepare an initial draft of MiR activity by examining GitHub activity (PR reviews, etc.) and via updates on Project Goals championed by the maintainer. * The Content team will interview maintainers and highlight their work. Program managers collect progress updates from goal owners (funded or not) on a regular cadence and prepare summaries. For funded maintainers, these summaries serve double duty: they give the Project visibility into goal progress, and the Foundation can use them to prepare sponsor-facing reports. @@ -219,8 +217,6 @@ As the program grows, we may wish to transition this role from a responsibility Separately, Code of Conduct violations that result in removal from the Project immediately terminate the contract. Team membership is a hard requirement for the role; a maintainer who is no longer a project member cannot continue as a Maintainer in Residence. -The Project does not decide whether a contract gets renewed; it provides input. - # Frequently asked questions [faq]: #faq