#2445 Proposal: Make the "shortcut" decision process require a specific request and assent
Closed: Accepted 3 years ago by ignatenkobrain. Opened 3 years ago by bcotton.

As discussed in #2429, the shortcut decision process has a bug where a proposal may be approved before all FESCo members have the opportunity to object. Since most proposals are not harmed by waiting for the one week period (or until all members have voted), the shortcut process should be something specifically requested by the proposer and FESCo members should agree that the request is suitable for a shortcut process.

I have submitted a pull request to the docs that adds the following to the approval policy:

In order to allow all FESCo members the opportunity to weigh in, the shortcut procedure must be specifically requested by the person presenting the proposal and assented to by FESCo members who cast a vote.


The problem with this is that it means we go back to having to have huge meeting backlogs by default again. I believe the reason why this was implemented was so that we could process these things more quickly and leave meetings to be the time for deliberation on the things that need it.

This was re-affirmed when the policy was amended 7 months ago to add the "fast-track kill" -7 option: https://pagure.io/fesco/fesco-docs/pull-request/22

The policy is deliberately symmetric for +7 and -7. And in practice, everyone will want the fast track option anyway, so we'd be adding boilerplate for no benefit (other than to slow down FESco's ability to process change proposals if people don't know about requesting fast track).

So in general, I'm NACK to this idea, since it's a bureaucratic chokepoint that doesn't provide a lot of value and deliberately goes against what we've been trying to do with the "lazy consensus" model that Fedora governance is generally built upon.

The problem with this is that it means we go back to having to have huge meeting backlogs by default again.

It would only get added to the meeting agenda if someone is -1. Otherwise, it waits until all members have voted or one week has passed. For most issues, that's no change from the current, but it does address rare cases like #2429.

Since FESCo is nobody's day job (even the Red Hat employees serve on a volunteer basis), we should default to being a little slower in our decision making so that people have a chance to weigh in.

deliberately goes against what we've been trying to do with the "lazy consensus" model that Fedora governance is generally built upon.

Yes, but lazy consensus is predicated on the idea that people have a chance to object. #2429 was approved in 31.5 hours, which is a pretty short window, particularly if someone is AFK (or busy at $dayjob) for a day.

In that particular case, the person who ultimately put -1 had in fact commented earlier in that ticket, but only put the -1 several days after, even after the auto +7 which then had another +1 the next day.

If that person had placed the -1 up front, then it would have stopped and triggered a meeting deliberation as normal. Instead, the vote was withheld, which is essentially the same as not voting at all yet, so it proceeded as normal.

The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

In that particular case, the person who ultimately put -1 had in fact commented earlier in that ticket, but only put the -1 several days after, even after the auto +7 which then had another +1 the next day.
If that person had placed the -1 up front, then it would have stopped and triggered a meeting deliberation as normal. Instead, the vote was withheld, which is essentially the same as not voting at all yet, so it proceeded as normal.

Yeah, this isn't the ideal example case. But the question that we're ultimately getting at is: what's the minimum time for a FESCo member to vote?

The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

Agreed, and I don't think it should.

Yeah, this isn't the ideal example case. But the question that we're ultimately getting at is: what's the minimum time for a FESCo member to vote?

IMO if 7 people vote within few hours as +1, that should be approved even if last 2 members did not have chance to vote.

The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

Probably we should highlight that if you don't want ticket to be auto-approved by the fasttrack / time, you should vote -1.

@bcotton

Since FESCo is nobody's day job (even the Red Hat employees serve on a volunteer basis), we should default to being a little slower in our decision making so that people have a chance to weigh in.

Well, I think everybody expect that FESCo members will put their concerns on the devel ML unless those are written by the other people. And also all members are supposed to read most (all?) the replies so the issues won't be silently dropped.

IMO if 7 people vote within few hours as +1, that should be approved even if last 2 members did not have chance to vote.

There is some community perception value in not fast-tracking controversial decisions, even if the end result is the same.

Probably we should highlight that if you don't want ticket to be auto-approved by the fasttrack / time, you should vote -1.

But the point is that a proposal can be approved before someone has the chance to do that. If I open a ticket for a change proposal toward the end of my workday, North Americans and night-owl Europeans could all vote before members from APAC or Europeans who aren't checking their email at 11pm. Or else someone who is +1 would have to vote -1 on it to "hold the door open" for the rest of the members.

Well, I think everybody expect that FESCo members will put their concerns on the devel ML unless those are written by the other people. And also all members are supposed to read most (all?) the replies so the issues won't be silently dropped.

Yes, but FESCo doesn't vote in the mailing list.

