During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
* To pass any measure, a majority — defined as the greater of half the eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
* Abstaining from a vote (aka "voting 0") is considered to have removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I'd also like to propose an additional policy modification that occurred to me while writing this message:
* A FESCo member may grant their proxy vote to another member of the Fedora community if they cannot be in attendance for a vote. If they do so, that vote is counted equivalently to any other. Proxy votes MUST be limited to predetermined topics and time period. (e.g. I can say "bookwar has my proxy vote on any topic directly related to ELN" while I am on vacation from MMDD until MMDD, but I cannot give my FESCo seat to a person of my choosing.)
----- Original Message -----
From: "Stephen Gallagher" sgallagh@redhat.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, May 11, 2020 11:52:24 AM Subject: Proposal: Revise FESCo voting policy
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
Obviously FESCo members changing their votes is within their prerogative, but what if nobody wanted to change their votes? I think the original policy is correct: if you don't have a majority explicitly voting yes, you don't have enough support and the resolution shouldn't pass. Abstaining is in two categories:
- I abstain because I don't care about this topic, - I abstain because I object to this line item, but not strongly enough to explicitly vote no, e.g., when the idea is generally correct but I don't explicitly back it or disagree with minor items in it.
I don't think a revision should be made, and counting the latter bucket of votes into the former category isn't correct in the general case.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I'm confused how this holds. There are 9 seats on the council. If one abstains, there's now an effective seat count of 8. Half of 8 is exactly 4, so wouldn't this mean a +4 vote is sufficient? What happens if the vote is (+4, 1, -4)? Shouldn't this fail / end in a tie?
One way to implement your examples is to always add 0.5 before rounding:
9 -> ceil(4.5 + 0.5) -> 5 8 -> ceil(4 + 0.5) -> 5 7 -> ceil(3.5 + 0.5) -> 4 6 -> ceil(3 + 0.5) -> 4 ... 2 -> ceil(1 + 0.5) -> 2 1 -> ceil(0.5 + 0.5) -> 1
I'd also like to propose an additional policy modification that occurred to me while writing this message:
- A FESCo member may grant their proxy vote to another member of the
Fedora community if they cannot be in attendance for a vote. If they do so, that vote is counted equivalently to any other. Proxy votes MUST be limited to predetermined topics and time period. (e.g. I can say "bookwar has my proxy vote on any topic directly related to ELN" while I am on vacation from MMDD until MMDD, but I cannot give my FESCo seat to a person of my choosing.) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, May 11, 2020 at 4:16 PM Alex Scheel ascheel@redhat.com wrote:
.... Abstaining is in two categories:
There is (at least) one additional category, which is that the issue involves various levels of self interest. Technically that is really called a recusal, but the result is the same when it comes time to vote.
On Mon, May 11, 2020 at 05:01:09PM +0000, Gary Buhrmaster wrote:
On Mon, May 11, 2020 at 4:16 PM Alex Scheel ascheel@redhat.com wrote:
.... Abstaining is in two categories:
There is (at least) one additional category, which is that the issue involves various levels of self interest. Technically that is really called a recusal, but the result is the same when it comes time to vote.
Yep. In this particular case, I fell into this category, because I am involved in the implementation of the change and I didn't think it appropriate to vote.
Zbyszek
On Mon, May 11, 2020 at 11:53 AM Stephen Gallagher sgallagh@redhat.com wrote:
Replying out of order because I can :-)
- A FESCo member may grant their proxy vote to another member of the
Fedora community if they cannot be in attendance for a vote. If they do so, that vote is counted equivalently to any other. Proxy votes MUST be limited to predetermined topics and time period. (e.g. I can say "bookwar has my proxy vote on any topic directly related to ELN" while I am on vacation from MMDD until MMDD, but I cannot give my FESCo seat to a person of my choosing.)
I have some Opinions on this proposal, but I suggest that we consider it separately from the remainder of the proposal for the sake of clarity.
On to the main point!
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
So in theory a proposal could pass with a vote of (+1,8,-0). This seems ungreat. If many FESCo members are unwilling to provide an up/down, that indicates a problem with the proposal, IMO. I'd like to see this have a floor (e.g. proposals always require at least +3).
This would also block the one-week approval (+3 and no -1 results in approval currently).
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
Definitely on board with this.
What if we changed it to "a majority of cast votes"? So:
To pass any measure, a majority — defined as the greater of half the votes cast (rounded up) — must vote in favor of the measure.
This keeps the one-week approval. It doesn't fix a (+4,5,-0) situation, but that's a rare case and again suggests the proposal needs improvement.
On Mon, May 11, 2020 at 12:23 pm, Ben Cotton bcotton@redhat.com wrote:
So in theory a proposal could pass with a vote of (+1,8,-0). This seems ungreat. If many FESCo members are unwilling to provide an up/down, that indicates a problem with the proposal, IMO. I'd like to see this have a floor (e.g. proposals always require at least +3).
I don't agree. If there's a problem with the proposal, FESCo members should vote no. Abstain means abstain. If you choose to abstain, that means you don't want your vote counted... there's nothing wrong with that. Not everyone has the opportunity to develop expertise on every issue.
On 11. 05. 20 18:23, Ben Cotton wrote:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
So in theory a proposal could pass with a vote of (+1,8,-0). This seems ungreat. If many FESCo members are unwilling to provide an up/down, that indicates a problem with the proposal, IMO. I'd like to see this have a floor (e.g. proposals always require at least +3).
This would also block the one-week approval (+3 and no -1 results in approval currently).
Also note that in the ticket, (+1,8,-0) would currently pass (in 2 weeks), but not on a meeting, so it's kinda weird to say "this is not yet approved on this meeting, but will be in 2 days in the ticket anyway".
However, (+2,6,-1) would not even pass in the ticket currently and IMHO neither should it in the meeting.
If we are to change the rules, I strongly suggest we keep the "majority of the 9" requirement at least when there is a negative vote involved.
On Mon, May 11, 2020 at 07:13:52PM +0200, Miro Hrončok wrote:
On 11. 05. 20 18:23, Ben Cotton wrote:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
So in theory a proposal could pass with a vote of (+1,8,-0). This seems ungreat. If many FESCo members are unwilling to provide an up/down, that indicates a problem with the proposal, IMO. I'd like to see this have a floor (e.g. proposals always require at least +3).
This would also block the one-week approval (+3 and no -1 results in approval currently).
Also note that in the ticket, (+1,8,-0) would currently pass (in 2 weeks), but not on a meeting, so it's kinda weird to say "this is not yet approved on this meeting, but will be in 2 days in the ticket anyway".
However, (+2,6,-1) would not even pass in the ticket currently and IMHO neither should it in the meeting.
If we are to change the rules, I strongly suggest we keep the "majority of the 9" requirement at least when there is a negative vote involved.
One strong argument for the proposed change is that, currently, an abstention or recusal (TIL that's the proper term) is essentially equivalent to a negative vote. (As long as we require +5 to pass, any vote apart from +1 has the same effect.)
In a hypothetical case where three or four FESCo members were involved in a change and decided to recuse themselves, a proposal gets a very high bar of 5/6 or 5/7 votes. If one or two voting members are absent, the change may not even pass even if *all* non-abstaining members are in favour.
Zbyszek
On 11. 05. 20 19:36, Zbigniew Jędrzejewski-Szmek wrote:
One strong argument for the proposed change is that, currently, an abstention or recusal (TIL that's the proper term) is essentially equivalent to a negative vote. (As long as we require +5 to pass, any vote apart from +1 has the same effect.)
In a hypothetical case where three or four FESCo members were involved in a change and decided to recuse themselves, a proposal gets a very high bar of 5/6 or 5/7 votes. If one or two voting members are absent, the change may not even pass even if*all* non-abstaining members are in favour.
If that is the only problem we are trying to solve here, I think we might very well create a concept of formal recusal and only lower the bar on such occasion.
Hi,
On Mon, May 11, 2020 at 8:06 PM Miro Hrončok mhroncok@redhat.com wrote:
On 11. 05. 20 19:36, Zbigniew Jędrzejewski-Szmek wrote:
One strong argument for the proposed change is that, currently, an abstention or recusal (TIL that's the proper term) is essentially equivalent to a negative vote. (As long as we require +5 to pass, any vote apart from +1 has the same effect.)
In a hypothetical case where three or four FESCo members were involved in a change and decided to recuse themselves, a proposal gets a very high bar of 5/6 or 5/7 votes. If one or two voting members are absent, the change may not even pass even if*all* non-abstaining members are in favour.
If that is the only problem we are trying to solve here, I think we might very well create a concept of formal recusal and only lower the bar on such occasion.
I'd rather ditch the idea of a recusal.
I don't really understand the reason behind it.
You are on FESCo, because community voted for you to bring some expertise. When you participate in the change, you make use of this expertise, and you know what this change is all about, and how community will benefit from it.
So why would we silence you from giving us the vote on the topic, if it is backed by your arguments and knowledge?
And if you go for a _formal_ recuse process, how far we are going to get? Should I stop receiving a post cards from Fedora members(not that I've got any, but still :) ), so that they don't compromise my decisions, when and if these members may create a Change for Fedora?
And what if I _like_ the idea of a Change and become a supporter? If I decide to work on this Change? Does it make me affiliated now? If I express support for it, should it be forbidden for me to vote?
I'd rather not bring these layers of political complexities into FESCo.
I believe we should be driven by the technology aspect, and your knowledge and skills don't change based on who submits a Change, you evaluate the change based on the content of the Change, and you should vote for it.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, May 11, 2020 at 08:25:35PM +0200, Aleksandra Fedorova wrote:
Hi,
On Mon, May 11, 2020 at 8:06 PM Miro Hrončok mhroncok@redhat.com wrote:
On 11. 05. 20 19:36, Zbigniew Jędrzejewski-Szmek wrote:
One strong argument for the proposed change is that, currently, an abstention or recusal (TIL that's the proper term) is essentially equivalent to a negative vote. (As long as we require +5 to pass, any vote apart from +1 has the same effect.)
In a hypothetical case where three or four FESCo members were involved in a change and decided to recuse themselves, a proposal gets a very high bar of 5/6 or 5/7 votes. If one or two voting members are absent, the change may not even pass even if*all* non-abstaining members are in favour.
If that is the only problem we are trying to solve here, I think we might very well create a concept of formal recusal and only lower the bar on such occasion.
I'd rather ditch the idea of a recusal.
I don't really understand the reason behind it.
You are on FESCo, because community voted for you to bring some expertise. When you participate in the change, you make use of this expertise, and you know what this change is all about, and how community will benefit from it.
So why would we silence you from giving us the vote on the topic, if it is backed by your arguments and knowledge?
Oh, it's not about knowledge at all in this case, but about bias and objectivity. Obviously, people who design some change can never be fully neutral. Additionally, if we assume that FESCo members vote for their changes, those changes would effectively have a lower bar than other changes, since a +1 (or more if more members are involved) would always be guaranteed. I don't like this appearance of unfairness.
And if you go for a _formal_ recuse process, how far we are going to get? Should I stop receiving a post cards from Fedora members(not that I've got any, but still :) ), so that they don't compromise my decisions, when and if these members may create a Change for Fedora?
I think rules should be appropriate for the problem at hand. This is a community distro, not a government procurement process, so a few lightweight rules are IMHO enough.
And what if I _like_ the idea of a Change and become a supporter? If I decide to work on this Change? Does it make me affiliated now? If I express support for it, should it be forbidden for me to vote?
That's why I don't think a *formal* recusal process is appropriate. To answer your particular question: if you say "+1, this looks great, I'll also participate in the implementation", a recusal would not be appropriate at all.
I'd rather not bring these layers of political complexities into FESCo.
I believe we should be driven by the technology aspect, and your knowledge and skills don't change based on who submits a Change, you evaluate the change based on the content of the Change, and you should vote for it.
Zbyszek
On Mon, May 11, 2020 at 12:49 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Oh, it's not about knowledge at all in this case, but about bias and objectivity. Obviously, people who design some change can never be fully neutral. Additionally, if we assume that FESCo members vote for their changes, those changes would effectively have a lower bar than other changes, since a +1 (or more if more members are involved) would always be guaranteed. I don't like this appearance of unfairness.
In ethics, these are sometimes difficult and nuanced. But I don't think this is such a situation.
Bias is not the same thing as a conflict of interest. And it doesn't inherently result in unfairness. Does the approval or rejection of a feature result in a personal benefit to a voting member? What is a personal benefit? Learning some new skill might seem to be a personal benefit, but that's something that could apply to anyone in a similar position, and thus not a conflict of interest. A personal benefit that is a conflict of interest might be a promotion or increase in salary, as a result of additional work (which could happen either by feature approval or rejection depending on the nature of the conflict).
More subtle conflicts arise if any voting member does performance evaluation of someone submitting a feature.
Bias that's either obvious or clearly stated is not likely to be a conflict of interest. The more obvious the bias, the more straightforward the challenge can be, if one exists. And objective and professional application of expertise is a good basis for bias, and is not a compelling reason for recusal.
In the case of a true conflict of interest, it is a recusal that is more likely called for, not merely abstaining on the vote. A real conflict of interest means even persuading others can itself produce the personal benefit, even if that person abstains from the vote.
I think the abstained vote case is generally about a lack of subject matter interest or expertise. Something about the presentation of the feature is insufficiently compelling or convincing, but not disqualifying. If the feature seems like a good idea, but could be specious, then the proper thing to do is vote against it on the basis that liabilities haven't been satisfactorily explored. Or similar specific critique.
On Mon, May 11, 2020 at 7:40 PM Chris Murphy lists@colorremedies.com wrote:
Bias is not the same thing as a conflict of interest. And it doesn't inherently result in unfairness.
Sometimes it is a matter avoiding even the appearance of impropriety that could be raised at a later date to question the process/motives/decisions (which often just delays the inevitable, but sometimes the delay is the point).
Regardless, I would suggest that along the way, if FESCo does not have a set of guidelines regarding if recusal on any vote is appropriate, they should consider writing down whatever they decide is appropriate (or just point to some other groups process if that is appropriate), even if the decision is no recusal is ever required, so we don't have this discussion all over again in a year or two when everyone has forgotten this one.
On Mon, May 11, 2020 at 2:21 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Mon, May 11, 2020 at 7:40 PM Chris Murphy lists@colorremedies.com wrote:
Bias is not the same thing as a conflict of interest. And it doesn't inherently result in unfairness.
Sometimes it is a matter avoiding even the appearance of impropriety that could be raised at a later date to question the process/motives/decisions (which often just delays the inevitable, but sometimes the delay is the point).
Of course voting members need to trust their instincts. I only mean to indicate bias is not the same thing as a conflict of interest; and also further that a very strong preference that's predicated on evidence and experience isn't even bias, certainly not in the prejudiced sense. Anyone who thinks their objectivity is compromised on some topic should recuse; and anyone who knows another's objectivity is compromised should feel comfortable to point this out and ask for recusal.
Regardless, I would suggest that along the way, if FESCo does not have a set of guidelines regarding if recusal on any vote is appropriate, they should consider writing down whatever they decide is appropriate (or just point to some other groups process if that is appropriate), even if the decision is no recusal is ever required, so we don't have this discussion all over again in a year or two when everyone has forgotten this one.
It's reasonable to have clarity on the issue. I'm not an ombudsman or ethicist, but there is such a person or group within Red Hat who could answer this question. It might even be as straightforward as each voting member filling out a questionnaire so that their possible conflicts are known, and they can steer clear of such areas. But I think Fedora has quite a lot of compartmentalization in the organizational structure that just inherently avoids the problem.
Anyway I came across this which is informative, even though it applies mainly to charities (Fedora is a non-profit so it's approximate). https://charitylawyerblog.com/2014/02/10/managing-conflicts-of-interest/
On Mon, May 11, 2020 at 11:22 PM Chris Murphy lists@colorremedies.com wrote:
On Mon, May 11, 2020 at 2:21 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Mon, May 11, 2020 at 7:40 PM Chris Murphy lists@colorremedies.com wrote:
Bias is not the same thing as a conflict of interest. And it doesn't inherently result in unfairness.
Sometimes it is a matter avoiding even the appearance of impropriety that could be raised at a later date to question the process/motives/decisions (which often just delays the inevitable, but sometimes the delay is the point).
Of course voting members need to trust their instincts. I only mean to indicate bias is not the same thing as a conflict of interest; and also further that a very strong preference that's predicated on evidence and experience isn't even bias, certainly not in the prejudiced sense. Anyone who thinks their objectivity is compromised on some topic should recuse; and anyone who knows another's objectivity is compromised should feel comfortable to point this out and ask for recusal.
Regardless, I would suggest that along the way, if FESCo does not have a set of guidelines regarding if recusal on any vote is appropriate, they should consider writing down whatever they decide is appropriate (or just point to some other groups process if that is appropriate), even if the decision is no recusal is ever required, so we don't have this discussion all over again in a year or two when everyone has forgotten this one.
It's reasonable to have clarity on the issue. I'm not an ombudsman or ethicist, but there is such a person or group within Red Hat who could answer this question. It might even be as straightforward as each voting member filling out a questionnaire so that their possible conflicts are known, and they can steer clear of such areas. But I think Fedora has quite a lot of compartmentalization in the organizational structure that just inherently avoids the problem.
Anyway I came across this which is informative, even though it applies mainly to charities (Fedora is a non-profit so it's approximate). https://charitylawyerblog.com/2014/02/10/managing-conflicts-of-interest/
Sorry but this is exactly the conversation I didn't want to have.
The methods described there are needed when you don't have other ways to resolve the described issues. And these methods are ugly. Yes, in case you have such a problem, there are no good ways out, so you have to do something.
Fortunately, we just don't have this problem.
We are Open Source community based on knowledge, skill and trust. Yes, some of us found ways to get paid for the work we love to do anyways, some of us spend free time on it, many do both. And it doesn't really matter, because we can evaluate our decisions and argue about them.
And if I support a change, i support a change. You can scratch my name from it and put anyone else's. If it has the same content, I am still going to support it. You can write your own change, but if you convince me, it becomes _my_ Change, Change in my Fedora, which I am going to defend for FESCo, or for Fedora community, or as a Fedora Ambassador for the outside world.
So I don't want us to _solve_ conflicts of interest, I think that we don't really have them.
And we shouldn't _bring_ them artificially either.
-- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, May 11, 2020 at 05:36:06PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
One strong argument for the proposed change is that, currently, an abstention or recusal (TIL that's the proper term) is essentially equivalent to a negative vote. (As long as we require +5 to pass, any vote apart from +1 has the same effect.)
In a hypothetical case where three or four FESCo members were involved in a change and decided to recuse themselves, a proposal gets a very high bar of 5/6 or 5/7 votes. If one or two voting members are absent, the change may not even pass even if *all* non-abstaining members are in favour.
Especially in the case of recusal it should be a higher bar, to keep the assessment on the same level.
If a non FESCo member proposes a solution, this person needs to convince 5 people, that their solution is good.
If a FESCo member proposes a solution, this person would only need to convince 4 people (or less, depending on the final rule), that their solution is good.
A positive voting result should always be a statement, that at least 5 people in FESCo can approve the thing in question, to the best of their knowledge. In the case that a FESCo member assumes a conflict of interest for her/him this should just lead to a self-removal from the process (either by voting no, which seems weird, or by abstaining, which counts as no, but doesn't seem weird) The result should be the same, that 5 FESCo members (optimally with a minimum amount of conflict of interest) can confirm that the thing in question should happen.
Removing people not attending the vote from the quorum can be discussed, but if a lot of people either don't care about the question or explicitely don't vote for some reason, this is probably also not a vote that should go through.
All the best, David
David Kaufmann wrote:
Especially in the case of recusal it should be a higher bar, to keep the assessment on the same level.
[…]
Removing people not attending the vote from the quorum can be discussed, but if a lot of people either don't care about the question or explicitely don't vote for some reason, this is probably also not a vote that should go through.
The rules you propose there lead to the ridiculous effect that people who want to astain will instead actually leave the meeting so that their vote is truly excluded rather than counted against the majority. This is exactly what regularly happens in the Italian Senate, which uses these rules.
The whole definition of an abstention or recusal is "my vote should not matter". If we do not want to allow this kind of abstentions, then we need to not allow abstentions at all and require people to vote -1 instead. Recording a 0 and actually treating it exactly like a -1 does not make sense.
Kevin Kofler
On Wed, May 13, 2020 at 12:44:44PM +0200, Kevin Kofler wrote:
The rules you propose there lead to the ridiculous effect that people who want to astain will instead actually leave the meeting […]
Yes, true, that could happen. Thats a good thought.
The whole definition of an abstention or recusal is "my vote should not matter". If we do not want to allow this kind of abstentions, then we need to not allow abstentions at all and require people to vote -1 instead. Recording a 0 and actually treating it exactly like a -1 does not make sense.
Having abstentions can still be used for signalling that in future the change could be ok - if it is interpreted as: 0 = Currently I can't say, that this should go through for $reason, -1 = This should not go through, and this will not change)
If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself.
I think finally it boils down to the question, if it should be a bar that should be reached / "at least x people are in favor" or if it should be a majority vote / "more people in favor than against"
All the best, David
David Kaufmann wrote:
If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself.
It would actually give them only half a vote. Whether a single half vote amounts to a whole vote depends on how ties are handled.
Kevin Kofler
On Wed, 13 May 2020 at 09:17, Kevin Kofler kevin.kofler@chello.at wrote:
David Kaufmann wrote:
If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself.
It would actually give them only half a vote. Whether a single half vote amounts to a whole vote depends on how ties are handled.
How about making this simpler: plurality wins
If the plurality is +1, then it passes If the plurality is +0, then it goes to more discussion (or drop because people are tired). If the plurality is -1 then it fails If there is a tie, it goes to more discussion.
So a 4 +1, 5 0, 0 -1 means more discussion.
Yes there will be corner cases, and ways to rig things.. there is no system which is going to beat Arrow's theorem. We either deal with it at the time or give up now because there is no perfect solution and no group of people are going to agree that there is a good solution either.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2020-05-13 at 09:27 -0400, Stephen John Smoogen wrote:
On Wed, 13 May 2020 at 09:17, Kevin Kofler kevin.kofler@chello.at wrote:
David Kaufmann wrote:
If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself.
It would actually give them only half a vote. Whether a single half vote amounts to a whole vote depends on how ties are handled.
How about making this simpler: plurality wins
If the plurality is +1, then it passes If the plurality is +0, then it goes to more discussion (or drop because people are tired). If the plurality is -1 then it fails If there is a tie, it goes to more discussion.
So a 4 +1, 5 0, 0 -1 means more discussion.
Yes there will be corner cases, and ways to rig things.. there is no system which is going to beat Arrow's theorem. We either deal with it at the time or give up now because there is no perfect solution and no group of people are going to agree that there is a good solution either.
This will not happen because the policy says that if at least 3 people gave +1 and nobody gave -1, after 1 week it is approved exactly so that tickets are not being held in endless loops of discussions.
So how is it different if it gets approved on a meeting with +4,±5,-0 or just waited for another few days and get auto-approved? This is the issue Stephen is proposing to solve.
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Wed, 13 May 2020 at 10:34, Igor Raits ignatenkobrain@fedoraproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2020-05-13 at 09:27 -0400, Stephen John Smoogen wrote:
On Wed, 13 May 2020 at 09:17, Kevin Kofler kevin.kofler@chello.at wrote:
David Kaufmann wrote:
If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself.
It would actually give them only half a vote. Whether a single half vote amounts to a whole vote depends on how ties are handled.
How about making this simpler: plurality wins
If the plurality is +1, then it passes If the plurality is +0, then it goes to more discussion (or drop because people are tired). If the plurality is -1 then it fails If there is a tie, it goes to more discussion.
So a 4 +1, 5 0, 0 -1 means more discussion.
Yes there will be corner cases, and ways to rig things.. there is no system which is going to beat Arrow's theorem. We either deal with it at the time or give up now because there is no perfect solution and no group of people are going to agree that there is a good solution either.
This will not happen because the policy says that if at least 3 people gave +1 and nobody gave -1, after 1 week it is approved exactly so that tickets are not being held in endless loops of discussions.
So how is it different if it gets approved on a meeting with +4,±5,-0 or just waited for another few days and get auto-approved? This is the issue Stephen is proposing to solve.
It gives a couple of days for people to either change their minds to -1 or to try to convince people to +1 more. At this point, if you want to have more discussion but aren't against it, you have to vote -1 just to force it for more discussion which leads people to having ill feelings from previous times where this has happened.
On Wed, May 13, 2020 at 5:18 AM David Kaufmann astra@ionic.at wrote:
On Wed, May 13, 2020 at 12:44:44PM +0200, Kevin Kofler wrote:
The rules you propose there lead to the ridiculous effect that people who want to astain will instead actually leave the meeting […]
Yes, true, that could happen. Thats a good thought.
An abstain is a non-vote. But that voting member is still present for purposes of quorum. If people leaving the meeting results in lack of quorum, then the meeting should be adjourned.
If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself.
Since abstain is a non-vote, it has the effect of being a vote cast for the prevailing side.
Rules of order are there to protect the minority. In a +1,8,0 case, there's no minority to protect. Right? A single person can just say "hey I think we should have a minimum number of votes for this issue" and then discuss that first. Rules questions are higher ranking than ordinary issues, so any time someone raises questions about procedure, you pretty much have to take them up because the idea is that everyone wants to follow the rules.
Also, +1 votes can be interpreted as either "in favor of" or "consent". Any idea that +1's translate into "I agree 100%" is misplaced. It's legitimate to +1 something when you have uncertainty, but trust in the due diligence of the people and work.
And as for feature owners who are FESCo members, there's no inherent conflict of interest. However, if that member just doesn't like the look of voting on their own proposal, it's reasonable to abstain from the start. This avoids the possibly awkward scenario of voting last, and breaking a tie vote.
I think finally it boils down to the question, if it should be a bar that should be reached / "at least x people are in favor" or if it should be a majority vote / "more people in favor than against"
Correct. And that question, once raised, is a higher order question than the feature proposal because it is a rules question. It's not necessary to make it a permanent rule, or alter the existing process. And it's up to the deliberative body to decide.
And as sgallagh stated at the outset, this hasn't happened before. It's a rare case. And it was handled properly.
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help. Better summary, more arguments, etc..
This would encourage people who are against the change to participate. And if there are no such people to provide convincing arguments against the change in a reasonable time frame, than FESCo decides in favor of the submitter.
I'd also like to propose an additional policy modification that occurred to me while writing this message:
- A FESCo member may grant their proxy vote to another member of the
Fedora community if they cannot be in attendance for a vote. If they do so, that vote is counted equivalently to any other. Proxy votes MUST be limited to predetermined topics and time period. (e.g. I can say "bookwar has my proxy vote on any topic directly related to ELN" while I am on vacation from MMDD until MMDD, but I cannot give my FESCo seat to a person of my choosing.)
I think this might be ok-ish in the example of ELN conversations as we both are owners of the change and work on it. But in a slightly different situation, on a generic topic, I would prefer if people announce their vacation, and then FESCo will wait for a vote from the person if it can change the outcome.
If someone goes on PTO for more than three weeks, that's a different story, but your approach won't work in this case either, as you won't be able to learn in advance which exact topics you need to delegate.
So -1 here as well.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help. Better summary, more arguments, etc..
This would encourage people who are against the change to participate.
I agree with Aleksandra up until here.
And if there are no such people to provide convincing arguments against the change in a reasonable time frame, than FESCo decides in favor of the submitter.
I disagree here. If such proposal does not have enough support, then it should not be accepted and should be revisited/abandoned/rejected. I cannot imagine any even hypothetical situation where the opposite was beneficial.
Vít
Dne 12. 05. 20 v 10:18 Vít Ondruch napsal(a):
Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help.
Actually, it should be also useful if position of each abstaining FESCo member was explained. Because for myself, I can interpret 5 people abstaining just as a lack of understanding of the issue and nothing else.
Vít
Better summary, more arguments, etc..
This would encourage people who are against the change to participate.
I agree with Aleksandra up until here.
And if there are no such people to provide convincing arguments against the change in a reasonable time frame, than FESCo decides in favor of the submitter.
I disagree here. If such proposal does not have enough support, then it should not be accepted and should be revisited/abandoned/rejected. I cannot imagine any even hypothetical situation where the opposite was beneficial.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, May 12, 2020 at 10:27:26AM +0200, Vít Ondruch wrote:
Dne 12. 05. 20 v 10:18 Vít Ondruch napsal(a):
Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Yes.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help.
Actually, it should be also useful if position of each abstaining FESCo member was explained. Because for myself, I can interpret 5 people abstaining just as a lack of understanding of the issue and nothing else.
+1
Zbyszek
On 12. 05. 20 10:27, Vít Ondruch wrote:
Actually, it should be also useful if position of each abstaining FESCo member was explained. Because for myself, I can interpret 5 people abstaining just as a lack of understanding of the issue and nothing else.
For me, it was that. I wasn't able to grasp the change proposal quickly, would need to dedicate more time to it and I prioritized other things, abstaining as in: "I trust other members understand this issue better than me and they will decide the good way."
However, it turned out that there was simply too many of 0 votes, hence I bit the bullet and decided to vote in favor, trusting the change owners they know what they are doing.
Miro Hrončok wrote:
For me, it was that. I wasn't able to grasp the change proposal quickly, would need to dedicate more time to it and I prioritized other things, abstaining as in: "I trust other members understand this issue better than me and they will decide the good way."
However, it turned out that there was simply too many of 0 votes, hence I bit the bullet and decided to vote in favor, trusting the change owners they know what they are doing.
IMHO, if you don't understand the change proposal, you should vote -1, not 0 and most definitely not +1.
It is part of the rules for changes that they need to be clearly and completely documented.
Kevin Kofler
Hi,
On Tue, May 12, 2020 at 10:19 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help. Better summary, more arguments, etc..
This would encourage people who are against the change to participate.
I agree with Aleksandra up until here.
And if there are no such people to provide convincing arguments against the change in a reasonable time frame, than FESCo decides in favor of the submitter.
I disagree here. If such proposal does not have enough support, then it should not be accepted and should be revisited/abandoned/rejected. I cannot imagine any even hypothetical situation where the opposite was beneficial.
The proposal has at least support of its owners, who stepped in and spent some time describing the idea.
If there are no convincing reasons against this proposal, then it is their opinion, which matters. They have an idea, and they are willing to do the job and take the responsibility. I don't see the reason to block it then.
Given that "change is out of scope of Fedora" and "support is very limited and the risk is too high" still can be a convincing reason to reject the change in some cases. But then it must be stated explicitly.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Aleksandra Fedorova wrote:
The proposal has at least support of its owners, who stepped in and spent some time describing the idea.
If there are no convincing reasons against this proposal, then it is their opinion, which matters. They have an idea, and they are willing to do the job and take the responsibility. I don't see the reason to block it then.
The problem is that "convincing" is very subjective and arguable.
I have several reasons against ELN, which I have already stated for past versions of your proposal (Should I really have repeated those at every single revised version that you came up with to bypass the repeated rejection?): * Having a buildroot that drops support for some subarchitectures is a step towards dropping those subarchitectures for everyone, which is exactly what we do not want. There is absolutely no reason to test dropping subarchitectures anywhere if we are not going to deploy it ever. * Having a buildroot called "EL Next" means that Fedora gets in the business of composing the development version of RHEL in addition to the development version of Fedora. I do not see how this is the job of Fedora and Fedora maintainers. RHEL should be developed on RHEL infrastructure, by RHEL maintainers only.
But apparently you do not consider those "convincing".
I also think that there needs to be a limit to how many times a rejected change gets resubmitted. It is just not acceptable to retry and retry until the vote ends up the way you want it to.
Kevin Kofler
On Wed, May 13, 2020 at 6:56 AM Kevin Kofler kevin.kofler@chello.at wrote:
I have several reasons against ELN, which I have already stated for past versions of your proposal (Should I really have repeated those at every single revised version that you came up with to bypass the repeated rejection?):
- Having a buildroot that drops support for some subarchitectures is a step towards dropping those subarchitectures for everyone, which is exactly what we do not want. There is absolutely no reason to test dropping subarchitectures anywhere if we are not going to deploy it ever.
FWIW, we do not currently have that in place (and may never). That said, I disagree with your ex post facto statement that we would never drop any subarchitectures. We certainly wouldn't drop them without sufficient information to justify it, which is why we would need a place to learn that information.
That said, the AVX2 proposal is currently on hold and is (IMHO) unlikely to be implemented for RHEL 9.
- Having a buildroot called "EL Next" means that Fedora gets in the business of composing the development version of RHEL in addition to the development version of Fedora. I do not see how this is the job of Fedora and Fedora maintainers. RHEL should be developed on RHEL infrastructure, by RHEL maintainers only.
That sounds like the exact opposite of open source, to me. The entire point of this exercise is to do *less* work out of the public eye. The set of people who would be doing this work behind the firewall are now going to be instructed to work in Rawhide (and, by extension, ELN) to prepare for future versions of RHEL. This will also give the community at large more opportunity to influence the eventual RHEL 9 (and onwards) content and design.
So, new issues that are discovered while building for a RHEL prototype will be far more visible and can be addressed earlier, either by the community maintainer or the RHEL maintainer working in the Fedora environment.
But apparently you do not consider those "convincing".
It is less that I don't find them convincing; I find them to be the product of insufficient explanation on my part that has led to incorrect assumptions. I'd appreciate it if you would be so kind as to default to assuming we're all on the same side (the success of Fedora and Open Source in general) and request clarification rather than assuming malicious intent.
I also think that there needs to be a limit to how many times a rejected change gets resubmitted. It is just not acceptable to retry and retry until the vote ends up the way you want it to.
I disagree with this, mainly because FESCo rarely rejects a Change *outright*. It's usually rejected for specific reasons. (E.g. it doesn't have a contingency plan or the proposed design would cause harm/regressions to a large subset of the Fedora community that outweighs the benefit). Any such Changes are welcome to be resubmitted as many times as necessary *provided that they have materially changed the sections resulting in the earlier rejection*.
On Wed, May 13, 2020 at 08:01:29AM -0400, Stephen Gallagher wrote:
- Having a buildroot called "EL Next" means that Fedora gets in the business of composing the development version of RHEL in addition to the development version of Fedora. I do not see how this is the job of Fedora and Fedora maintainers. RHEL should be developed on RHEL infrastructure, by RHEL maintainers only.
That sounds like the exact opposite of open source, to me. The entire point of this exercise is to do *less* work out of the public eye. The set of people who would be doing this work behind the firewall are now going to be instructed to work in Rawhide (and, by extension, ELN) to prepare for future versions of RHEL. This will also give the community at large more opportunity to influence the eventual RHEL 9 (and onwards) content and design.
So, new issues that are discovered while building for a RHEL prototype will be far more visible and can be addressed earlier, either by the community maintainer or the RHEL maintainer working in the Fedora environment.
Yes. As long as ELN doesn't disrupt normal Fedora packaging (which is what the discussion after the change was proposed was to a large extent was about, and which I think we have safeguarded properly in the latest iterations), having another downstream is great for Fedora. Every time some group of people decides to build another downstream from Fedora, we should welcome that. The point of Fedora is not just Fedora, but allowing people to build their own solutions. Also, "with enough eyes, all bugs are shallow".
I also think that there needs to be a limit to how many times a rejected change gets resubmitted. It is just not acceptable to retry and retry until the vote ends up the way you want it to.
I disagree with this, mainly because FESCo rarely rejects a Change *outright*. It's usually rejected for specific reasons. (E.g. it doesn't have a contingency plan or the proposed design would cause harm/regressions to a large subset of the Fedora community that outweighs the benefit). Any such Changes are welcome to be resubmitted as many times as necessary *provided that they have materially changed the sections resulting in the earlier rejection*.
I disagree too. This isn't particularly relevant to this case (since this particular Change was proposed once, discussed once albeit quite verbosely, and voted once). But even if somebody did resubmit the same proposal a few times, voting -1 is always a very easy thing.
Zbyszek
On Wednesday, May 13, 2020 5:01:29 AM MST Stephen Gallagher wrote:
- Having a buildroot called "EL Next" means that Fedora gets in the
business
of composing the development version of RHEL in addition to the development version of Fedora. I do not see how this is the job of Fedora and Fedora maintainers. RHEL should be developed on RHEL infrastructure, by RHEL maintainers only.
That sounds like the exact opposite of open source, to me. The entire point of this exercise is to do *less* work out of the public eye. The set of people who would be doing this work behind the firewall are now going to be instructed to work in Rawhide (and, by extension, ELN) to prepare for future versions of RHEL. This will also give the community at large more opportunity to influence the eventual RHEL 9 (and onwards) content and design.
So, new issues that are discovered while building for a RHEL prototype will be far more visible and can be addressed earlier, either by the community maintainer or the RHEL maintainer working in the Fedora environment.
So, effectively, this is just Red Hat/IBM looking for free labor from Fedora developers? That's how this comes across, at least with that wording. If it's just a matter of allowing development to happen in public, Red Hat/IBM could simply make their repository available publicly.
On Wed, May 13, 2020 at 8:04 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, May 13, 2020 at 6:56 AM Kevin Kofler kevin.kofler@chello.at wrote:
I have several reasons against ELN, which I have already stated for past versions of your proposal (Should I really have repeated those at every single revised version that you came up with to bypass the repeated rejection?):
- Having a buildroot that drops support for some subarchitectures is a step towards dropping those subarchitectures for everyone, which is exactly what we do not want. There is absolutely no reason to test dropping subarchitectures anywhere if we are not going to deploy it ever.
FWIW, we do not currently have that in place (and may never). That said, I disagree with your ex post facto statement that we would never drop any subarchitectures. We certainly wouldn't drop them without sufficient information to justify it, which is why we would need a place to learn that information.
That said, the AVX2 proposal is currently on hold and is (IMHO) unlikely to be implemented for RHEL 9.
- Having a buildroot called "EL Next" means that Fedora gets in the business of composing the development version of RHEL in addition to the development version of Fedora. I do not see how this is the job of Fedora and Fedora maintainers. RHEL should be developed on RHEL infrastructure, by RHEL maintainers only.
That sounds like the exact opposite of open source, to me. The entire point of this exercise is to do *less* work out of the public eye. The set of people who would be doing this work behind the firewall are now going to be instructed to work in Rawhide (and, by extension, ELN) to prepare for future versions of RHEL. This will also give the community at large more opportunity to influence the eventual RHEL 9 (and onwards) content and design.
So, new issues that are discovered while building for a RHEL prototype will be far more visible and can be addressed earlier, either by the community maintainer or the RHEL maintainer working in the Fedora environment.
I want to preface this first with the statement that I think having ELN is a good thing in general. I would actually really like to see RHEL development just be an aspect of Fedora, and I would *love* for other Fedora downstreams to do the same within Fedora. Excluding commercial downstream users of Fedora (which isn't just Red Hat!) is a great way to completely destroy our community. I'd love to see Amazon Linux development in Fedora, for example. And non-commercial side-stream/down-stream consumers and contributors like Mageia, OpenMandriva, etc. I would love to see folks from SUSE involved in Fedora too, just as I would love to see Fedorans involved in openSUSE. I want all of us in the RPM Linux distribution ecosystem working together more to solve problems better!
But I think a huge part of the reaction about ELN comes back to this perception by folks that Fedora is not useful on its own and only exists as an alpha/beta test bed for RHEL. In recent years, it has increasingly appeared like this was true (wrt modularity, ARK, and recent CPE stuff). It's *generally* not, but there are definitely some folks I've met within Red Hat who *do* consider it that way, even though it's absolutely wrong. I've even heard grumbles from folks who wished it Fedora worked like CentOS (which is only a user community and not a developer+user community).
And it doesn't help that Fedora is technically the outlier among Red Hat projects: no other Red Hat project has a governance model like Fedora's. No other Red Hat project has formal structures to allow the community to have as strong of a voice as it does. A lot of Red Hat projects are in fact set up the *opposite* way: there is no way for the community to have a strong influence without getting a Red Hat employee to be on their side. It's quite interesting, because if you look at projects like Kubernetes that are very successful, they are structured very similarly to how Fedora is. Many of the concepts and governance structures are extremely similar to how the Fedora Project works. The difference between Fedora and Kubernetes is that Fedora doesn't have people paid to advocate for the community and encourage folks to participate in it.
When *I* look at Fedora, I see something special: a community with massively unrealized potential. We're a huge passionate group of folks that try to work diligently and amicably with the communities that make the projects that the Fedora Linux distribution ships. We are also often the drivers of innovation. In many cases, this is obvious (UsrMerge, systemd, PipeWire, Wayland, EarlyOOM, etc.). In some cases, it's not (Koji, fedmsg, HyperKitty, Pagure, Dist-Git, Ansible, AppStream, RPM-OSTree, etc.). And a great deal of this is driven by people in the community who *aren't* from Red Hat!
But a lot of people don't see it this way, and many of us bristle when they bring up the RHEL point. Just look at Phoronix, Reddit, or any other place, and you'll see the comments about people being "free labor" or "free QA" for Red Hat. This is an unfair characterization that speaks to a deep misunderstanding of how this relationship is supposed to work. And it goes both ways: both Fedorans and Red Hatters misunderstand this and mischaracterize it in ways that are counterproductive.
So I guess, in the end, what I want to see is RHEL becoming more like Fedora: more participatory and better able to respond to the needs of the community as well as Red Hat's customers. To me, I think ELN, when done right, can do just that.
-- 真実はいつも一つ!/ Always, there's only one truth!
Hi, Neal,
On Wed, May 13, 2020 at 9:24 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, May 13, 2020 at 8:04 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, May 13, 2020 at 6:56 AM Kevin Kofler kevin.kofler@chello.at wrote:
I have several reasons against ELN, which I have already stated for past versions of your proposal (Should I really have repeated those at every single revised version that you came up with to bypass the repeated rejection?):
- Having a buildroot that drops support for some subarchitectures is a step towards dropping those subarchitectures for everyone, which is exactly what we do not want. There is absolutely no reason to test dropping subarchitectures anywhere if we are not going to deploy it ever.
FWIW, we do not currently have that in place (and may never). That said, I disagree with your ex post facto statement that we would never drop any subarchitectures. We certainly wouldn't drop them without sufficient information to justify it, which is why we would need a place to learn that information.
That said, the AVX2 proposal is currently on hold and is (IMHO) unlikely to be implemented for RHEL 9.
- Having a buildroot called "EL Next" means that Fedora gets in the business of composing the development version of RHEL in addition to the development version of Fedora. I do not see how this is the job of Fedora and Fedora maintainers. RHEL should be developed on RHEL infrastructure, by RHEL maintainers only.
That sounds like the exact opposite of open source, to me. The entire point of this exercise is to do *less* work out of the public eye. The set of people who would be doing this work behind the firewall are now going to be instructed to work in Rawhide (and, by extension, ELN) to prepare for future versions of RHEL. This will also give the community at large more opportunity to influence the eventual RHEL 9 (and onwards) content and design.
So, new issues that are discovered while building for a RHEL prototype will be far more visible and can be addressed earlier, either by the community maintainer or the RHEL maintainer working in the Fedora environment.
I want to preface this first with the statement that I think having ELN is a good thing in general. I would actually really like to see RHEL development just be an aspect of Fedora, and I would *love* for other Fedora downstreams to do the same within Fedora. Excluding commercial downstream users of Fedora (which isn't just Red Hat!) is a great way to completely destroy our community. I'd love to see Amazon Linux development in Fedora, for example. And non-commercial side-stream/down-stream consumers and contributors like Mageia, OpenMandriva, etc. I would love to see folks from SUSE involved in Fedora too, just as I would love to see Fedorans involved in openSUSE. I want all of us in the RPM Linux distribution ecosystem working together more to solve problems better!
Huge +1 here!
But I think a huge part of the reaction about ELN comes back to this perception by folks that Fedora is not useful on its own and only exists as an alpha/beta test bed for RHEL. In recent years, it has increasingly appeared like this was true (wrt modularity, ARK, and recent CPE stuff). It's *generally* not, but there are definitely some folks I've met within Red Hat who *do* consider it that way, even though it's absolutely wrong. I've even heard grumbles from folks who wished it Fedora worked like CentOS (which is only a user community and not a developer+user community).
While I can recognize some of those notes, I think you are unnecessarily amplifying them.
Note that Red Hat is not a hive mind. It is a big company, which is also full of grumpy engineers and similarly grumpy managers. And if you catch me in a wrong mood, I can go rant on how I wish I could just tell people to do the right thing, and not spend hours on explaining why exactly it is right to them.
I don't have such power, and I will never _really_ wish for that kind of power, but, you know, everyone has its moments. It doesn't make me disrespectful to the Open Source community. And it literally has nothing to do with Red Hat and Fedora.
Full disclosure: there is no such power for me or anyone else inside Red Hat either, and I am kind of proud of it.
And it doesn't help that Fedora is technically the outlier among Red Hat projects: no other Red Hat project has a governance model like Fedora's. No other Red Hat project has formal structures to allow the community to have as strong of a voice as it does. A lot of Red Hat projects are in fact set up the *opposite* way: there is no way for the community to have a strong influence without getting a Red Hat employee to be on their side. It's quite interesting, because if you look at projects like Kubernetes that are very successful, they are structured very similarly to how Fedora is. Many of the concepts and governance structures are extremely similar to how the Fedora Project works. The difference between Fedora and Kubernetes is that Fedora doesn't have people paid to advocate for the community and encourage folks to participate in it.
Nitpicking here, as less than two years old RedHatter and more than 10 years old Fedora contributor, I am actively against separating Red Hatters who contribute to Fedora from the rest of Fedora community. And some of the Red Hatters I know are the most fierce Fedora advocates you can ask for.
(I am not that fierce yet, but sometimes I am trying)
When *I* look at Fedora, I see something special: a community with massively unrealized potential. We're a huge passionate group of folks that try to work diligently and amicably with the communities that make the projects that the Fedora Linux distribution ships. We are also often the drivers of innovation. In many cases, this is obvious (UsrMerge, systemd, PipeWire, Wayland, EarlyOOM, etc.). In some cases, it's not (Koji, fedmsg, HyperKitty, Pagure, Dist-Git, Ansible, AppStream, RPM-OSTree, etc.). And a great deal of this is driven by people in the community who *aren't* from Red Hat!
But a lot of people don't see it this way, and many of us bristle when they bring up the RHEL point. Just look at Phoronix, Reddit, or any other place, and you'll see the comments about people being "free labor" or "free QA" for Red Hat. This is an unfair characterization that speaks to a deep misunderstanding of how this relationship is supposed to work. And it goes both ways: both Fedorans and Red Hatters misunderstand this and mischaracterize it in ways that are counterproductive.
Indeed, as Fedora Ambassador I see this happening a lot in various communities, usually already hostile by some other reasons. Over the years I learned to accept the fact that Fedora is indeed balancing on this edge, all the time. It is hard and it is complicated, but we are doing it for quite some time already. With some downsides and upsides, we keep moving.
This balancing act on one hand causes frustration, but on the other - it is something which feeds our evolution as a project. If you don't have the downstream, you don't have a use case, which could bring you down to earth and to real world tasks, and you don't have resources to make something big. If you don't have upstream and community, no one challenges your decisions, and no one forces you or teaches you to prove yourself, again and again.
But I am quite disappointed that we are discussing this under the ELN topic. As it was designed exactly to not allow this attitude to grow. It is maybe us not explaining it better, or maybe some generic historical baggage, which we carry, played the role. But honestly, it is just sad.
For me one of the main achievements (I should probably say challenges, as we haven't achieved it yet), or better, one of the _defining_ properties of the ELN effort is that we keep Fedora Project and Fedora maintainers in charge of the whole thing. This is what we were fighting for, internally and externally.
So rather than just creating some place where RHEL engineers can share their code to public (which would be so much easier to do), we create an incentive for RHEL engineers to come to Fedora Project and Fedora community, bringing their work, their expertise and their resources, and putting it into Fedora development under Fedora guidelines.
And while it may bring additional conversation topics to non-RedHat Fedora community members, it is actually a much larger challenge for RHEL developers. And people who commit to it, who try to bring something useful to Fedora, who find time to make it work in between of all of their downstream activities, they deserve the respect for what they are doing. They _are_ the Open Source developers, and they are Fedora community too.
So I guess, in the end, what I want to see is RHEL becoming more like Fedora: more participatory and better able to respond to the needs of the community as well as Red Hat's customers. To me, I think ELN, when done right, can do just that.
I agree with this goal.
And, yes, I would love to be called out on specific things, which we are not doing right, and hear suggestions on how we can make it better.
Dne 12. 05. 20 v 14:22 Aleksandra Fedorova napsal(a):
Hi,
On Tue, May 12, 2020 at 10:19 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help. Better summary, more arguments, etc..
This would encourage people who are against the change to participate.
I agree with Aleksandra up until here.
And if there are no such people to provide convincing arguments against the change in a reasonable time frame, than FESCo decides in favor of the submitter.
I disagree here. If such proposal does not have enough support, then it should not be accepted and should be revisited/abandoned/rejected. I cannot imagine any even hypothetical situation where the opposite was beneficial.
The proposal has at least support of its owners, who stepped in and spent some time describing the idea.
If there are no convincing reasons against this proposal, then it is their opinion, which matters. They have an idea, and they are willing to do the job and take the responsibility. I don't see the reason to block it then.
When the change process was established, I always proposed that the change should be always pre-approved by default. The changes would be judged by the amount of feedback received on ML after their announcement. If somebody had strong concerns, it would be possible to bring this change to be judged by FESCo.
But then everybody felt strong that it is not possible, because if there was not official body approving this, that could be end of the world. So now, when we have that body, it gives blank approvals, because the members of the body cannot get themselves educated about the problematic? Can somebody explain me what is the reason for the process then?
My proposal is that FESCo should put their stuff together and provide reasonable ruling or it should completely dissolve, because it proves itself useless. There are no reasons for the committee to gather together just to provide rubber stamps to changes.
Vít
Given that "change is out of scope of Fedora" and "support is very limited and the risk is too high" still can be a convincing reason to reject the change in some cases. But then it must be stated explicitly.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 13. 05. 20 14:45, Vít Ondruch wrote:
When the change process was established, I always proposed that the change should be always pre-approved by default. The changes would be judged by the amount of feedback received on ML after their announcement. If somebody had strong concerns, it would be possible to bring this change to be judged by FESCo.
That isn't that bad of an idea, really.
But then everybody felt strong that it is not possible, because if there was not official body approving this, that could be end of the world. So now, when we have that body, it gives blank approvals, because the members of the body cannot get themselves educated about the problematic? Can somebody explain me what is the reason for the process then?
Unfortunately, I don't full-time working week to dedicate to FESCo to reasonable educate myself on *all* proposed changes and sometimes, I decide to abstain. Does this mean I am disqualified of being a good FESCo member?
My proposal is that FESCo should put their stuff together and provide reasonable ruling or it should completely dissolve, because it proves itself useless. There are no reasons for the committee to gather together just to provide rubber stamps to changes.
It reads a bit harsh to call all the time I actually do spend on FESCo stuff useless :(
Dne 13. 05. 20 v 15:08 Miro Hrončok napsal(a):
On 13. 05. 20 14:45, Vít Ondruch wrote:
But then everybody felt strong that it is not possible, because if there was not official body approving this, that could be end of the world. So now, when we have that body, it gives blank approvals, because the members of the body cannot get themselves educated about the problematic? Can somebody explain me what is the reason for the process then?
Unfortunately, I don't full-time working week to dedicate to FESCo to reasonable educate myself on *all* proposed changes and sometimes, I decide to abstain. Does this mean I am disqualified of being a good FESCo member?
I understand. And luckily it doesn't regularly that FESCo is not decisive. But when it happens, then there should probably happen some kind of selfreflection. I think that it is enough if one of the abstainers take the time to get deeper understanding. It might be also fault of the proposal which is not clear enough to give enough insights.
The "Revise FESCo voting policy" kind of selfreflection is unexpected.
My proposal is that FESCo should put their stuff together and provide reasonable ruling or it should completely dissolve, because it proves itself useless. There are no reasons for the committee to gather together just to provide rubber stamps to changes.
It reads a bit harsh to call all the time I actually do spend on FESCo stuff useless :(
Sorry, I exaggerated the proposal and I didn't want to offend anybody.
Vít
On Wed, May 13, 2020 at 2:46 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 12. 05. 20 v 14:22 Aleksandra Fedorova napsal(a):
Hi,
On Tue, May 12, 2020 at 10:19 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
Hi,
On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher sgallagh@redhat.com wrote:
During today's FESCo meeting, we encountered an unusual voting situation for the first time: Four FESCo members voted in favor (+1) of a measure and five FESCo members opted to abstain (0) for various reasons. However, the FESCo voting policy currently reads: "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting." As a result, we were actually at an impasse until two of the FESCo members opted to change their votes to +1 to resolve the confusion.
It was subsequently suggested that we revise the policy to avoid this pitfall in the future. I volunteered to put together a proposal for how this could work and send it to the Fedora Development list for discussion. I propose the following changes to the FESCo voting policy:
- To pass any measure, a majority — defined as the greater of half the
eligible votes (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member. No measure may pass without at least one vote in favor.
- Abstaining from a vote (aka "voting 0") is considered to have
removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
A practical effect of the new abstention rule is that if two FESCo members abstain, the measure would then require only a +4 vote to pass. (A single abstention would still require a +5 vote).
I don't like this idea.
I think if FESCo members don't have enough data or understanding to vote on the topic, this means that FESCo needs to put more effort in it.
Find some subject matter experts in the community, make additional steps to learn the subject. Or, when topic has no technical foundation but more of the personal preference, bring it for a full community vote.
In the end FESCo supposed to channel the community voice. If FESCo can not make a decision, it means delegation of the decision to FESCo by community failed. So let's go back to community?
So how about the alternative: if FESCo can't come up with the decision, it announces the stalled decision to fedora-announce and requests help. Better summary, more arguments, etc..
This would encourage people who are against the change to participate.
I agree with Aleksandra up until here.
And if there are no such people to provide convincing arguments against the change in a reasonable time frame, than FESCo decides in favor of the submitter.
I disagree here. If such proposal does not have enough support, then it should not be accepted and should be revisited/abandoned/rejected. I cannot imagine any even hypothetical situation where the opposite was beneficial.
The proposal has at least support of its owners, who stepped in and spent some time describing the idea.
If there are no convincing reasons against this proposal, then it is their opinion, which matters. They have an idea, and they are willing to do the job and take the responsibility. I don't see the reason to block it then.
When the change process was established, I always proposed that the change should be always pre-approved by default. The changes would be judged by the amount of feedback received on ML after their announcement. If somebody had strong concerns, it would be possible to bring this change to be judged by FESCo.
But then everybody felt strong that it is not possible, because if there was not official body approving this, that could be end of the world. So now, when we have that body, it gives blank approvals, because the members of the body cannot get themselves educated about the problematic? Can somebody explain me what is the reason for the process then?
I think you are taking it a bit too far.
We were talking about highly theoretical case here, when: 1) majority FESCo members had no convincing reasons to reject the change, but couldn't approve it, 2) they asked explicitly community to help in resolution, 3) community also haven't found reasons to reject the change, 4) and majority of FESCo members are still not convinced to approve it, but not convinced to reject it either.
It kind of can happen only in a mathematical sense of a word "can". So I probably shouldn't have argued about it.
So how about - if we ever see this happening in real life, we don't follow any policy, but come back to this conversation and rethink the role of FESCo?
My proposal is that FESCo should put their stuff together and provide reasonable ruling or it should completely dissolve, because it proves itself useless. There are no reasons for the committee to gather together just to provide rubber stamps to changes.
Vít
Given that "change is out of scope of Fedora" and "support is very limited and the risk is too high" still can be a convincing reason to reject the change in some cases. But then it must be stated explicitly.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Wed, May 13, 2020 at 6:46 AM Vít Ondruch vondruch@redhat.com wrote:
But then everybody felt strong that it is not possible, because if there was not official body approving this, that could be end of the world. So now, when we have that body, it gives blank approvals, because the members of the body cannot get themselves educated about the problematic? Can somebody explain me what is the reason for the process then?
The process catches subtle errors all the time that could cause problems for users or other stakeholders, it helps keep Fedora stable and on course.
And in particular with this specific change, is already well tested elsewhere, NetworkManager folks were in favor, and it was discussed by the Workstation working group prior to becoming a change proposal.. And in the original FESCo vote it passed with a majority of the votes.
My proposal is that FESCo should put their stuff together and provide reasonable ruling or it should completely dissolve, because it proves itself useless. There are no reasons for the committee to gather together just to provide rubber stamps to changes.
Plurality decisions are frequent in most committees. In no possible way was the process unreasonable.
And review your metaphors please: to use a rubber stamp means that something is approved without assessment. That is self evidently not the case. This is not resolved's first day at the rodeo.
-- Chris Murphy
On Wednesday, May 13, 2020 4:29:19 PM MST Chris Murphy wrote:
On Wed, May 13, 2020 at 6:46 AM Vít Ondruch vondruch@redhat.com wrote:
But then everybody felt strong that it is not possible, because if there was not official body approving this, that could be end of the world. So now, when we have that body, it gives blank approvals, because the members of the body cannot get themselves educated about the problematic? Can somebody explain me what is the reason for the process then?
The process catches subtle errors all the time that could cause problems for users or other stakeholders, it helps keep Fedora stable and on course.
And in particular with this specific change, is already well tested elsewhere, NetworkManager folks were in favor, and it was discussed by the Workstation working group prior to becoming a change proposal.. And in the original FESCo vote it passed with a majority of the votes.
My proposal is that FESCo should put their stuff together and provide reasonable ruling or it should completely dissolve, because it proves itself useless. There are no reasons for the committee to gather together just to provide rubber stamps to changes.
Plurality decisions are frequent in most committees. In no possible way was the process unreasonable.
And review your metaphors please: to use a rubber stamp means that something is approved without assessment. That is self evidently not the case. This is not resolved's first day at the rodeo.
To change abstaining to be the same as removing oneself from the pool of eligible voters would have the same effect as providing rubber stamps to changes. If folks are uncertain about a given change, it's certainly very valid to abstain, and if many people are abstaining, the issue is with the proposal, not the voters.
John M. Harris Jr wrote:
To change abstaining to be the same as removing oneself from the pool of eligible voters would have the same effect as providing rubber stamps to changes. If folks are uncertain about a given change, it's certainly very valid to abstain, and if many people are abstaining, the issue is with the proposal, not the voters.
I think that if a FESCo member is unsure about a change, that member should actually vote -1 and request more documentation. Then the feature can be voted on again once that documentation is provided and the situation is clarified. And if the situation does not improve in a timely manner, the feature should be rejected for good, instead of revoting repeatedly in a loop as has been done in at least one case.
Abstaining means "I don't care", not "I feel uncomfortable with this change". The latter warrants for a -1 vote.
It looks like there are still some open questions on that systemd-resolved feature, as can be seen in the "Summary/Minutes from today's FESCo Meeting (2020-05-11)" thread. Surely, those should have been answered BEFORE approving (or rejecting) this change.
Kevin Kofler
On Thu, May 14, 2020 at 10:57 AM Kevin Kofler kevin.kofler@chello.at wrote:
Abstaining means "I don't care", not "I feel uncomfortable with this change".
I'm going to disagree with you here, specifically with regards to the "I don't care" piece. From my time in FESCo, and as the FPL before that -- I can never remember a time when someone abstained because they didn't care. I remember people abstaining because they didn't feel it was appropriate for them to vote on their own ticket, or they felt uncomfortable for whatever reason, but never simply because they didn't care.
Please remember that FESCo members can vote either "+1" or "0" or "-1" for a particular change. I would think voting "0" would be more appropriate for a "I don't care" vote. But I still don't see an "I don't care" vote as a reason to abstain.
-- Jared Smith
On Thu, May 14, 2020 at 11:47 AM Jared K. Smith jsmith@fedoraproject.org wrote:
I'm going to disagree with you here, specifically with regards to the "I don't care" piece. From my time in FESCo, and as the FPL before that -- I can never remember a time when someone abstained because they didn't care. I remember people abstaining because they didn't feel it was appropriate for them to vote on their own ticket, or they felt uncomfortable for whatever reason, but never simply because they didn't care.
Please remember that FESCo members can vote either "+1" or "0" or "-1" for a particular change. I would think voting "0" would be more appropriate for a "I don't care" vote. But I still don't see an "I don't care" vote as a reason to abstain.
For the record, "0" is used much more often with the following meanings: * I am the submitter of this Change Proposal and abstain from voting due to bias. * I do not have sufficient expertise in this area to have a considered opinion on the matter, so I am deferring to other members of the committee who do. * I have reservations about the implementation that are not serious enough for me to vote -1, but I don't want to go on record as being in support.
The last one usually comes up when the vote is already decided (+5 or more) and someone is reserving the right to say "I told you so" later. An argument can be made that this should just result in a -1 vote (particularly since it won't change the outcome). The first and second ones are the cases that I was attempting to address with this proposal. Note that I posted what I did as a conversation-starter; if there is a better phrasing or tweaks (like for example how my math was wrong and didn't match what I had intended...) they are most welcome.
One thing that I think this conversation thread *has* achieved is identifying that most Fedorans don't consider a FESCo member voting in favor of their own Change Proposal to be a conflict of interest. I think we should probably recognize this and take that out of the equation (which also has the side-effect of reducing the frequency we might need to deal with such things).
I'll try suggesting another version of the policy for votes *in meetings* (these do not impact votes resolved exclusively in-ticket):
* To pass any measure, a majority — defined as the greater of half the eligible votes + 0.5 (rounded up) — must vote in favor of the measure. The standard set of eligible votes is one vote per FESCo member.
* Abstaining from a vote (aka "voting 0") is considered to have removed that FESCo member's vote from the set of eligible votes. This must be done explicitly and is never to be assumed from lack of communication.
* If more than half of the FESCo members (rounded down) are unavailable or have abstained from voting, the vote lacks a quorum and may not be resolved.
* If two FESCo having a quorum in attendance pass that fail to meet voting quorum for an issue, the ticket is considered rejected(*).
Practical effect: No meeting vote can pass with fewer than 3 positive votes. The worst-case scenario for a measure to pass in a meeting vote is therefore: (+3, 4, -2)
(*) At this point, if that many FESCo members haven't formed a strong opinion on the matter, it's reasonable to assume that the proposed Change is not good enough.
Stephen Gallagher wrote:
One thing that I think this conversation thread *has* achieved is identifying that most Fedorans don't consider a FESCo member voting in favor of their own Change Proposal to be a conflict of interest. I think we should probably recognize this and take that out of the equation (which also has the side-effect of reducing the frequency we might need to deal with such things).
For the record, I *do* consider this a conflict of interest.
But there are actually many more conflicts of interest that are not immediately recognized, even by the people concerned. Many FESCo members are members of some workgroup and will thus be biased in favor of changes submitted by that workgroup. Also, FESCo members are often Red Hat employees.
Kevin Kofler
On Sat, May 16, 2020 at 9:02 AM Kevin Kofler kevin.kofler@chello.at wrote:
Stephen Gallagher wrote:
One thing that I think this conversation thread *has* achieved is identifying that most Fedorans don't consider a FESCo member voting in favor of their own Change Proposal to be a conflict of interest. I think we should probably recognize this and take that out of the equation (which also has the side-effect of reducing the frequency we might need to deal with such things).
For the record, I *do* consider this a conflict of interest.
But there are actually many more conflicts of interest that are not immediately recognized, even by the people concerned. Many FESCo members are members of some workgroup and will thus be biased in favor of changes submitted by that workgroup.
I don't think this necessarily is as strong conflict of interest as you'd expect. Most folks are involved in multiple teams (WGs, SIGs, etc.) and those "conflicts" naturally exist. I think the only *real* conflict would be a change owner voting *for* their change. For example, If this were such a thing to worry about, I'd be unable to vote for any change proposal, due to the number of groups I *actually* do work in.
Also, FESCo members are often Red Hat employees.
Only way to fix that is for more non-RHers to run for FESCo. ;)
But again, I don't necessarily see them being employed by Red Hat as a negative there. It *does* induce some bias, for sure, but in general, this is a lot less pronounced than many folks would expect. And I'm speaking as someone who tends to run into them more often than not. ;)
Today, there are a mix of Red Hat and non-Red Hat folks, and it seems to work out fine. And even Red Hatters have pushed back against other Red Hat-driven changes. So I think this fear is mostly unfounded.
-- 真実はいつも一つ!/ Always, there's only one truth!
Neal Gompa wrote:
I don't think this necessarily is as strong conflict of interest as you'd expect. Most folks are involved in multiple teams (WGs, SIGs, etc.) and those "conflicts" naturally exist. I think the only *real* conflict would be a change owner voting *for* their change. For example, If this were such a thing to worry about, I'd be unable to vote for any change proposal, due to the number of groups I *actually* do work in.
Well, I do see a strong correlation between changes being driven by large influential workgroups (e.g., Workstation or Modularity) and them being accepted by FESCo, even over predominantly negative community feedback.
But again, I don't necessarily see them being employed by Red Hat as a negative there. It *does* induce some bias, for sure, but in general, this is a lot less pronounced than many folks would expect. And I'm speaking as someone who tends to run into them more often than not. ;)
Today, there are a mix of Red Hat and non-Red Hat folks, and it seems to work out fine. And even Red Hatters have pushed back against other Red Hat-driven changes. So I think this fear is mostly unfounded.
Well, I also see a strong correlation between changes being driven, requested and/or needed by RHEL and them being accepted by FESCo, even over predominantly negative community feedback.
I am aware that correlation does not imply causation, but it does make me wonder where those correlations come from, and in particular, whether conflicts of interest play a decisive role or whether there is some other mechanism in play here.
Kevin Kofler
On 5/17/20 9:36 AM, Kevin Kofler wrote:
Well, I also see a strong correlation between changes being driven, requested and/or needed by RHEL and them being accepted by FESCo, even over predominantly negative community feedback.
I am aware that correlation does not imply causation, but it does make me wonder where those correlations come from, and in particular, whether conflicts of interest play a decisive role or whether there is some other mechanism in play here.
Some of it is a matter of resources. Fedora is a community distribution, in the sense that anyone with the time and drive to contribute is able to do so in some capacity. But there's a large variation in the capacity of any individual contributor to actually make changes. People who are paid by Red Hat and other companies, or who are otherwise fortunate enough to be able to dedicate a large amount of resources to work on Fedora and related technologies, are more likely to have the time and energy to experiment with and build new tools or technologies, integrate them into the distribution, and go through the process of getting those things through the relevant hoops to be part of the core distribution. And if you're getting paid by a company to do something, it's usually because it will benefit the company in some way (those benefits don't always have to be in conflict with the goals of the distribution, but it's definitely a spectrum).
That tends to explain why Red Hat employees are driving many of the larger changes to the distribution, and why they tend to be aligned with the needs of RHEL, but not why they're being accepted by FESCo over negative community feedback. To explain that, I think we have to look at the change process itself.
The standard for accepting a change via the Change Process (which I assume to be the project mission and foundations[1] - I can't find anything specific about approval criteria in the change process documentation) is so broad that the bar for saying "no" to a change proposal is quite high. Unless negative feedback from the community can make a convincing case that a change is not technically sound (and can't be rolled back with a contingency plan), doesn't tick all of the process boxes, or doesn't _somehow_ align with the mission and foundations of the distribution, there's really no reason for FESCo to block a change.
Rich
Jared K. Smith wrote:
I'm going to disagree with you here, specifically with regards to the "I don't care" piece. From my time in FESCo, and as the FPL before that -- I can never remember a time when someone abstained because they didn't care. I remember people abstaining because they didn't feel it was appropriate for them to vote on their own ticket, or they felt uncomfortable for whatever reason, but never simply because they didn't care.
Please remember that FESCo members can vote either "+1" or "0" or "-1" for a particular change. I would think voting "0" would be more appropriate for a "I don't care" vote. But I still don't see an "I don't care" vote as a reason to abstain.
Voting "0" is exactly what I mean by "abstain".
Kevin Kofler
On Thursday, May 14, 2020, Jared K. Smith jsmith@fedoraproject.org wrote:
On Thu, May 14, 2020 at 10:57 AM Kevin Kofler kevin.kofler@chello.at wrote:
Abstaining means "I don't care", not "I feel uncomfortable with this change".
I'm going to disagree with you here, specifically with regards to the "I don't care" piece. From my time in FESCo, and as the FPL before that -- I can never remember a time when someone abstained because they didn't care. I remember people abstaining because they didn't feel it was appropriate for them to vote on their own ticket, or they felt uncomfortable for whatever reason, but never simply because they didn't care.
Please remember that FESCo members can vote either "+1" or "0" or "-1" for a particular change. I would think voting "0" would be more appropriate for a "I don't care" vote. But I still don't see an "I don't care" vote as a reason to abstain.
In the end voting 0 means "I don't care" - even more so with this proposal as you are taking yourself out of the decision process. If you have an opinion in either direction then vote -1 or +1.