#1326 change to fesco replacement process?
Closed None Opened 4 years ago by mattdm.

The current process for filling vacant slots does not seem the best; this is why we opted for a special election this time around instead. Maybe we should fix that officially?

(Specifically, process seems to assume vast field of candidates and with a smaller field causes the losers in the election to fill the spots, which probably isn't the intended outcome. And failing that, the appointment process does not feel very democratic or encourage new blood.)


Idea: propose plan, take to board for ratification.

The special election approach seems like the best all-around fit, IMHO.

Related: we should probably also offer up a formal recall option. I was thinking that if the community as a whole disapproves of a member of FESCo, they should have the option to file a public Board ticket. If the person receives at least N(*) other supporting comments from FPCA+1 community members, it should force a special election. The candidate would of course be allowed to run to retain his or her seat.

N needs to be small enough that the process can be invoked when necessary, but not so small that it gets called up every time a FESCo member misspeaks on the mailing list. Perhaps 10 or 15 active community members?

Replying to [comment:2 sgallagh]:

The special election approach seems like the best all-around fit, IMHO.

Related: we should probably also offer up a formal recall option. I was thinking that if the community as a whole disapproves of a member of FESCo, they should have the option to file a public Board ticket. If the person receives at least N(*) other supporting comments from FPCA+1 community members, it should force a special election. The candidate would of course be allowed to run to retain his or her seat.

N needs to be small enough that the process can be invoked when necessary, but not so small that it gets called up every time a FESCo member misspeaks on the mailing list. Perhaps 10 or 15 active community members?

That is a very small number. It's small enough that you can get one WG or SIG that dislikes some -1 vote to band together and try to oust someone.

FESCo has been around for a very long time and we haven't needed this thus far. If a significant problem that would call for a recall showed up, I would suspect the Fedora Board could be contacted and it would deal with it appropriately if FESCo couldn't resolve it on it's own.

Well, frankly you just described pretty much the scenario I was trying to address. If a WG or two feels that a FESCo member is being problematic, they can band together and force a special election. That doesn't necessarily force the FESCo member out, but it does force them to earn re-election.

I'd be fine with setting a time limit on recalls as well (i.e. the same person cannot be recalled more than once in a Fedora release cycle).

Replying to [comment:4 sgallagh]:

Well, frankly you just described pretty much the scenario I was trying to address. If a WG or two feels that a FESCo member is being problematic, they can band together and force a special election. That doesn't necessarily force the FESCo member out, but it does force them to earn re-election.

Sorry, but I think this is a really bad idea. "Person X didn't vote for my proposal so I'm going to recall them" sounds ripe for abuse. And a single person isn't going to be a "problem" for a WG/SIG without the majority of FESCo agreeing with that person. So really your proposal has no chance to actual solve a problem for a WG/SIG unless you want to open it up to "I'm recalling all of FESCo". It also has the potential to confuse and dilute our already horrible election process. In essence, it isn't FIXING anything and it is introducing a number of potential problems.

The appeal route for a WG/SIG is not to remove members in their way. It's to escalate to a higher governing body, which is the Board.

The related problem seems to me as bad idea too. Also it sounds like more processes, which are hard to follow.

Also elections are pretty much time consuming for people involved in it. And it's already hard to find candidates. If this would be used more often, it could lead to no one to run elections and no one to run for it. And I think one year term allows for quite a good reflection of FESCO members in the next elections (if they want to be re-elected).

Otherwise, I like the idea of special elections with that note we should try to avoid having it as described above (if possible) or do bigger elections (as this were - several FESCO members stepped down).

sgallagh -- can you break the recall issue out into another ticket? I don't want to get hung up on that here.

(Also, for whatever it's worth, I'm not particularly in favor -- I think it isn't the "friends" way to go. If someone is being really problematic, I hope we can solve it by talking. And failing that, the one year term isn't so long.)

I'm sufficiently convinced to withdraw the proposal in any case.

On a related note, should we request to codify "twelve months" as a term, rather than the previous loose "two releases"?

On the issue of avoiding going through the work of an election in situations where there is little gain, here are some possibilities:

'''a)''' If there are fewer than 4 months until until the seat is due to be refilled anyway, leave it open

'''b)''' If there are fewer than 4 months ... only then temporarily appoint someone

'''c)''' If there are fewer than 4 months ... elect for those months + next full term

'''d)''' ''Always'' leave seats open unless there are at least 3 vacancies

Replying to [comment:9 sgallagh]:

I'm sufficiently convinced to withdraw the proposal in any case.

On a related note, should we request to codify "twelve months" as a term, rather than the previous loose "two releases"?

I like for it to be release-based. But maybe: "two releases, and not more than .. 15 months? Or 18 months? Or 13 months?"

Replying to [comment:10 mattdm]:

On the issue of avoiding going through the work of an election in situations where there is little gain, here are some possibilities:

'''a)''' If there are fewer than 4 months until until the seat is due to be refilled anyway, leave it open

This only works if there's some form of tie-breaker in voting.

'''b)''' If there are fewer than 4 months ... only then temporarily appoint someone

'''c)''' If there are fewer than 4 months ... elect for those months + next full term

'''d)''' ''Always'' leave seats open unless there are at least 3 vacancies

This is just a form of a) with the same problem.

