Stream: t-lang/meta

Topic: staged proposals


view this post on Zulip nikomatsakis (Nov 02 2020 at 21:36):

So @Josh Triplett and I have been talking a bit about staging and proposals and we drew up a refined proposal. The main ideas are:

This is intended to help line up with the libs + compiler processes. After cleaning up the above hackmd I hope to shop it around to those folks. (I guess that compiler doesn't need most of this, it's mainly the "seconding" that aligns, but I think the rough model in some simplified form may also fit there.)

(cc @XAMPPRocky, @pnkfelix, @Ashley Mannix)

view this post on Zulip Josh Triplett (Nov 02 2020 at 21:50):

Ideally, libs should be able to use this process unmodified.

Compiler would probably skip the RFC stage for most proposals (and charter may be as small as "a paragraph written in the initial proposal"). Some things would go through impl then stable (such as -Z flags or other things that have a nightly-only gating mechanism), while insta-stable things (like architectural changes to the compiler) would move directly to stable when implemented.

view this post on Zulip Ashley Mannix (Nov 04 2020 at 23:02):

I think this exact process could be applied to Libs :+1: The way I think things currently tend to work is:

With this process we could either skip the pre-RFC phase altogether in favor of a proposal, or instead of promoting that to an RFC, it becomes a charter to see that through to a full RFC and stabilization.

One thing I am wondering is whether our new takes on these design/development phases are producing public RFCs a bit too late. I think we don't tend to get complete feedback on proposals until there's an RFC and a forcing function to give complete feedback (it'll get stabilized without your input if you don't comment). That seems to have played out a bit in the safe transmute proposal, where the group worked for a long time exploring the design space and came up with a complete and extensive solution that satisfied all the constraints they'd discovered, but was based on a few assumptions that were deemed unsuitable for a standard library feature.

Maybe we just need to make sure we give useful feedback throughout the brainstorming process by checking in on them. That might be covered by the checkpoints between stages.

view this post on Zulip Ashley Mannix (Nov 04 2020 at 23:05):

The main thing I'd love to try avoid in Libs is having a single person "own" an RFC when possible, because the burden of dealing with feedback on your own is heavy. It seems like stages would help there too

view this post on Zulip Joshua Nelson (Nov 04 2020 at 23:10):

Ashley Mannix said:

The main thing I'd love to try avoid in Libs is having a single person "own" an RFC when possible, because the burden of dealing with feedback on your own is heavy. It seems like stages would help there too

/me has been avoiding https://github.com/rust-lang/rfcs/pull/2988 for a while

view this post on Zulip nikomatsakis (Nov 06 2020 at 16:38):

@Ashley Mannix yes, I agree, that is a goal for project groups etc in general

view this post on Zulip nikomatsakis (Nov 06 2020 at 16:38):

(avoiding a single owner)

view this post on Zulip nikomatsakis (Nov 06 2020 at 16:38):

though i'm not sure if it always works out

view this post on Zulip nikomatsakis (Nov 06 2020 at 16:38):

that said, good to hear that this structure seems like it could fit, I'd like to take some time and expand the explanation a bit

view this post on Zulip nikomatsakis (Nov 06 2020 at 16:39):

one of the questions we need to pin down I think is the tracking issue, but I think i've decided we should just be using a single tracking issue in the rust repo and just try to apply the policy we've been using on lang-team tracking issues, where we discourage general comments and use it more for updates

view this post on Zulip Ashley Mannix (Nov 08 2020 at 22:27):

@nikomatsakis Are these the tracking issues for the project groups themselves? Would we like to try follow a similar pattern for feature tracking issues too? Mixing general discussion with status updates isn't always the best experience in GitHub

view this post on Zulip nikomatsakis (Nov 09 2020 at 14:35):

So the lang-team has issues for each "project group", but what I was proposing is basically repurposing tracking issues so that they are not a forum for discussion, only for status updates. Probably we should include explicit instructions on how to notify folks of problems or raise comments/questions about the design.

view this post on Zulip nikomatsakis (Nov 09 2020 at 14:35):

I'd then remove the lang-team issues and just use the main tracking issue

view this post on Zulip nikomatsakis (Nov 09 2020 at 14:35):

(perhaps with some labels or other metadata)

view this post on Zulip nikomatsakis (Nov 09 2020 at 14:35):

@Ashley Mannix :point_up:

view this post on Zulip Ashley Mannix (Dec 16 2020 at 09:49):

Sorry for taking so long to circle back around! So we'd possibly use a combination of C-tracking-issue T-{team} C-project-group PG-{group}? It all makes me wish GitHub queries supported arbitrary unions, intersections and negations of labels :smile:

view this post on Zulip nikomatsakis (Dec 16 2020 at 10:48):

no worries, I've been quite slow on following up here, I still have in my head to make this into a concrete proposal


Last updated: Jan 26 2022 at 07:32 UTC