Fedora-Council/tickets ticket #488: Review of Stakeholders & Decision Makers for Git Forge Evaluation 2024

Project Discussion
,
1

@amoloney filed Fedora-Council/tickets ticket #488. Discuss here and record votes and decisions in the ticket.

Ticket text:

2

Added git-forge-future

3

Note, everyone, that Aoife made a slight edit to the original text (with an important paragraph about the intended decision-making process). The ticket-bot doesn’t have code to handle that, so I’ve updated the text above manually. Since I don’t think edits go out as email notifications by default, I’m quoting the key added part here:

4

The above snippet should probably be either

  • Edition Working Groups
  • KDE SIG

or

  • Cloud Edition Working Group
  • CoreOS Working Group
  • Iot Edition Working Group
  • Server Working Group
  • Workstation Working Group
  • KDE SIG
5

Although it’s not always the case when making a big decision, here, all Decision Makers are also direct Stakeholders, right? Would it be more clear to explicitly list them in both places?

6

I think this is a very interesting experiment in involving far more people directly in making a big decision than we have traditionally done in Fedora.[1] The Decision Makers groups add up to a lot of people! By analogy with the Go/No-Go meeting, we would expect each team to come to their own agreement, and then send a representative?

What if a team can’t come to an internal agreement? As I see it, we could either:

  • Say that if a team can’t agree, their vote counts as “abstain”.
  • Give an extended menu of options:
    1. Our team thinks GitLab CE is the better option.
    2. Our team thinks Forgejo is the better option.
    3. Our team is fine with either choice.
    4. Our team is emphatically not fine with either choice and we have an alternate suggestion.
    5. Our team could not come to an agreement.

Then, there’s the next question: what is the threshold for a vote? Assuming we add all of the edition WGs, that’s 14 votes. Does a 8–6 majority carry the day? What about 7–6 with one abstention?

The Go/No-Go meeting is full consensus. One “no” vote stops the train. That seems very appropriate for that meeting, but maybe — probably! — not here.

I think we should decide in advance what we should do in the event that full consensus can’t be reached. This will avoid possible acrimony if things turn messy and we’re forced to do something ad hoc at the Council level.

Here’s my suggestion:

  1. The Gitforge Decision Meeting will strive for full consensus, but operate on a “unanimity minus two” basis. That is, in the end, there can be two dissenters and the decision still approved. This appears on the surface similar to “need the vote to be 12–2 or better”, but underneath (and in practice!) should function quite differently.[2]
  2. If this level of consensus cannot be reached, the Council will weigh the input from all Stakeholders and Decision Makers and make the final call by our normal consensus process, starting with a proposal to adopt whichever option has the most support from the Decision Makers group, and if that fails, a proposal for the other choice.[3]

What do you all think?

  1. Making sure everyone’s voice is heard and considered has always been important to us. However, unlike e.g. Debian, we’ve never done referendums or anything really similar. I think that’s generally good, because, for example, we were able to choose systemd and move on with our lives. ↩︎

  2. See Fedora Council Charter :: Fedora Docs for more about consensus in Fedora decisions.

    Also, Consensus decision-making - Wikipedia is an excellent overview of the topic, and particularly how consensus is different from a vote, or from “unanimity in the moment”.

    A Handbook for The Consensus Decision-Making Process is a good shorter read, too. (with a few tweaks needed to apply to Fedora, like the bit about “business purpose” in the intro). ↩︎

  3. In the nine and a half years the Fedora Council has been in operation, we have never failed to reach consensus on anything important. We’ve decided to drop some things where it was clear we wouldn’t get everyone on the same page, but that’s not really an option here. If both propositions fail, and the Council does not have some other alternative at hand, there’s a process for that too (a simple majority of the Council asks me as FPL to make the call). I’ll do that if need be, but I sincerely hope it does not come to that! ↩︎

1 Like
7

Although it’s not always the case when making a big decision, here, all Decision Makers are also direct Stakeholders, right? Would it be more clear to explicitly list them in both places?

Yes thats actually correct. I was running on the assumption that the implication was obvious, but a specific call out would be a lot more clearer for folks and much more helpful! :sweat_smile:

1 Like
8

Can we also add DEI to the stakeholders please? Currently, we heavily rely on GitLab for our team workflow and organizing events.

2 Likes