Where did the magical 4 months timeframe come from, and what happened to the existing practice of appointing from the previous election's runner ups?

Replying to [comment:12 jwboyer]:

'''a)''' If there are fewer than 4 months until until the seat is due to be refilled anyway, leave it open
This only works if there's some form of tie-breaker in voting.

Well, it rarely comes to that -- highly-divided votes don't happen that often. And usually, votes aren't really between two opposing choices -- they're "do this, or the status quo". So for that, it could just be "5 votes needed to pass a resolution even when the slate isn't full".

'''b)''' If there are fewer than 4 months ... only then temporarily appoint someone

'''c)''' If there are fewer than 4 months ... elect for those months + next full term

'''d)''' ''Always'' leave seats open unless there are at least 3 vacancies

This is just a form of a) with the same problem.

Sure.

If you think that it's a ''big'' problem, we can of course just do the election every time.

Where did the magical 4 months timeframe come from, and what happened to the existing practice of appointing from the previous election's runner ups?

Sorry, "4" is an arbitrary number I picked as an example. Could be any other number.

I think the existing policy of appointing runner-ups is problematic, especially with small slates -- it can have the anti-democratic effect of putting people who specifically did not get enough community votes into office -- possibly even no votes at all in the (unlikely in reality) situation of a very unpopular candidate.

Replying to [comment:13 mattdm]:

Replying to [comment:12 jwboyer]:

'''a)''' If there are fewer than 4 months until until the seat is due to be refilled anyway, leave it open
This only works if there's some form of tie-breaker in voting.

Well, it rarely comes to that -- highly-divided votes don't happen that often. And usually, votes aren't really between two opposing choices -- they're "do this, or the status quo". So for that, it could just be "5 votes needed to pass a resolution even when the slate isn't full".

Um, if something gets 5 votes it won't be in a tie situation. You're not solving the problem I presented. You're handwaving it away as unlikely, but we also thought it was unlikely we'd have to run a special election to fill vacant FESCo seats. Let's solve the problems now instead of putting it off until we run into it. That way we might actually have less of a mess and avoid having to redo all of this again.

We have an odd number of seats to prevent ties. With all the seats filled, we require a majority vote to pass something, which means if we have 5 votes it passes. If we have 4 +1 and 4 -1 and one 0, it doesn't because it doesn't have majority. If you have an even number of seats and an even split in votes, you have neither majority nor minority. It's simple math.

Solutions:

'''1)''' Always have an odd number of seats (which would mean filling vacant ones)

'''2)''' Before votes are cast, a random seat is chosen as a non-voting seat (force odd number by dropping one)

'''3)''' Tie votes are presented to the Product WGs to vote on. Majority vote from the WGs wins.

'''4)''' Any number of other solutions that actually fix the problem.

'''b)''' If there are fewer than 4 months ... only then temporarily appoint someone

'''c)''' If there are fewer than 4 months ... elect for those months + next full term

'''d)''' ''Always'' leave seats open unless there are at least 3 vacancies

This is just a form of a) with the same problem.

Sure.

If you think that it's a ''big'' problem, we can of course just do the election every time.

