Open stephenpdeos opened 1 year ago
I feel that, regardless of who is allowed to vote, requiring a super-majority to make a change is enshrining the Status quo bias in our organization, which would be a mistake.
Even though we may prefer the status quo, whenever a change is considered, we should weigh the pros and the cons, and if the pros outweigh, we should make the change. It is fine to add a weight for possible unforeseen issues if we think they are likely (the unknown unknowns).
I think that Areg's proposal to allow yes/no/abstain votes is fine, the abstain votes should be removed, and if the yes have >50% of the remaining votes, the proposal passes. So there is a slight advantage for the status quo already as the yes require over 50% to pass.
If we want to favor action (or to counteract the natural human preference for the status quo) we can say that greater or equal than 50% is enough to pass.
I don't see a rationale for requiring a super-majority to effect change, unless we have a reason believe that change should be avoided as much as possible.
I currently have no preference regarding simple majority vs super majority. But since change usually has cost, I believe a change should require some majority, i.e. > 50%.
@greg7mdp I failed to find any research on status quo bias and software quality. Do you have any links for this? Or really any information regarding software and status quo bias.
I concur that abstain votes should not be counted against the majority regardless of which type is chosen. Additionally, absent votes should be counted toward "no change" (e.g. Frank was on vacation and Ted intentionally scheduled a meeting to get a change passed).
Additionally, absent votes should be counted toward "no change"
That is exactly status quo bias. When stating that, you implicitly show your preference for no change. But no change is an action with consequences, exactly like a change. If a majority feels that effecting a change is better for the organization, why assume that they are wrong, that change has a cost they haven't considered, and that we should diminish the power of their opinion by adding the non-voters to the other side?
My first comment has a link to an article about Status quo bias with references. It is not specific to software.
Additionally, absent votes should be counted toward "no change"
That is exactly status quo bias. When stating that, you implicitly show your preference for no change. But no change is an action with consequences, exactly like a change. If a majority feels that effecting a change is better for the organization, why assume that they are wrong, that change has a cost they haven't considered, and that we should diminish the power of their opinion by adding the non-voters to the other side?
I believe I was unclear or, possibly, you've misread - I am advocating against bad faith manipulations.
My first comment has a link to an article about Status quo bias with references. It is not specific to software.
It was so short and not directly relevant to software engineering and so I was hoping you might have something with more meat. I looked myself first, but couldn't find anything.
Regardless of what's decided here, the autonomy to make good decisions is important. We shouldn't overly burden ourselves with bureaucracy.
And, for example, @spoonincode 's general distaste for FetchContent
probably isn't worth as much time as we've sunk into it. I think finding consensus for certain changes is much more interesting than "putting it to a vote" and probably leads to better outcomes. For example, I believe that if I am correct about something it should become self evident if I'm given a fair opportunity to explain it. And the opposite is also usually true, if my argument isn't persuasive enough there's probably a reason and I should reexamine my position.
(As an aside, Matt's arguments against FC are valid, though I think there is a pattern we can use that addresses these concerns, but it requires CMake 3.25 which is the latest stable. That's unreasonably new. Having said that, I really like FC so I'll likely use it in my personal stuff and would certainly argue for it in a solution that wasn't for public consumption.)
Eh, I've diverged, but let's not put bad bureaucracy in place.
Sounds good @ScottBailey, sorry for the misunderstanding!
From video, we are going to sit on this for a week or two to determine if we like our current process or if we feel it needs to be modified before we invest more time into this issue. Whichever the outcome, our process will need to be documented.
Notes: from 4/4/23 call
from @greg7mdp there is no forum for relaxed conversation like a coffee break
Action items:
Feedback from today's meeting (2023-04-04):
Decision
tag is good because it helps filter it down.
We are going to start making decisions in a more organized fashion. We need to first decide and vote on how consensus is achieved.