@T-compiler/WG-meta :wave:
pretty sure that @nikomatsakis would like to talk about draft process that we should post as an RFC
and if we have time I'd like to talk about the ideas stated in #t-compiler > active working groups
in particular I've opened compiler-team#264
gah
I'm here :)
mostly I'd like to move that process forward
I'm actually feeling pretty good about the whole "find someone who likes the idea and post it during the announcements at a triage meeting" part of it
I think we should probably specify that we are going to create a #t-compiler/major-change-proposals
stream
and then the process is:
:wave:
I guess that's what we already wrote
makes sense :+1:
I think we should discuss "blocking objections" a bit
I don't want to wind up in the situation of "indefinite blocks" that we get elsewhere
at the same time, I don't want us to just barrel forward
there are two pathologies and it's hard to navigate between them
It all kind of comes down I guess to overall bandwidth.
yeah
yeah, so I think the bandwidth and energy factor is really important
if you don't have time or energy you may overlook some stuff and end with proposals that wouldn't have been accepted
or something like that
well that's the too hard to block, your summary was perfect :)
if someone blocks, can we just deal with it at a design meeting?
I think so
This actually connects to the "consitution" question
obviously that could still cause problems, if someone is being troublesome and that ends up filling up design meeting slots
but at least we shouldn't end up with "indefinite blocking"; progress should be made eventually
i.e., I'd ultimately like us to have a clearer set of "deciders", @pnkfelix and I were talking about the idea of a kind of "technical steering committee" that is a few folks who are making the final decisions
(at least in complex cases...)
but I don't think that has to be part of this specific ida
I think it suffices for now to say "when an objection is raised, you should discuss, and if it you want to create space for the discussion, file a design meeting"
I maybe wouldn't even phrase as 'objection', maybe there's a better term
I guess we call them "concerns" elsewhere
nikomatsakis said:
i.e., I'd ultimately like us to have a clearer set of "deciders", pnkfelix and I were talking about the idea of a kind of "technical steering committee" that is a few folks who are making the final decisions
is this really needed? isn't enough having you and @pnkfelix as compiler team leaders giving the final call?
probably
in the cases where that's needed I guess we will mostly have consensus :)
technicaly, though we've rarely exercised this,
the original team rfc did state that "in the case where consensus cannot be reached, the team lead decides"
(something I saw recently when re-reading)
nikomatsakis said:
I maybe wouldn't even phrase as 'objection', maybe there's a better term
yeah more positive words are better than object and concern :)
I have a question
this is something I just wrote -- it's a minor detail -- but I'm basically just wondering about
I think that FCP should always "begin" at some synchronous point
so that folks can skim meeting blog posts or whatever and see what's going on
does that make sense?
I'm imagining then that part of the "pre-triage" procss for prioritization wg
would be to skim a list of "major change candidates" or something?
or maybe people add it to the list themselves when they "second it"
yeah I think it makes sense
I think we want to enable a structure where the decision making power/responsibility is rotated through the membership
(sorry I was responding to a message way way back up there...)
You mean relating to the TSC? That is true, that was a motivation too
I also think a slightly larger TSC would be better than just the two leads
but for now it's ok
yes the Technical Steering Committee
anyway it doesn't matter for the short term
thinking a bit more...
its more a question of how best to govern things in the long run
if part of the role of the TSC is to select the things to do, as well
nowadays I have to assume that we all need to be a little more serious about bus factors
...you could imagine having a kind of election early on to elect TSC members, which might help to set our agenda for the year...
but yeah I'd rather get this MCP thing through first :)
okay, yeah, sorry, I didn't mean to forcibly continue an abandoned digression. :slight_smile:
side note @pnkfelix that I still want to raise the question of surveying our ongoing projects, project groups, etc
pnkfelix said:
yes the Technical Steering Committee
well another way to see it is if you have the leads (as I know you're) always listening and trying to have people reach consensus, rather than having a vertical style, I guess something like that is not needed :)
but you know better than I do, so ... :)
btw
we don't have anything in the process to reject a MCP
how do we decide to "close" one of these things? :)
seems important to discuss
(I think something @nikomatsakis left unsaid is that there is a distinction between technical steering and social steering.)
(team leads may need to do both. Not everyone is good at both.)
yes, although I do think the role of the TSC would also be to do a lot of listening
this comes back a little bit to "how do we decide"
in paricular, it's easier to judge "consensus",
but I can see that if we decide "no we are not doing this"
that may never get a "consensus"
maybe they just time out
right
(and/or the leads can decide)
"after 3 months of inactivity, an issue can be closed", something like that?
ah
hah
aren't we the project that has the Postponed label
that just leaves things to die
sigh
I think I would say something like
not sure how imp't the first bullet is
maybe we don't need to specify a time, but I think it'd be kind of useful
but basically I imagine what will happen in practice is that every once in a while we'll sweep the list and "gc" old ideas
that never quite got off the ground
I'm thinking though about some of the trickier cases we've been confronted with
sorry but I need to leave for a bit, going to read in a while
e.g., the "end to end" query PRs that led to an inconclusive design meeting
I guess that it would be valid after some time to close that proposal
i.e., mw and I had unresolved objections, we had the design meeting, it doesn't seem like we were going to reach a consensus on the existing approach
gah, I guess it's "lang pre-triage" time