I think it's as ''big'' of a problem as having a vacant seat is.

Where did the magical 4 months timeframe come from, and what happened to the existing practice of appointing from the previous election's runner ups?

Sorry, "4" is an arbitrary number I picked as an example. Could be any other number.

I'm not a fan of it being time based to be honest, certainly not 4 months. That's a significant portion of an entire release's development window.

I think the existing policy of appointing runner-ups is problematic, especially with small slates -- it can have the anti-democratic effect of putting people who specifically did not get enough community votes into office -- possibly even no votes at all in the (unlikely in reality) situation of a very unpopular candidate.

OK. However, if you're going to stress the democratic angle the only fair solution is a special election every time. I don't think Fedora is a fully democratic project (it's somewhere between democracy and meritocracy).

All things being said, I'd rather just have a FESCo approved appointee put in a vacant seat for the remainder of that seat's term. It solves a lot of problems with the other solutions while still keeping some form of our *cracy balance because FESCo is an elected group of representatives. It's also fairly simple in comparison with all the other options.

Replying to [comment:14 jwboyer]:

Replying to [comment:13 mattdm]:

Well, it rarely comes to that -- highly-divided votes don't happen that often. And usually, votes aren't really between two opposing choices -- they're "do this, or the status quo". So for that, it could just be "5 votes needed to pass a resolution even when the slate isn't full"
Um, if something gets 5 votes it won't be in a tie situation. You're not solving the problem I presented.

Maybe I'm just missing something? Saying "5 votes are required" is just another way of saying "In a 4-4 tie situation, the proposal does not pass." In most FESCo votes, there is a status quo and a proposal, so the tiebreaker is "status quo stays".

The only case where I can see this not working is when something is seriously broken (so status quo is not an option) and there are two possible solutions. In that case, it seems like there is at least a strong incentive to come to a resolution -- and if it's that contentious, I don't see "okay, we need to find a better solution than either of these, or come to a compromise" as a bad outcome.

Can you give me an example of where that wouldn't work?

Majority isn't really magically special in decision making. Other models would be two-thirds or some other supermajority -- sometimes complete consensus, or consensus minus one. Those tend to be slower-moving and conservative, and I think not usually right for a working, technical oversight group like FESCo. On the other hand, or some situations, it is even okay to say that a minority of "yes" votes passes. This is the case in my condo association, for example: in the event that at least one third of owners agree to do some improvement to the common areas but less than two thirds, the improvement can be done but those who vote no can opt out of paying for it. This might be appropriate for stand-alone features, for example -- although I'm not actually proposing it, just giving an example of why I'm not so concerned about this.

I think the existing policy of appointing runner-ups is problematic, especially with small slates -- it can have the anti-democratic effect of putting people who specifically did not get enough community votes into office -- possibly even no votes at all in the (unlikely in reality) situation of a very unpopular candidate.

OK. However, if you're going to stress the democratic angle the only fair solution is a special election every time. I don't think Fedora is a fully democratic project (it's somewhere between democracy and meritocracy).

Right, that's why appointments for the vacant seat are better than using the losing candidates (which is neither democratic nor meritocratic).

Replying to [comment:15 mattdm]:

Replying to [comment:14 jwboyer]:

Replying to [comment:13 mattdm]:

Well, it rarely comes to that -- highly-divided votes don't happen that often. And usually, votes aren't really between two opposing choices -- they're "do this, or the status quo". So for that, it could just be "5 votes needed to pass a resolution even when the slate isn't full"
Um, if something gets 5 votes it won't be in a tie situation. You're not solving the problem I presented.

Maybe I'm just missing something? Saying "5 votes are required" is just another way of saying "In a 4-4 tie situation, the proposal does not pass." In most FESCo votes, there is a status quo and a proposal, so the tiebreaker is "status quo stays".

"5 votes are required" isn't sufficient for a vacant seat but non-tie situation. E.g. you can have +4:-3:0 and now the item doesn't pass because it doesn't have 5 votes even though it has majority.

The only case where I can see this not working is when something is seriously broken (so status quo is not an option) and there are two possible solutions. In that case, it seems like there is at least a strong incentive to come to a resolution -- and if it's that contentious, I don't see "okay, we need to find a better solution than either of these, or come to a compromise" as a bad outcome.

Yeah, I don't disagree that serious cases are where this will come into play. Yet we've had situations like this in previous FESCo votes. They will happen again, and they are exactly the kind of situations where we need clarity and process to help us through them.

Can you give me an example of where that wouldn't work?

See above.

Majority isn't really magically special in decision making. Other models would be two-thirds or some other supermajority -- sometimes complete consensus, or consensus minus one. Those tend to be slower-moving and conservative, and I think not usually right for a working, technical oversight group like FESCo. On the other hand, or some situations, it is even okay to say that a minority of "yes" votes passes. This is the case in my condo association, for example: in the event that at least one third of owners agree to do some improvement to the common areas but less than two thirds, the improvement can be done but those who vote no can opt out of paying for it. This might be appropriate for stand-alone features, for example -- although I'm not actually proposing it, just giving an example of why I'm not so concerned about this.

That's the crux of my concern. You're changing the voting model based on the number of filled seats (and in your last paragraph on a case-by-case basis?!) in a very hand-wavy way. That is confusing. It can lead to situations where nobody really remembers why something passed or didn't, and it introduces unfairness into the process. I'm for a clear and fixed voting model or process, and if we agree "majority" then it should be majority and not "5 votes or whatever".

I don't care if this is "unlikely". It's important. I think we all agree filling the seat is the best solution, so perhaps solving this is as simple as saying "FESCo will not vote on issues until the vacant seat is filled".

I think the existing policy of appointing runner-ups is problematic, especially with small slates -- it can have the anti-democratic effect of putting people who specifically did not get enough community votes into office -- possibly even no votes at all in the (unlikely in reality) situation of a very unpopular candidate.

OK. However, if you're going to stress the democratic angle the only fair solution is a special election every time. I don't think Fedora is a fully democratic project (it's somewhere between democracy and meritocracy).

Right, that's why appointments for the vacant seat are better than using the losing candidates (which is neither democratic nor meritocratic).

Great. Let's do that then.

When discussing elections I often come back to this post by sopwith: https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00772.html In particular, I think his point about not wanting to be a Model UN can be applied to our election policy complexity in general.

With that in mind, I think I've captured some of the suggestions that mattdm and jwb are pushing back and forth into this draft of the election policy:

The last change I made wasn't discussed here but falls out as a possibility from the question of whether FESCo feels the need to be more accountable to the people who are voting for fesco which I think is part of what sgallagh is driving at (and also one of the reasons that pjones was uncomfortable with continuing to serve for the extended F21 cycle). If that's not the direction that FESCo wants to go in, it could be discarded: https://fedoraproject.org/w/index.php?title=User%3AToshio%2FFESCo_Elections_%28draft%29&diff=383079&oldid=383078

There's some other things about quorum mentioned in the last few comments. I think those are good to explore too but probably should be added to the policy that talks about quorum rather than the eleciton policy. I see: "A majority of the committee (that is, 5 of 9) is required to pass a proposal" - https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=FESCo#Agenda but quorum rules might be present somewhere else as well.

Adding meeting keyword.

Replying to [comment:10 mattdm]:

On the issue of avoiding going through the work of an election in situations where there is little gain, here are some possibilities:

'''a)''' If there are fewer than 4 months until until the seat is due to be refilled anyway, leave it open

'''b)''' If there are fewer than 4 months ... only then temporarily appoint someone

'''c)''' If there are fewer than 4 months ... elect for those months + next full term

'''d)''' ''Always'' leave seats open unless there are at least 3 vacancies
\
'''b)''' and '''c)''' seem reasonable to me. They don't suffer the "majority of votes" issue pointed out by jwboyer.

The time frame could be something as short as 1 month in case of '''b)''' (since the election process would take significant portion of the period and the person would be elected only for 2 weeks (?)), but in case of '''c)''' the time frame does not make much sense.

Replying to [comment:17 toshio]:

The last change I made wasn't discussed here but falls out as a possibility from the question of whether FESCo feels the need to be more accountable to the people who are voting for fesco which I think is part of what sgallagh is driving at (and also one of the reasons that pjones was uncomfortable with continuing to serve for the extended F21 cycle).

Basically, what's been bothering me for a while is that we regularly end up with situations where a major shift (such as Fedora.next) occurs in the middle of terms. We then have a set of representatives making major changes to Fedora with what can appear to be little input from the outside community. I've seen the phrase "I wish this had been on the election questionnaire" quite a few times on the list.

I'd like there to be some way for the community to realistically weigh in on major changes that were unpredictable during the elections.

Some other historical examples:
* systemd
* UsrMove
* TmpOnTmpfs
* GNOME 3

Note: I'm not trying to say we made incorrect decisions above, just that there was a significant part of the community that disagreed with FESCo, but had no choice but to go along. It feels very undemocratic. Yes, I am aware of the irony that I am one of the people pushing hard for the Fedora.next initiative. I just want to make sure people agree that it's the right approach. I commented to several people at DevConf that I was betting a lot on my re-election or removal as a sign that the community did or did not want the Fedora.next plan to go through, since I was the most obvious candidate to remove if the tide of public opinion was against it. I'd prefer that we had a more consistent mechanism than "hoping that an election is timed right".

Agreed to defer for a complete proposal to be added to the ticket and discussed there, drop meeting keyword until then (i.e. let’s not keep thinking about this only during the meetings) (+5).

Replying to [comment:21 mitr]:

(i.e. let’s not keep thinking about this only during the meetings)

Well, three months later, that clearly didn't work. I'm not going to add the 'meeting' keyword this week, but perhaps we should bring it up next week if we can't get this conversation going.

I am afraid that the proposal won't materialize before the meeting but I am adding the meeting keyword tentatively.

We will revisit this after F21 is released.

F21 is out. Time to revisit.

Okay, so, we should do this. I guess the first thing to decide on which of these things are important

  • appointed positions to fill in, or not
  • possibility of special elections, or only regular-cycle ones
  • occasional terms which are longer or shorter than normal to realign with the election cycle
  • allow vacant seats, or not

If we can prioritize these, the policy should be clear.

For example, in order of preference, I would like: to avoid special elections, prefer elections to appointments, prefer elected terms never be less than a single release cycle, and don't care if there are vacant seats until the next scheduled election. That suggests a particular policy, but if we decide that vacant seats are a concern, we should do it differently. Or, if we decide that appointments are better than doing a special election, the policy Toshio drafted is basically Good to Go.

I don't like the idea of a seat sitting vacant for too long. For example, if someone is elected and then for some reason is forced to vacate their seat a couple months in, I think that's too long a gap to have the seat unfilled.

Perhaps we can start with: a vacated seat must be filled by some mechanism if there are more than 60 days before the conclusion of the next standard election.

With that in mind, I think we also want to differentiate a short-term fill-in vs. a long-term one. I propose the following:

If the remaining duration of the vacated seat's term is less than a full Fedora release cycle, a replacement should be appointed.

If the remaining duration of the vacated seat's term is more than a full release cycle, then an additional seat (for a shorter term) should be voted upon during the next regular election. In the interim, a replacement should be appointed.

I don't have a good plan for how to handle the appointed seats. Having FESCo self-select its own members has never sat well with me, since human nature generally trends towards selecting people who already agree with you. (And if you have two people on a committee who always agree, one of them is redundant, as the saying goes). Perhaps the Council could weigh in on the matter?

Replying to [comment:27 sgallagh]:

I don't like the idea of a seat sitting vacant for too long. For example, if someone is elected and then for some reason is forced to vacate their seat a couple months in, I think that's too long a gap to have the seat unfilled.

Perhaps we can start with: a vacated seat must be filled by some mechanism if there are more than 60 days before the conclusion of the next standard election.

With that in mind, I think we also want to differentiate a short-term fill-in vs. a long-term one. I propose the following:

If the remaining duration of the vacated seat's term is less than a full Fedora release cycle, a replacement should be appointed.

If the remaining duration of the vacated seat's term is more than a full release cycle, then an additional seat (for a shorter term) should be voted upon during the next regular election. In the interim, a replacement should be appointed.

I'm not quite following what you are wanting here. An additional seat? So we'd appoint someone to fill the vacancy, and then create yet another seat during the election? Confused.

I don't have a good plan for how to handle the appointed seats. Having FESCo self-select its own members has never sat well with me, since human nature generally trends towards selecting people who already agree with you. (And if you have two people on a committee who always agree, one of them is redundant, as the saying goes). Perhaps the Council could weigh in on the matter?

You could do appointment with Council approval if you're that worried about it. I think it would be rare that the Council would override a candidate the majority of FESCo selected though.

Another alternative is to have the Council suggested a replacement, but then you run into the fact that the suggestion is likely to come from the Engineering rep, who is quite possibly a FESCo member. That doesn't really avoid the self-selecting issue you're concerned about. Or you could have the rep abstain from the Council selection, which gets you into having a committee of people that are not necessarily involved in the technical aspects of Fedora suggesting a candidate. Probably not the best solution.

If you really want to get the Council involved you can, but I don't see it as anything other than a rubber stamp in most cases. Sometimes a rubber stamp is worth it though.

Replying to [comment:28 jwboyer]:

Replying to [comment:27 sgallagh]:

If the remaining duration of the vacated seat's term is more than a full release cycle, then an additional seat (for a shorter term) should be voted upon during the next regular election. In the interim, a replacement should be appointed.

I'm not quite following what you are wanting here. An additional seat? So we'd appoint someone to fill the vacancy, and then create yet another seat during the election? Confused.

Normally an election is for either four or five seats (alternating). In the event that someone vacated for more than a single cycle, that would mean that this election would be for either five or six seats, replacing the appointee.

I don't have a good plan for how to handle the appointed seats. Having FESCo self-select its own members has never sat well with me, since human nature generally trends towards selecting people who already agree with you. (And if you have two people on a committee who always agree, one of them is redundant, as the saying goes). Perhaps the Council could weigh in on the matter?

You could do appointment with Council approval if you're that worried about it. I think it would be rare that the Council would override a candidate the majority of FESCo selected though.

Another alternative is to have the Council suggested a replacement, but then you run into the fact that the suggestion is likely to come from the Engineering rep, who is quite possibly a FESCo member. That doesn't really avoid the self-selecting issue you're concerned about. Or you could have the rep abstain from the Council selection, which gets you into having a committee of people that are not necessarily involved in the technical aspects of Fedora suggesting a candidate. Probably not the best solution.

If you really want to get the Council involved you can, but I don't see it as anything other than a rubber stamp in most cases. Sometimes a rubber stamp is worth it though.

Yeah, you're running through basically the same set of problems I came up with, hence "I don't have a good plan". I'm perfectly happy continuing with "FESCo self-selects for non-election filling" until or unless someone comes up with a good alternative. I just wanted to make sure it was noted.

From today’s FESCo meeting: Deferred for another week.

I am going to restate the discussion above while clearing up some ambiguities. Hopefully we can discuss and vote on this proposal at the 2015-05-25 meeting.

== Premise ==
A vacated seat must be filled by some mechanism if there are more than 60 days before the conclusion of the next standard election.

== Mechanism ==
If the remaining duration of the vacated seat's term is less than a full Fedora release cycle, a replacement should be appointed by the remaining members of FESCo by full consensus. If no consensus can be reached by FESCo, the Board will be asked to select from the available candidates through whatever mechanism they see fit.
If the remaining duration of the vacated seat's term is more than a full release cycle, then a candidate will be appointed as for the above case until the next election cycle begins. During this election cycle, the normal election seats will be filled first by the candidates with the most votes. After those seats are filled, and vacated seats will be filled by the candidates with the next-highest number of votes.
* Vacated seats filled outside of the normal two-release cycle will serve for only a single Fedora release cycle so that their seats are back on schedule for the following term.

I don't really have an objection other than the fact that I think I need a flow chart to follow all the rules for bullets 2 and 3. I'm still unclear as to which seats are up for election when, etc. Personally, I'd rather just use bullet 1 in all cases and be done with it.

Also, you need to s/Board/Council.

  • ACTION: sgallagh to update the FESCo wiki with the new policy (sgallagh, 18:47:20)
  • AGREED: New policy for filling vacated FESCo seats is approved (+7, 2, -0) (sgallagh, 18:47:58)

Login to comment on this ticket.

Metadata