-
Notifications
You must be signed in to change notification settings - Fork 54
replace initiatives with a newer, lighterweight process #173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@rust-lang/lang I updated some of the pages based on the meeting by adding FAQs and the like, hopefully capturing the spirit of what we were saying! In particular I expanded the experimentation page to capture the idea of the two roles we see:
I said that these can be the same person, but in that case somebody else should second the PR that adds the feature gate. |
52526b5 to
8a0b80a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nikomatsakis during the meeting you had a diagram, but I don't see it here. Maybe you forgot to add it to the commit? (Edit: never mind, I totally managed to a review a small subset of the changes... somehow).
| * Once you've found a champion, open a PR adding a new feature gate to the compile and create an associated tracking issue. | ||
| * The PR should include a write-up documenting the motivation and outline of what they are trying to achieve. | ||
| * The feature gate should be marked as 'experimental', so that users get warnings if they try to use it. This flag has to stay until an RFC is accepted, even if the implementation is in good shape. | ||
| * The lang-team champion will "second" the PR, starting an FCP. Once the FCP completes, the PR can land and implementation work begins (always gated under the new feature gate). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a regular FCP (i.e., rfcbot)? Or the new process we're thinking about?
(Or the not-actually-full-team checkbox kind of partially existing MCP FCP where it isn't tracked by automation)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was imagining this as using the new bot, but since that's not available, we should discuss how to achieve it. I would be fine with an interim process of "just use rfcbot", or of "just use rfcbot, but you can check all the boxes".
1f9f887 to
da9de3c
Compare
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
|
Pushed various updates, taking into account @Mark-Simulacrum's suggestions (thanks!). |
|
@rfcbot fcp merge I'd like to get folks to review this and agree to it. We discussed it some in the meeting, and I don't think I really deviated from that, but nonetheless. |
|
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. 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. |
|
Thanks for working all this out! The simplifications look like a good match for what often happens, and I like the emphasis on getting RFCs a bit more often than we have recently. @rfcbot reviewed |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
The current diagram sort of makes it confusing about whom the two boxes on the right side apply to. (Or, alternatively, it makes it confusing to whom the box on top, about "experienced contributor", is being directed at: Is it aimed at everyone, including people proposing small tweaks to existing features, or is it solely aimed at people proposing new features or other large changes?) Maybe consider revising the diagram so that the "new feature, or complex change" box now has a "yes" arc that flows into the "experienced contributor" question box, and a "no" arc that flows into the "okay, this must be a small addition or tweak to existing feature box." (The biggest reason I suggest this: the current diagram has that "experienced contributor" box at the top, and its easy for people to see that, and start there, without even noticing the other boxes on the side. This means experienced contributors may well overlook the fact that they need not open a tracking issue if they're talking about a minor change. Obviously if they read the text itself, they would see the alternative path you describe there, but I suspect many people may consult the diagram without looking much at the text.) Having said that, I'm not registering this as a formal concern; its just a nitpick. |
|
I've pushed up some edits and resolved the concerns. I'm going to go ahead and merge this although the FCP has not expired, because I want to be able to link to it as I go through issues and do housekeeping. |
This PR proposes a lighterweight initiative process. The summary is this:
I removed the old initiative pages and redirect them to the new summary.
I've uploaded a preview to http://smallcultfollowing.com/lang-team-2022-09-20-preview/