text describing how other teams are enabled to make decisions.

[pnkfelix]

No description provided.

[RalfJung]

How would I ensure such a thing? The docs should state that.

[traviscross]

It'd need to be nominated.

But I think this gets to where a proposal like this gets tricky. Things that we want to be aware of (to potentially object to) but will move forward without us have to go to the top of our agenda. So this has the effect of forcing all of these items to the top. But if they're at the top anyway, then there's not much point in delegating them, since they'd get handled quickly.

So it seems to me that we either need to be OK delegating these on the understanding we may never see most of these cases at all, or only see them long afterward in a kind of retrospective, or that we want to continue approving these. If we want to continue approving them, we can of course choose to prioritize these, which is what we already do (e.g., why today's item was right near the top).

[the8472]

You can have a list of FYI without committing the entire team to look over them. Perhaps someone is interested and will look anyway, but that's not the same as putting it on an agenda for consensus-approval.

[RalfJung]

It'd need to be nominated.

So if we want lang team to decide something we nominate it, and if we want lang team to just be informed we... nominate it? I must be missing something.

[pnkfelix]

I agree that just a nomination seems like it won't suffice, not without tooling (or human processes) to analyze the reason-for-nomination and pull such cases to the top of the agenda.

From my point-of-view, there are some reasonable options here:

1. Add a new github label, e.g. I-lang-attention, for items that are meant to be put on the agenda but not given discussion time.
2. Make the protocol here be "reach out to whichever lang team member is currently preparing the weekly agenda", or
3. Slight variation on the above: reach out to any lang team member via zulip, and let them be responsible for folding it into the agenda.
4. Make a separate document that holds these items, and then fold that document into the agenda each week.

I expect this to be a rare event, so I don't think the ceremony associated with option 4 makes sense.

Options 1, 2, or 3 sound okay. but its easy for me to claim Option 2 is "easy" since I'm not the one preparing the agenda. (And I'm not always on top of my notifications, so I shouldn't be so glib in suggesting option 3...)

[the8472]

related/prior art: self-approval of PRs. It's a violation of procedure/responsibilities but people occasionally do it anyway for reasons. It's usually accompanied by an explanation why and notifying others to make it clear that nothing sneaky is going on and that they can doublecheck later if desired.

[traviscross]

If the delegated items end up requiring reading a lot of other background material in order to acquire necessary context, then we indeed would have a problem here.

Here's some context on my thoughts on this.

Items that seem like perfunctory sign-offs for us already go straight to the top of the agenda. I go through all new nominated items, and if something seems like it's going to be an easy yes for us, that saturates the sorting metric we use (perhaps below only the time-sensitive). I usually write language on these items to prompt us that it's probably an easy OK. E.g., "[trusted long-time contributor X] suggests to us that this is a bug and we should go forward with Y. Do we agree?"

So I feel like we already have evidence on how long it takes to build the necessary context on these items -- it's however long they take to process today.

Some of these do go fairly quickly -- but not so quickly that we could blow through a list of them in a few dozen seconds. There's just kind of a hard minimum on how long it takes to load up what's going on. And I don't think there's a difference in how long this takes between us deciding to give a perfunctory OK versus checking that we would have given such an OK.

And, every once in awhile, we do decide to dig into something that seemed perfunctory, and we either don't give the OK or end up asking for things first.

So, my feeling is that either we need to spend about the same amount of time reviewing these (in some form, synchronously or not), or (like all forms of delegation) we need to be OK with sometimes finding out later that things happened that we ourselves would have chosen to do differently.

[tmandry]

Yeah we should just clarify exactly what types of decisions we're okay with delegating and accepting not-our-favorite outcome on. Reversible decisions like lints are a good starting candidate.

[pnkfelix]

To be clear: The PR that led to my writing this proposal was not itself a lint: rust-lang/rust#129422

However, I do think PR #129422 can be accurately categorized as a "reversible decision". Namely, that PR was a decision to change repr(Rust) from being a no-op in some contexts to instead being an error (as "obvious nonsense").

Much like lints, I do think that does serve as an example of a reversible decision (in that we can always backtrack from error back again to no-op). But it's also not quite the same as a two-way door (i.e. we cannot in general go from no-op to error -- it was allowable in this context since the PR author had done due diligence to determine risk of fallout was amazingly low).

---

I write all this to ask: Do you actually want me to attempt to encode a policy for which decisions are delegatable into this PR? Maybe we should just chat about it as a team in the meeting tomorrow before I bother to try to write something up, to make sure we're all on the same page first.

[pnkfelix]

ah well I took a swing at revising the text anyway: 33dcca7

[pnkfelix]

For T-lang discussion:

1. Are we happy with the text that attempts to delimit the scope of what decisions we are comfortable delegating?
2. Are we happy with the proposal to add a new distinct label for delegated decisions that need to be put onto the T-lang agenda? (I assume the label gets removed after the issue/PR has been put onto an agenda and the corresponding T-lang meeting actually occurs, though we didn't spell that out in the conversation here...)

[traviscross]

To your item number 2, if we did this, I'd actually prefer a persistent label (e.g. ??-lang-delegated) so that there's a way to search for all things that imply lang decisions but that weren't made by lang.

(If we actively reviewed such an item in a meeting and ended up signing off on it, we could remove the label as the decision would be explicitly ours at that point.)

[traviscross]

I've added an I-lang-easy-decision label to rust-lang/rust and have started applying it in places where people suggest that it should be an easy call for us.

One partial step we could take here, to collect data, would be to ask people to apply this label when appropriate when making nominations. Then we could cross-check our sense of what other people think is an easy decision for us with what we think is an easy decision or not.