Document Engineering Internal Decision-Making Process

[stephenpdeos]

We are going to start making decisions in a more organized fashion. We need to first decide and vote on how consensus is achieved.

[greg7mdp]

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

[greg7mdp]

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.

[ScottBailey]

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

[greg7mdp]

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.

[ScottBailey]

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.

[greg7mdp]

Sounds good @ScottBailey, sorry for the misunderstanding!

[kj4ezj]

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.

[wanderingbort]

Notes: from 4/4/23 call

• from @stephenpdeos process became very focused, DevRel lost its value in this process, the transition.
• from @ericpassmore we never seem to break out into the unstructured conversation that used to happen.
• can add more meetings but that carries other problems
• for clarity discussing things that aren't "decisions" is harder to achieve in this format
• is the "15min reserve" too short or is it a different fundamental thing?
  • do we put the unstructured time first?
• Activation energy is a lot more work to add an issue than adding a bullet point
• is 10 minutes arbitrary? should time commit be part of the proposal?
• Are we missing a category that is neither a concrete decision or free and open discussion?
• from @greg7mdp there is no forum for relaxed conversation like a coffee break

Action items:

• @kj4ezj to reach out to @nsjames to get DevRel's perspective

[kj4ezj]

Feedback from today's meeting (2023-04-04):

1. Bart
   1. The quantity and velocity of topics that have come through this process have been dramatically fewer than the previous (open-ended) process.
2. Stephen
   1. It did feel like a little bit was lost with how focused we got with this topic. It eliminated some room to catch up on other fronts. The DevRel team was having a hard time extracting value from this meeting.
3. Eric
   1. I think the Decision tag is good because it helps filter it down.
   2. I think we decided if we would finish an issue then we would break out into a more unstructured conversation, but we haven't gotten there yet.
4. Scott
   1. Can't the unstructured conversation happen in an external meeting, or in a ten minute topic?
5. Areg
   1. Should the unstructured time be longer?
6. Eric
   1. No, we just need to have them. I don't know how to bring up items that aren't decisions.
   2. Stephen aligns with this.
7. Areg
   1. Is the unstructured conversation too short, or is it qualitatively different?
      1. Stephen: The activation energy to submit an issue is too high compared to submitting a bullet point on an agenda.
8. Zach
   1. We have ended these meetings before the hour multiple times, so we are not using all of our time for unstructured conversation.
   2. Maybe unstructured conversation should happen before the issue discussion so external groups can drop.
   3. The ten minute time limit is often not appropriate, perhaps the time limit should be a part of the issue proposal.
9. Stephen
   1. There are in-between things that are too big for the open discussion, but too small for an issue. There are also things that come up at the last minute and will not get upvotes in time, but deserve conversation.
   2. Nathan is the right person to talk to for DevRel opinions.
10. Bucky
    1. Is it necessarily a bad thing that we are going through less items? Is everything we went through on the free agenda worth everyone's time?
11. Scott
    1. I agree that it is good for the barrier to entry to be higher.
12. Greg
    1. I agree the purpose is to use the meeting efficiently with respect to peoples' time, but we also need a forum to have discussions that might happen in passing in an office. Let's not totally dismiss the idea of unstructured discussion.
13. Bart
    1. It was intentional to throw a wet blanket on this meeting. There was a period where we took a lot of time and had a lot of discussion without making impactful decisions. We do not do a good job at ad-hoc discussions. The watercooler channel does not service that. I am worried about a meeting where people are expected to attend to have those discussions.
14. Eric
    1. I like the idea of the coffee discussion, but it should have a different type of structure and different time.
15. Areg
    1. The closest thing I've found to that is discussion after standup.
16. Bart
    1. We should lean into cases where that is already happening organically, then block out space on everyone's calendar where they know they will not have time on their schedule so they can hang around if they choose to.
       1. Self-assigned action item for Bart.