@T-compiler/WG-meta :wave:

Hey @Santiago Pastorino

o/

today we had our check-in :), you've probably seen it on the other thread but anyway worth mentioning that I've created this doc so we can keep our status up to date :)

with the aim of making check-ins easier

anyway, related to our current things, what do you @nikomatsakis think we should focus on?

good question

I was just pondering it

would be nice to land diagnostics but that's on @Esteban Küber

also, what about the major changes PR?, is there something we can do to move that forward?

I'm looking

the template is probably fine

we could just land it

but I think what we're missing right now

is .. what happens when a major change proposal is filed?

we could spend a bit of time talking about that

there have been a few, right?

I have a vague sense that

we should (a) create a t-compiler/major-changes

and we should have some kind of "FCP"

basically: If conversation seems to die down

we sort of summarize what was said and see if there's a vague consensus "for" or "against",

then maybe we ananounce it in compiler triage meetings and wait a week or something?

I mean this doesn't require all the checkmarks etc

I feel like the goal is more to keep people aware and spark conversation

so you're saying that after discussing a major change, if things die down we should or accept or reject following an FCP process?

now I'm thinking I should review the notes from the design meeting where we talked about this

I guess the question is "should there be a decision"

or is this just like "advertising" and no decision is needed

maybe the latter is fine

like, we let the decisions come from the PRs

and of course if there's strong opposition

I don't want a lot of annoying process we';ll fail to follow :)

nikomatsakis said:

I guess the question is "should there be a decision"

yes, and the decision could totally be, this is deferred until X date or until Y thing happens before

but I feel like having someone "announce" a major change proposal (and then creating an associated stream)

and then we collect those and highlight them at the meeting

nikomatsakis said:

or is this just like "advertising" and no decision is needed

what kind of advertising are you referring to?

and maybe that suffices? if after some time there isn't anyone making a strong objection (perhaps we have a formal way to do that) we assume its implicitly "ok for now"?

yes

that seems fine

@Santiago Pastorino ok so one option I'm imagining, to be concrete, is:

You want to make some "major change":

• You open a major change proposal
• You create a zulip stream with a link to it
• We announce this in next triage meeting
• If by the next triage meeting nobody says "GAH! STOP!" then it's assumed you're good to explore

(Of course, you can start doing work whenever, but we can't land the PR without that)

(And similarly having done the process doesn't mean somebody won't appear on the PR with concerns)

But it's just a way to give people a "head's up"

I guess it's important the explore part of your phrase

By that I meant

It should be interpreted as "nobody blocks this yet" not "everybody accepts this"

I meant, after nobody said that you can explore but at some point somebody can object and the work may never land

exactly :)

the only thing missing then is like

maybe it's good to talk about why someone might block

Could we integrate this with the tracking issue?

Integrate what exactly with what tracking issue, @DPC ?

As in the change proposal is the tracking issue

nikomatsakis said:

maybe it's good to talk about why someone might block

I guess because people realize at some point that the idea is not as good as it was originally thought

could happen that somebody was not aware of the proposal but then they realized and are against

people from the community may realize about the change and come up with suggestions or ideas that make the proposal be not the best one

right

I guess I also just think

if people haven't actively checked a box

there's a good chance they were just on vacation that week :)

etc

not to mention of course that impl experience or further reflection may result in other kinds of problems

ok, so I feel pretty good about this idea of "you have to advertise"

I'm thinking about the tracking issue question, @DPC

i.e., create a tracking issue on rust-lang/rust .. (or maybe compiler-team?)

I kind of like moving some of this stuff out of rust-lang rust but either would do I suppose

nikomatsakis said:

there's a good chance they were just on vacation that week :)

yeah was thinking about that too, if people are on vacation they may not see but when they are back they may be against :)

okay go ahead

nikomatsakis said:

not to mention of course that impl experience or further reflection may result in other kinds of problems

exactly, that often happens

design meeting notes

so we had something different there

what we said was

seems like

there has to be some positive review