In that particular case, the person who ultimately put -1 had in fact commented earlier in that ticket, but only put the -1 several days after, even after the auto +7 which then had another +1 the next day.
If that person had placed the -1 up front, then it would have stopped and triggered a meeting deliberation as normal. Instead, the vote was withheld, which is essentially the same as not voting at all yet, so it proceeded as normal.
The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

You can blame me, that's fine. My assumption with the btrfs proposal was that it was large enough that we would allow time for all members to weigh in and even discuss it in the meeting. To me, the intent for the fast track option is for more routine things and not huge fundamental changes.

In that particular case, the person who ultimately put -1 had in fact commented earlier in that ticket, but only put the -1 several days after, even after the auto +7 which then had another +1 the next day.
If that person had placed the -1 up front, then it would have stopped and triggered a meeting deliberation as normal. Instead, the vote was withheld, which is essentially the same as not voting at all yet, so it proceeded as normal.

Yeah, this isn't the ideal example case. But the question that we're ultimately getting at is: what's the minimum time for a FESCo member to vote?

A week is not unreasonable to me.

The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

Agreed, and I don't think it should.

Yeah, this isn't the ideal example case. But the question that we're ultimately getting at is: what's the minimum time for a FESCo member to vote?

IMO if 7 people vote within few hours as +1, that should be approved even if last 2 members did not have chance to vote.

Why? The only thing you're doing at this point is deliberately excluding FESCo members who have not weighed in.

The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

Probably we should highlight that if you don't want ticket to be auto-approved by the fasttrack / time, you should vote -1.

If that's the policy now, I'd like to have that explicitly stated.

I'd also like for people to generally have good intentions here and understand what @bcotton was saying.... this is all volunteer basis. We should all have an opportunity to read up on issues discussed and form questions, objections, or opinions. 31.5 hours is not enough.

I schedule time in my work week for FESCo work and my assumption is everyone else does too, certainly considering how difficult it's been to move either the FESCo or Council meeting due to conflicts with everyone's day jobs. A week is a reasonable amount of time for all members to work this in to their schedules and provide input.

@bcotton

Since FESCo is nobody's day job (even the Red Hat employees serve on a volunteer basis), we should default to being a little slower in our decision making so that people have a chance to weigh in.

Well, I think everybody expect that FESCo members will put their concerns on the devel ML unless those are written by the other people. And also all members are supposed to read most (all?) the replies so the issues won't be silently dropped.

I do this and it's not trivial work. I schedule time to read through threads. I make notes and change things I've written down as new information comes up. I can't possibly be the only one doing that.

In that particular case, the person who ultimately put -1 had in fact commented earlier in that ticket, but only put the -1 several days after, even after the auto +7 which then had another +1 the next day.
If that person had placed the -1 up front, then it would have stopped and triggered a meeting deliberation as normal. Instead, the vote was withheld, which is essentially the same as not voting at all yet, so it proceeded as normal.
The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

Another point here is that I said "withholding my vote until...". In this case, my expectation was that there would be a vote. I would've appreciated a heads up from other FESCo members if this was fast tracking anyway if I wanted to weigh in.

IMO if 7 people vote within few hours as +1, that should be approved even if last 2 members did not have chance to vote.

I would strongly disagree with this. It is not unheard of for a single member of FESCo to bring up a counterpoint which makes the other members reconsider their positions. It has happened before, and will likely happen again. A week is typically not too long to wait for most issues. And this still does provide a path to request a fast-track for emergency issues as they arise.

The quirk here is the assumption that withholding a vote does anything. As I currently read the policy, it doesn't.

Probably we should highlight that if you don't want ticket to be auto-approved by the fasttrack / time, you should vote -1.

As stated above, fast track by default doesn't really buy Fedora anything, but does come with a risk. While leaving the 1 week vote in ticket as the default and Fast track as an explicitly requested option leaves flexibility where required and gives time for people members to actually read and respond to tickets appropriately by default.

The problem with this is that it means we go back to having to have huge meeting backlogs by default again.

I'm struggling to see the problem here. The purpose of those meetings is to have discussion. If you don't have all votes present in a ticket, that means that either:

  1. when it comes up in meeting, it'll be quickly decided or moved for further discussion or
  2. not everything that needs to be said has been said, and in-meeting conversation is needed

or perhaps some combination of both. If something is so temporally important that it can't wait until the next meeting, I would naïvely expect fesco members to be reachable.

And after all, if everything can just take place in the tickets, there's no point in having the meeting at all.

I'm in favor of the proposal.

Though maybe it needs an amendment to also allow a FESCo member to attach the "short-circuit tag" to a ticket, not only the original submitter.

I'm in favour too.

When originally approved, my understanding was that the fast-track mode would be only used for tickets which require swift resolution, and would need to be explicitly requested.

