RFC: project goals for 2025h1 #3764
Conversation
|
Given that the goals for 2024H2 had an "unusual ratification procedure", I assume that the same applies here? Adding a bit onto this: I'm not 100% sure why this is shared in the form of an RFC, since as the RFC clarifies, a lot of these goals boil down to someone actually having the resources to accomplish them, either in the form of money, time, etc. So, it feels unusual to open an RFC on the specific goals that have been declared, since it feels like the only options for discussion are bad: either criticising people on what they're doing with their time, or asking people to work on things that they don't have the resources for. I'm not sure what a better alternative forum would be for announcing these goals, asking people to get involved, etc., but I also don't think that an RFC with everything in one giant list is a good solution. Perhaps it could be done in a separate "goals" repo with individual discussion threads for individual goals, or in a similar category on Internals. I personally dislike using Zulip for longer-form discussions, which is why I specifically mention making a repo or Internals category for this. For the remainder of my feedback, I think that it's probably more appropriate to not comment on the specific goals, but rather, the process surrounding them, which I guess is probably the real goal of this RFC. And so, I'll add my concerns in individual sections in this comment. What steps are done to ensure that these goals are resilient to changing circumstances and burnout? Imagine that a hypothetical person is being paid by their employer to perform a given task, and then they later get laid off? In this circumstance, I would imagine that the answer would be unequivocally that this goal is now off the table, since this person should not feel pressured to work on a goal in their spare time when their source of income and time is immediately severed. However, I have a feeling that many people in this situation would feel pressured to continue working on their goal despite the circumstances, and I think that there should be something in the process to help ensure that people get the support they need in these situations. And, this is a bit picky, but I think that the term "Goals" itself is putting expectations in the wrong place. As I mentioned, if someone's circumstances change and they can't complete the goal (which is very likely to happen for at least a few goals given that we're committing to six months in the tech industry), they will feel pressured to complete it. I think that calling this "project plans" or something similar would be worthwhile. I don't really care what colour the shed is painted, and as far as I'm concerned, it can be just decided, but I really don't like the idea of pressuring volunteers into doing something even if their circumstances change. I especially think that there should be a culture of acceptance and forgiveness when it comes to burnout, and adding deadlines onto something that may be entirely volunteer work is definitely a way to make it more stressful. I don't have a good solution to this: I know that many people who work on these teams do have the support of their employer to work on the project, but many people also don't. The "exposure" of being even the point of contact for a major project goal is effectively worthless, although I personally know that working on open source work can be rewarding in its own right. I think that there should always be a balance and an escape hatch for people who can't handle the pressure when something isn't their full-time job. At least from an outside perspective, a lot of these goals appear to be spreading the project very thin. The prevalence of "help wanted" across a large number of goals, including one of the stated major goals (Rust for Linux), feels very concerning. I truly doubt that this is the plan, but a lot of the goals give the appearance of someone wanting a feature, deciding to be project manager for that feature, and then sitting back and folding their arms and waiting for people to come and implement the feature. Obviously, as an open source project, a lot of contributions hinge on volunteers, but it feels premature to declare something a "goal" without even deciding the people involved with its implementation. I think that in the future, anything with the title "goal" should have all of its resources planned ahead of time, especially with contingencies and backups in case of unexpected situations as mentioned above. Similarly, "invited goals" feel like a massive commitment with little benefit other than the potential for recognition, which even then feels unlikely. I feel like the project already has a decent system for something more "goal" like, which is the Rust Foundation grant program: people with dedicated plans to do something are literally given the resources to complete it, rather than just being given a mentor and getting on the hook for completing something they didn't fully understand from the start. Of course, resources are obviously limited in this case, and not a whole lot of grant money can be doled out for things. I think that, if we're working outside the framework of literally giving people the resources to complete things, these should be reframed in terms of working groups instead: have the capacity reserved on the team for mentors still, but instead of treating it as a goal for someone to take on, treat it as an area where people can enter and incrementally bring it toward the finish line, then leave as they wish. Part of this is the expectation that something may not be worked on at all, and this is okay. |
|
@clarfonthey correct, the ratification procedure will be the same as last time, I was just giving it a bit of time for people to point at mistakes or other things. I'll post the comment today. Regarding the use of an RFC, I am opening it in this form so as to invite comment. RFCs are the Rust project's mechanism for ratifying consensus on a particular direction (and, to a lesser extent, advertising that to people actively following the project). I agree that sometimes the procedure isn't a perfect fit (and maybe this is one of those cases) but it's still the closest we've got. =) For this particular RFC the primary "audience" are Rust team members (similar to RFCs about team procedure, for example), but that doesn't mean others have nothing to contribute. To start-- perhaps you could say "Hey, that sounds awesome!" or lend in words of encouragement for things you are excited for. In terms of proposing changes to the text, maybe you feel the wording or framing of the flagship goals could be improved -- or that one of the project goals might be elevated to a flagship goal? Or, perhaps you realize that some work you were considering contributing is not on this list, and would like to ask whether you can add a goal of your own? And, yes, there is room for constructive feedback on individual goals as well. I appreciate your concern about "telling people what to do with their time" and I agree that many negative comments would be inappropriate and pointless. But I think highlighting potential pitfalls, suggesting alternatives that could be better or ought to be mentioned (at least in the FAQ), or even saying "I don't really think this direction is good" is not out of scope. And yes, I am happy to receive meta feedback about the process, although I personally feel very clear that this is providing value. EDIT: Updated slightly along the way as I thought more about this. |
|
Regarding invited goals and the grant program, the two work together. Invited goals are one way for the Foundation to know what kind of work would be welcome and hence where grants would be well suited. But also, I don't think grants are the be-all-end-all here -- money is not always the blocker, particularly for initial contribution, mentoring and knowing what to do is a much bigger challenge. |
|
Allow me to address the choice of term goals: Putting pressure on volunteers is obviously not the goal (pun intended). I would actually turn your question around. For a lot of people I've spoken with, the problem is not the energy to move something over the finish line, but the sense that if they put time into it, they have no idea if the idea is going to go anywhere, or if somebody will arise with a concern or comment. When somebody does, it is difficult to tell what they are supposed to do in response -- how much "response" is enough to resolve it? Note that the person raising the concern may or may not be a Rust team member, it can be hard to tell how much weight to give to a concern. So when we declare something as a project goal, that term is intentional, because the plan is that it carries a certain amount of weight for the Rust maintainers -- we are going to support this person in getting this thing done. |
I found a bug in the regular expression that generated the RFC text.
Proposed Final Comment PeriodDue to its cross-team nature, this RFC follows an unusual ratification procedure. To enter FCP, the leads of all impacted teams must check their boxes. Other team members are free to check their boxes but not required for FCP. Any team member from an impacted team should feel free to voice concerns. Guidance for reviewing:
What follows is a check-list of names from each team (generated from the teams repo). Note that only the leads are cited using github pings because otherwise we exceed the limit of 50 names. Please check your box. bootstrap
cargo
clippy
compiler
crates-io
infra
lang
leadership-council
libs
libs-api
opsem
project-stable-mir
rustdoc
spec
testing-devex
types
wg-macros
EDIT: removed release team sign-off |
nikomatsakis
added
proposed-final-comment-period
| * prepare to support asynchronous (and synchronous) generators in the language. | ||
| * Continue helping Rust support low-level projects by [**stabilizing compiler options and tooling used by the Rust-for-Linux project**](https://rust-lang.github.io/rust-project-goals/2025h1/./rfl.html). In 2025H1 we plan to: | ||
| * implement [RFC #3716](https://github.com/rust-lang/rfcs/pull/3716) to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth; | ||
| * taking the first step towards stabilizing [`build-std`](https://rust-lang.github.io/rust-project-goals/2025h1/https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](./build-std.html); |
There was a problem hiding this comment.
links are still broken here...the latest commit didn't fix them all but you marked the threads as resolved
There was a problem hiding this comment.
d'oh! Thanks, I'll take a look.
| * implement [RFC #3716](https://github.com/rust-lang/rfcs/pull/3716) to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth; | ||
| * taking the first step towards stabilizing [`build-std`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](https://rust-lang.github.io/rust-project-goals/2025h1/./build-std.html); | ||
| * add rustdoc features to extract and customize rustdoc tests (`--extract-doctests`); | ||
| * stabilize clippy configuration like `.clippy.toml` and `CLIPPY_CONF_DIR`; |
There was a problem hiding this comment.
nit: let's specify "to the extent of guaranteeing some level of backwards compatability, but not necessarily perpetual backcompat".
it does not seem to be the case that Linux needs perpetual backcompat, just some weaker guarantees.
There was a problem hiding this comment.
In general my take is that we should avoid making our stability guarantees overly complex. But we can weaken the section on clippy in particular if you like. I feel like the ability to accept this file without dying is all that needs to be stable; it's ok if there is deprecation and flags stop having the intended effect or what have you.
There was a problem hiding this comment.
Yes, that's the goal. I'm also fine with that being informally documented in this RFC thread for now.
|
@rfcbot reviewed |
stabilization decision should involve Types
same with any decision made here |
|
t-compiler are discussing our review capacity in our private Zulip stream prior to checking our boxes :) |
text/0000-Project-Goals-2025h1.md
Outdated
| | [Externally Implementable Items](https://rust-lang.github.io/rust-project-goals/2025h1/eii.html) | [Mara Bos][] | [compiler], [lang] | | ||
| | [Field Projections](https://rust-lang.github.io/rust-project-goals/2025h1/field-projections.html) | [Benno Lossin][] | [compiler], [lang] | | ||
| | [Finish the libtest json output experiment](https://rust-lang.github.io/rust-project-goals/2025h1/libtest-json.html) | [Ed Page][] | [testing-devex] | | ||
| | [Implement Open API Namespace Support](https://rust-lang.github.io/rust-project-goals/2025h1/open-namespaces.html) | ![Help Wanted][] | [cargo], [compiler] | |
There was a problem hiding this comment.
Reword to avoid confusing with OpenAPI?
| | [Implement Open API Namespace Support](https://rust-lang.github.io/rust-project-goals/2025h1/open-namespaces.html) | ![Help Wanted][] | [cargo], [compiler] | | |
| | [Implement Open Namespace Support on crates.io](https://rust-lang.github.io/rust-project-goals/2025h1/open-namespaces.html) | ![Help Wanted][] | [cargo], [compiler] | |
There was a problem hiding this comment.
so it's not just me that was confused by this... 😅
I agree that calling it "Open API Namespace Support" is a bit misleading. The original RFC called it "Packages as (optional) namespaces" and IMHO it would probably be best to keep that name to avoid such confusion.
There was a problem hiding this comment.
if somebody wants to open a PR against https://github.com/rust-lang/rust-project-goals/ I'd merge it. =)
cc @epage
There was a problem hiding this comment.
The name change is very intentional and the suggested fix is incorrect. It's a little clearer without title case ("open API namespaces")
This is a feature for open namespaces for Rust code with publish controls on crates.io. The naming is trying to make it clear that this is not registry namespaces which it is commonly confused with and which the RFC said it wasn't solving iirc.
There was a problem hiding this comment.
idk if this is the right place to discuss this but it feels a bit strange to me that this was unilaterally renamed without discussion across the involved teams. "open namespaces" vs "registry namespaces" apparently makes a big difference to you but I assume for a regular user without a lot of context they sound basically equivalent.
There was a problem hiding this comment.
idk if this is the right place to discuss this but it feels a bit strange to me that this was unilaterally renamed without discussion across the involved teams.
Before we get to into the weeds about that, a key distinction independent of the RFC is that this project goal is written for compiler and Cargo support. At that level, there is no registry behavior and this is only a language feature of "open namespaces".
The initial versions of the RFC were unclear in their intent, being about a single piece of software and not organizational namespacing for registries. As I better understood that, I reframed the RFC around this being a language feature over several PRs. I did not rename the RFC itself. I don't remember why, whether it was easier to be consistent on names (I've seen this with other RFCs that go through major revisions) or that I hadn't realized the level of confusion the name might cause until further discussion when it was too late. The RFC does not speak at all about "registry namespacing", explicitly says its for projects and not organizations, and in all of my communication about this, I've tried to make it very clear that this is not a general registry namespacing feature and that if people use it as such, they are likely to run into impedance mismatches. Due to the connotations around "registry namespacing" (being organizational focused), I would go as far as saying that calling this "registry namespacing" isn't just a misnomer (as the focus is on the language feature) but goes against the intent of the RFC (oriented around APIs, not organizations).
"open namespaces" vs "registry namespaces" apparently makes a big difference to you but I assume for a regular user without a lot of context they sound basically equivalent.
The first term describes a language feature. The second term describes a registry feature. How people will understand this is the context it is communicated in which is up to us.
We've agreed who will take point in reviewing each of the goals that we think will need a dedicated reviewer, so checking both Wesley and I's boxes. |
One is planned, yeah. It's the first hand-over and we've got some kinks to work out. |
* update asks for some goals * add spec team asks * remove one spec team goal
|
Hi folks, A few things---
One thing to note on point 2 is that I did not do the best job of pre-circulating these goals with all relevant parties. So if this is the first time you are seeing an ask of your team, please feel free to ask questions. Now that we have a project goals team that is forming and can share the load, I expect we'll do a better job about circulating goals up front next time. |
good catch, let me check that @lcnr EDIT: opened rust-lang/rust-project-goals#240 |
release team signoff is no longer needed.
|
Update: After some conversation with release team, we hammered out the requirements for spec goal, and that team is removed from the goal. Therefore I've removed them from the RFC checklist, as this was the only ask. I've also taken the liberty of checking the box of @calebcartwright on behalf of the ask for "discussion and moral support" for the "testing-devex" working group, given that (a) they've not responded to pings on Zulip, so they are probably away; (b) the ask is just for basic approval and (c) I'm not even sure that working groups need to check boxes (though I don't see how it hurts). |
|
I believe at this point the only outstanding issue is hammering out agreement about the Secure quorum-based cryptographic verification and mirroring for crates.io goal, and we have ongoing discussion on Zulip about that. Here's hoping we can this into FCP tomorrow! |
|
I've checked my box, but I want to note a concern: There are substantially more accepted goals in this round than in the previous, and currently only one under "Goals not accepted". It doesn't seem like prioritization was as carefully done this round, and as a team lead I was never explicitly asked to do this. If that continues to be the norm I worry about project goals becoming a process-heavy crystallization of a problem the Project has struggled with for years: Trying to focus on too many things with too little time. What's the right number of project goals? I don't claim to know, but if I can't easily remember all the goals with asks for my team I think we are already flirting with it being too high. A big advantage of project goals is that it allows us to set aside dedicated time for higher-level priorities that we actually intend to follow through on. If instead it becomes a blessed way to bypass more granular prioritization decisions for things that aren't that, it will make the project less efficient. Granted, another benefit is that it allows goal owners to get a quick "vibe check" from the team. But I think we have to be careful about separating this from a commitment to actually dedicate future resources to a problem. There are some goals that had meaningful early feedback from the lang team during this process – that's a win! For others it felt more to me like "I see no reason why you shouldn't do this and since you don't seem to be asking for that much, fine". My gut tells me we should not accept goals like this, since that can easily lead to a mismatch in expectations. There should always be a good understanding of why we should accept a goal, according to some criteria, instead of an absence of reasons not to. Keeping in mind that project goals are not intended to be the only entry way to the project – rejecting a goal does not mean rejecting the effort altogether. |
|
@tmandry Solid concerns. I also have wondered if we have too many goals. At the same time, I think that as a project we've done a better job of calculating and estimating resources for many teams than we did before (e.g., the compiler team did explicitly discuss review bandwidth, and the spec team used the goals to anticipate what kind of edits to the reference would be required). When it comes to the lang team specifically, I think we probably need to think more about how to better integrate goal review and prioritization into our processes. It seems like a good task for the goals team to work with teams to figure out how to do the same for next time. Something we could do better I think is taking a skeptical look at each goal to determine if it is realistically accounting for the resources required and if we can really support it at this time. |
Propose a slate of 40 project goals for 2025H1, including 3 flagship goals:
Pin, which is frequently used in low-level async code; andbuild-stdby creating a stable way to rebuild core with specific compiler options;--extract-doctests);.clippy.tomlandCLIPPY_CONF_DIR;-Zbinary-dep-depinfo=y) and to configure no-std without requiring it in the source file (e.g., as via-Zcrate-attr);Rendered