which actually makes a lot of sense

right

i.e., the major change should have a kind of "second" and no objections

ah well

actually we were smarter than that

I had forgotten about this

the idea woudl be that for a major change to go forward

it needs to also have a designed reviewer

and that person acts implicitly as the "second" I suppose

yeah forgot about all that too

but yeah

but this also helps to scale how many "major cahnges" we try to do :)

ok, I quite like this

so what is the "next step" to make it official I guess

nikomatsakis said:

but this also helps to scale how many "major cahnges" we try to do :)

yeah this is very important

so the idea is:

• you can open a major change proposal

• to be accepted, it requires a reviewer who approves

• people can also raise objections

• they may also agree to review but request approval from others

:+1:

• It should be announced at a compiler team meeting but maybe we don't require any particular "waiting period"

• and I think a dedicated zulip stream is good

to help people note new ideas

nikomatsakis said:

• It should be announced at a compiler team meeting but maybe we don't require any particular "waiting period"

maybe we should just say: when a MCP is created, it is announced, and when it is "accepted" with a reviewer, that is announced too (or both at once if it moves quick)

this gives people a chance to say "wait..."

well, I think the regular thing should be to give a week, but you're allowed to move quicker if it's considered "small"

Ok, do we want an RFC?

to help make it feel "official"?

at least we need to write up docs for forge, but I sort of lean towards an RFC

I think it's going to take some "muscle" to make this work

I am also thinking that the triage team should be somewhat involved...

or at least there should be some folks who are kind of "monitoring" the process

and "executing" it

(side note: I wonder if "wg-meta" should just become the triage group)

well, maybe not.

I'm just thinking that I feel like we need some group of "folks who are executing compiler team procedures"

nikomatsakis said:

or at least there should be some folks who are kind of "monitoring" the process

in particular, I sort of like the idea that instead of designating yourself as a reviewer, you tell the "fcp officer" to put you down, which also means they can add it to the meeting agenda, etc

maybe we can automate that

I can help monitor those :slight_smile:

sorry, got distracted reading a bit :)

nikomatsakis said:

at least we need to write up docs for forge, but I sort of lean towards an RFC

agreed on RFC, I guess

nikomatsakis said:

I am also thinking that the triage team should be somewhat involved...

unsure I understand this

ahh after reading the rest I think I get it

I was thinking about stuff like

"this should be announced at the compiler team meeting"

and how we make that happen

do these MCPs get FCPd?

I think no

or at east, not in the sense of everybody checks their box

that's too much overhead

so ... I'm not sure if this should be triage, it's more like we need 2 groups

triage on one side and people executing and following compiler procedures on another one

but I think the idea that "you should have a reviewer and approval from one other owner of the code"

and "it should be announced and you should wait a time"

so it's kind of like the check boxes, but you only need 1 to go, or something like that

Santiago Pastorino said:

triage on one side and people executing and following compiler procedures on another one

yeah I realized as I was talking it's maybe different

yep

earlier we were talking about having designated "officers"

I think this is sort of what I mean

also that comes to meta is too vague

and there'd probably be a "triage officer" or something

(i.e., lead(s) of triage working group)

Santiago Pastorino said:

also that comes to meta is too vague

heh yes

yeah, makes sense

meeting time is over btw :) should we open an issue for major change procs and maybe summarize some of the key conclusions?

IMHO things look like triage and meta which should be compiler-procedures-wg

or something like that

seems like next step is to try and bang out an RFC

do you want me to help in some way?

not entirely sure what exactly do we want to come up with but ...

depends, do you want to try and write RFC? I had the feeling that might be arduous for you

b/c lang barrier

but maybe I'm just projecting :)

I hate writing in foreign languages

but you are much better at English than I am at any other language

hehehe :)

I guess it depends on how much work I'd take out of your shoulders :)

I'm not sure if it will cost me because of the language but if course that would add

may take because I'm not 100% sure about the process, what exactly we want to write and things like that

I may take a stab this today