Chartering the Project Goals Team

[traviscross]

Building on the completion of the 2024H2 project goals work, we're now looking forward to planning project goals for 2025H1, and in that light, we're proposing to charter the Project Goals Team:

• Propose project-goals team team#1641

The PR to the team repo includes the initial team charter. The team will live under launching-pad for the moment. Let's nominate to discuss and confirm our sign-off.

cc @nikomatsakis @jamesmunns

[nikomatsakis]

Yes please.

[traviscross]

@rfcbot fcp merge

[rfcbot]

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

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

Concerns:

• success-story-cementing (Chartering the Project Goals Team #150 (comment))

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

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

[oli-obk]

@rfcbot concern success-story-cementing

I personally do not feel like the project goals have really worked out for us, and instead produced negative pressure for contributors.

Cementing these in the form of a team gives this system an official stamp, but I don't see the system actually working out for anyone but external folk who now have a lever that only team members had before.

I want to discuss this more in council meetings, thus I'm raising a concern

[nikomatsakis]

Oli: I've not heard that feedback before. Can you elaborate a bit more on what you feel is not working?

I would mention that we (project goals team) have been discussing the idea of doing a more thorough evaluation as part of the Rust Vision Doc work precisely because we want to figure out what is working and what is not. I have heard a lot of positive feedback but I feel like people might not tell me the negative things.

That said, I don't think that creating a team is making this process any more official than it already is. What makes it feel official is the blogging (which we already decided to do) and, well, running the program.

[nikomatsakis]

I did a "mini retrospective" (asked for folks to leave comments on Zulip, reached out to some people) and I summarized the results here:

https://blog.rust-lang.org/inside-rust/2024/11/04/project-goals-2025h1-call-for-proposals.html#what-have-the-experiences-with-the-goals-program-so-far

[davidtwco]

I personally do not feel like the project goals have really worked out for us, and instead produced negative pressure for contributors.

I like the project goals program. Oftentimes, the projects that end up being goals will happen regardless of the goal program existing, this just makes it explicit what is going on and what the likely asks of those projects will be. I think that's useful.

I do think we're still working out as individual project teams how much capacity we have and how to answer questions like "can you support this goal?". That's a difficult problem for us regardless, the goal program just surfaces it.

If the project is selective about which goals it adopts then it can be a mechanism for us to highlight the project's priorities while having any confidence we might actually deliver on those priorities (ideally we've chosen goals where the owner will deliver on their commitment to do the work). We can provide updates to the wider community on those priorities and use the goals as a way to direct grants to the work the project has deemed important.

I think it does raise a tension that might exist in the project as it's a case of the project asking something of the project members - to prioritise helping out the goals that the project has decided to accept. Previously the only significant ask we've made of team members was to participate in reviews, because those are just sort-of necessary to keep everything moving. Otherwise we've asked that project members maintain a certain standard in their work and follow the procedures and policies we've put in place that are necessary for working together, but I think that's about all. I don't want a circumstance where the project tells people exactly what to work on, nobody wants that. I do think it's healthy for the project to move in a direction where there's a tiny bit more of an expectation on those who choose to be project members to help with things valuable to the broader project/teams, rather than becoming a project member, getting one's r+ rights and then pursuing exclusively one's own projects. It should never be a big ask and the majority of one's time as a project member should be able to be spent chasing your interests. I expect that some contributors will be more open to that than others.

This isn't necessarily all a reply to your comment, just what came to mind reading it.