Skip to content
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.

Sign up for GitHub

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

text describing how other teams are enabled to make decisions. #290

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

text describing how other teams are enabled to make decisions. #290

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e370cf5
text describing how other teams are enabled to make decisions.
pnkfelix Sep 18, 2024
7b3ac83
Update src/decision_process/reference.md
pnkfelix Sep 19, 2024
33dcca7
refine text to narrow scope of delegated decisions to reversible deci…
pnkfelix Sep 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions src/decision_process/reference.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,32 @@
agree with the decision. They (or another team member) should then set their
status to `dissent`.

# Delegation of decisions

We trust other teams to make decisions about their areas of expertise, without
waiting on language team approval on every such decision.

If the matter being decided seems non-trival or subtle, then we do wish to be
part of the decision-making process. But the answer for a problem seems obvious,
pnkfelix marked this conversation as resolved.
Show resolved Hide resolved
pnkfelix marked this conversation as resolved.
Show resolved Hide resolved
then it need not wait on T-lang nomination and approval.

For example, we trust the compiler team to fix obvious bugs that are not
intended to be part of the Rust language and have minimal known breakage. See
for instance [PR #129422](https://github.com/rust-lang/rust/pull/129422), which
corrected a mistake in the implementation of `#[repr(Rust)]`).

However, when another team makes a language-relevant decision, the language team
also wants to be aware of it. This way we can ensure that the set of delegated
decisions do not drift out of their intended scope.

If your team is making a decision that impacts the language, please ensure that
a link to the decision (and any related discussion) appears in the agenda for
the language team's triage upcoming meeting.
Comment on lines +83 to +85
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@traviscross traviscross Sep 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@traviscross traviscross Sep 20, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


(If a decision cannot be easily descibed and justified in a short snippet of
text, then it possibly needs to be brought to the attention of the language team
through the normal nomination process.)

# Rustbot commands

The following commands are accepted by rustbot. (Commands written below omit
Expand Down
Loading