Proposal
Stop using MCPs or FCPs in the types-team repository. When proposing new initiatives or larger work, use Project Goals instead. This has been discussed at the AllHands, but I want to make this explicit.
This has a few constraints on Project Goals, so it'd be nice for somebody from @rust-lang/goals to confirm that our understanding is correct here:
- We are able to add new Project Goals at any point of the year, it does not have to go through a central RFC. It is possible to adjust already accepted Project Goals with minimal overhead
- The Types Team is able to
@rustbot second or @rfcbot merge Project Goal PRs in the project goal repository
Tracking major type system changes as Project Goals makes them more visible to the rest of the project and the wider community. We've discussed this with members of @rust-lang/lang and would like them to do the same for Lang Experiments, unifying the language experimentation and evolution process. This should also make it significantly nicer to propose changes which require buy-in from multiple teams. One can open a single Project Goal which then gets approval by each of the affected teams. This ideally relies on being able to have multiple distinct @rustbot second on a single issue.
Reference level explanation
For large changes which fall under our stability guarantees, a Types Team FCP is required. This includes stabilizing a new feature and any other user-visible changes. Such changes should always have an accompanying Stabilization Proposal. For now, significant enough changes may also require a separate RFC. Types Team FCPs are also required for changes to our processes, such as this one :>
When proposing major refactorings, experimental features, or initiatives, we will now require a Project Goal Proposal which is accepted after a @rustbot second. For very large changes which cannot easily be reverted, a full-team FCP may be appropriate.
For smaller changes which fit into a single PR, a Project Goal is likely unnecessary. For changes which impact future work, we require a @rustbot second or Types Team FCP on the PR itself or on a free-standing issue on https://github.com/rust-lang/rust. Such changes include major performance optimizations, introducing widely used internal APIs, or any other changes which would be difficult to revert at a later point.
Mentors or Reviewers
This is mainly a change to our procedures. We need to make sure to update the relevant information sources. I actually don't know where our current procedures are documented, but we should definitely do this 😁
Process
The main points of the Major Change Process are as follows:
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Proposal
Stop using MCPs or FCPs in the
types-teamrepository. When proposing new initiatives or larger work, use Project Goals instead. This has been discussed at the AllHands, but I want to make this explicit.This has a few constraints on Project Goals, so it'd be nice for somebody from @rust-lang/goals to confirm that our understanding is correct here:
@rustbot secondor@rfcbot mergeProject Goal PRs in the project goal repositoryTracking major type system changes as Project Goals makes them more visible to the rest of the project and the wider community. We've discussed this with members of @rust-lang/lang and would like them to do the same for Lang Experiments, unifying the language experimentation and evolution process. This should also make it significantly nicer to propose changes which require buy-in from multiple teams. One can open a single Project Goal which then gets approval by each of the affected teams. This ideally relies on being able to have multiple distinct
@rustbot secondon a single issue.Reference level explanation
For large changes which fall under our stability guarantees, a Types Team FCP is required. This includes stabilizing a new feature and any other user-visible changes. Such changes should always have an accompanying Stabilization Proposal. For now, significant enough changes may also require a separate RFC. Types Team FCPs are also required for changes to our processes, such as this one :>
When proposing major refactorings, experimental features, or initiatives, we will now require a Project Goal Proposal which is accepted after a
@rustbot second. For very large changes which cannot easily be reverted, a full-team FCP may be appropriate.For smaller changes which fit into a single PR, a Project Goal is likely unnecessary. For changes which impact future work, we require a
@rustbot secondor Types Team FCP on the PR itself or on a free-standing issue on https://github.com/rust-lang/rust. Such changes include major performance optimizations, introducing widely used internal APIs, or any other changes which would be difficult to revert at a later point.Mentors or Reviewers
This is mainly a change to our procedures. We need to make sure to update the relevant information sources. I actually don't know where our current procedures are documented, but we should definitely do this 😁
Process
The main points of the Major Change Process are as follows:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.