Though maybe it needs an amendment to also allow a FESCo member to attach the "short-circuit tag" to a ticket, not only the original submitter.

Yes. Maybe:

The fast-track procedure must be specifically requested by one of the FESCo members and is only in effect when there's agreement from other members.

(No reason stated, because "In order to allow all FESCo members the opportunity to weigh in" is not the only reason. We also mentioned community perception, etc. So I think we don't need a justification to be part of the rules.

And "there is agreement" has the advantage that if at least one person says they disagree, there is no agreement. So it's not only the assenting voices that matter, but also any potential dissenting ones. So I think this phrasing implies that there must be some support voiced by others and no disagreement for this to be effectively triggered. OTOH, I don't think we need every of the 6 voting people to repeat that they assent to the fast-track mode.)

Oh, and I think we should call this "fast-track" and not "shortcut".

The fast-track procedure must be specifically requested by one of the FESCo members and is only in effect when there's agreement from other members.

Works for me.

(No reason stated, because "In order to allow all FESCo members the opportunity to weigh in" is not the only reason. We also mentioned community perception, etc. So I think we don't need a justification to be part of the rules.

Makes sense. I included it initially as an interpretation guide for future generations, but the commit message works for that, too.

Oh, and I think we should call this "fast-track" and not "shortcut".

Agreed.

@bcotton could you update the PR then?

@bcotton could you update the PR then?

Done. I modified your proposal to indicate that the person submitting the proposal can request the fast-track. I can yank that back out if needed, but I think it's reasonable for a person to be able to say "I need this fast tracked". A FESCo member can always nack it, so it's more of a "yes, it's okay for you to ask for this" than a real change in how the proposal works.

Side notes:

1) When all 9 people vote either +1 or 0 and there is at least +5, I believe the ticket should be approved immediately, without further delay. The policy does not recognize this. Should it?

2) The -7 thing was added, so we don't have to got through such tickets on meeting agenda. Now it only applies when a fast decision was requested. Is that OK for us?

1) When all 9 people vote either +1 or 0 and there is at least +5, I believe the ticket should be approved immediately, without further delay. The policy does not recognize this. Should it?

I think it's implied, although I'll allow that there are cases where someone may have voted and change their mind from a subsequent argument. So it wouldn't hurt to make that explicit if that's the intent (I suggest treating it as a separate matter from this proposal just to keep things simple)

2) The -7 thing was added, so we don't have to got through such tickets on meeting agenda. Now it only applies when a fast decision was requested. Is that OK for us?

Ooh, my bugfix introduced a bug! I would say we'd want to have -7 apply regardless of whether or not a fast-track is requested. Thinking about the community relation impact, the harm of a quick accept is greater than a quick reject, so we could say -7 still rejects a proposal without specifically requesting. Or we could just say the chair may leave it off the agenda unless someone specifically tags it for the meeting.

wouldn't hurt to make that explicit

we could say -7 still rejects a proposal without specifically requesting

I think we should do both.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

3 years ago

I have updated the pull request incorporating the feedback from today's meeting:

  1. keep the symmetry
  2. close unanimous tickets
  3. explicitly say that tagging with 'meeting' is a nack to the fast-track process

The proposal, as it currently stands, reads:

The fast-track procedure must be specifically requested by the person submitting the proposal or a FESCo member and is only in effect when there's agreement from other members. Tagging the issue for the meeting agenda is understood to disqualify the proposal for fast-track status. Proposals that receive a unanimous vote are immediately considered approved or rejected as appropriate, independent of fast-track status.

Metadata Update from @ngompa:
- Issue untagged with: meeting

3 years ago

Does "unanimous" mean +9,0,-0 and +0,0,-9 only, or is e.g. +5, 4, -0 considered unanimous?

Does "unanimous" mean +9,0,-0 and +0,0,-9 only, or is e.g. +5, 4, -0 considered unanimous?

It refers to +9 or -9 conditions.

Diff:

- There is also a shortcut procedure, which does not require waiting for the week to be up.
+ There is also a fast-track procedure, which does not require waiting for the week to be up.
  Seven positive votes with no negative votes will immediately approve a proposal, and seven negative votes with no positive votes will immediately reject a proposal.
+ The fast-track procedure must be specifically requested by the person submitting the proposal or a FESCo member and is only in effect when there's agreement from other members.
+ Tagging the issue for the meeting agenda is understood to disqualify the proposal for fast-track status.
+ Proposals that receive a unanimous vote are immediately considered approved or rejected as appropriate, independent of fast-track status.

+1

APPROVED (+8, 0, -0), @bcotton will squash commits

@bcotton Feel free to merge PR with squashed commits :)

Metadata Update from @ignatenkobrain:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata