On first reading this looks great to me, I'll read it a few more times and share any thoughts I have or respond to others.

Excellent work Noel.

I love the role definitions and requirements

For the lazy consensus portion:

lets say I just want to throw together a cool ujust to grab a decky plugin thats not on the store, or a toggle to fix a bluetooth quirk ,or something equally low impact, non breaking

does that need a consensus request email, wait 3 days, then open the PR? Or is there a subjective threshold of impact that triggers these requirements?

I think we should probably leave email for the dinosaurs and make sure that this process can be done entirely through GitHub, but that should be a minor adjustment.

does that need a consensus request email, wait 3 days, then open the PR? Or is there a subjective threshold of impact that triggers these requirements?

The section below states that "This process is for major impactful decisions for Bazzite or large code changes."

I would assume that something like a ujust to add a decky plugin would be the same process as-is today, without needing a consensus to be passed.

does that need a consensus request email, wait 3 days, then open the PR? Or is there a subjective threshold of impact that triggers these requirements?

The section below states that "This process is for major impactful decisions for Bazzite or large code changes."

I would assume that something like a ujust to add a decky plugin would be the same process as-is today, without needing a consensus to be passed.

Right, in my eyes smaller code contributions would use lazy consensus. Voting is only needed when larger changes or if a maintainer or member objects to the PR being merged and it can't be sorted out with a quick change.

Yeah, it is a great start and we can start working on it.

I will add three things and revisit it later.

1 - the Project paragraph is out-of-scope for this discussion and it's something that we should discuss internally first. Some things are agreeable, e.g., "Bazzite will always remain open source", but some need discussion. Let's remove it for now and revisit it later.

2 - There is an overt focus on hard "technical" requirements and rights for the different levels of membership. E.g., "Enabled two-factor authentication", "Primary reviewer for at least 5 PRs", "Defined by: Admin permissions on repositories managed by Bazzite". We should not mix virtual and real life.

The process we are going through is to establish a governance structure which is something squishy fleshy humans do and not defined by pressing buttons on a proprietary (github) dashboard. I have been part of multiple volunteering orgs, and that essentially means establishing a charter, and having a formally defined voting structure for promoting people to "Contributors" and "Maintainers", which would roughly translate into "Organization Members", and "Board Members" in a traditional charter.

This would also then allow us to move into more of a foundation style and establish a legal entity that we can then e.g., use to accept donations, grants, pay out infrastructure costs, freelancers for needed work (not allowed by the current document), secure boot keys, etc. Much like KDE, Gnome, Fedora.... But this comes after we visit [1].

Broadly speaking in volunteering organizations, Organization Members vote on who should be in the Board, which then takes executive decisions until it is time for a re-election. For normal organizations this is yearly, but as Bazzite currently has a pre-enstablished maintainer pool, it is out of scope for the foreseeable future. We are humans though, and if this org goes well, it will succeed all of us, so it will be relevant some day.

The more important part is to establish a voting structure for Bazzite maintainers to vote on issues, and if a consensus cannot be raised or it would be disagreeable among the organization members, to be able to extend the voting process to the organization members themselves. This would mean that for most of the time we do not raise a vote.

It would only be required for major changes, where major is defined as you will know intuitively, we are not robots, intuition is a thing. But the focus would be essentially three things: deprecations/software removals, introductions of technical debt (new software), and changes that can impact stability.

Finally, we need to enstablish a process for people to become org members where we do not focus on just hard technical contribution. We can make it less concrete, focus on sponsors (voting; in the current document), time-based (e.g., at least three months), and require a pulse+fuzzy contribution based with a guideline for what's required to be a member.

3 - We can circle back to Univeral Blue's role on Bazzite after formalizing [2]. It is clear that as a related entity to Universal Blue, Universal Blue members should have an easier path to becoming (or being defacto) Bazzite Contributors.

But Bazzite is a separate project/org. In the current document, it is listed that each UBlue member gets a vote or UB itself is limtied to a vote. If the former, it means that as UB has around 15 members now, it would also have 70% of control of the Bazzite decision process. If the latter, 1 vote out of around 8-10 Bazzite members is not much. We can discuss a 10-20% voting participation for Universal Blue members into Bazzite.

Of course, when it affects communal resources such as builders, this is not a Bazzite decision but it should be brought/only concern Universal Blue members/approvers.

Examples of Software foundation Charters/Articles of Incorporation/Governance/Bylaws
Apache
Gnome
KDE (Articles of Association)
Rust (Governance)
CNCF
Linux Foundation

(KDE and Gnome are good traditional charters)

(yes general assemblies are very boring; if we were in-person we would bring cake)

1 - the Project paragraph is out-of-scope for this discussion and it's something that we should discuss internally first. Some things are agreeable, e.g., "Bazzite will always remain open source", but some need discussion. Let's remove it for now and revisit it later.

I think it is exceptionally important for a Project and a Product to be distinctly defined. Defining what the project is for anyone reading our governance is extremely important. Is there anything in the project section that you distinctly disagree with?

2 - There is an overt focus on hard "technical" requirements and rights for the different levels of membership. E.g., "Enabled two-factor authentication", "Primary reviewer for at least 5 PRs", "Defined by: Admin permissions on repositories managed by Bazzite". We should not mix virtual and real life.

This is a very valid point that you bring up. I definitely think there is an opportunity to better define what roles folks hold inside the Bazzite project. There is some clarity that is missing of who does what inside the project, and there are a lot of folks that hold dual responsibilities inside the project that are too much for any one person to hold by themselves. (I.E. Kyle being responsible for writing code and managing portions of our social media presence. I think these things should be offloaded and put out there for everyone to review when there is a need to do so, but I also think there needs to be a level of autonomy and responsibility that folks hold in that position).

The process we are going through is to establish a governance structure which is something squishy fleshy humans do and not defined by pressing buttons on a proprietary (github) dashboard. I have been part of multiple volunteering orgs, and that essentially means establishing a charter, and having a formally defined voting structure for promoting people to "Contributors" and "Maintainers", which would roughly translate into "Organization Members", and "Board Members" in a traditional charter.

For sure. The biggest thing I want to maintain is a balance between "death by committee" decision-making and a lean structure that allows us to innovate quickly and efficiently. Many of the problems I see in entities (not just open source projects) is losing sight of what is important and having decisions never get made because the governance structure is too bureaucratic.

This would also then allow us to move into more of a foundation style and establish a legal entity that we can then e.g., use to accept donations, grants, pay out infrastructure costs, freelancers for needed work (not allowed by the current document), secure boot keys, etc. Much like KDE, Gnome, Fedora.... But this comes after we visit [1].

A foundation is an interesting idea, but I think there are major changes to the project that would have to happen in order for that to be an easier transition. I definitely agree with you that we need to figure out [1] first before even thinking about this.

Broadly speaking in volunteering organizations, Organization Members vote on who should be in the Board, which then takes executive decisions until it is time for a re-election. For normal organizations this is yearly, but as Bazzite currently has a pre-enstablished maintainer pool, it is out of scope for the foreseeable future. We are humans though, and if this org goes well, it will succeed all of us, so it will be relevant some day.

Yeah, I agree with you that I think it is too early to think about elections and committee based decision-making. That also has its challenges, and I want to think about how we can potentially innovate so that we can try to keep bureaucratic red tape to a minimum.

The more important part is to establish a voting structure for Bazzite maintainers to vote on issues, and if a consensus cannot be raised or it would be disagreeable among the organization members, to be able to extend the voting process to the organization members themselves. This would mean that for most of the time we do not raise a vote.

I agree. I like lazy consensus as the default and moving to a majority vote as a way to move things forward. Not only that, but I don't like the idea of folks having veto power or other ways to hold the project back for no reason. Convince me why I should think something is a good idea.

It would only be required for major changes, where major is defined as you will know intuitively, we are not robots, intuition is a thing. But the focus would be essentially three things: deprecations/software removals, introductions of technical debt (new software), and changes that can impact stability.

I can add these to the list of things that should be kept in mind when proposing a change. I do think it is the responsibility of those who hold a position of member or maintainer to keep an eye out for things that qualify, and propose an objection as part of the Lazy Consensus process.

Finally, we need to enstablish a process for people to become org members where we do not focus on just hard technical contribution. We can make it less concrete, focus on sponsors (voting; in the current document), time-based (e.g., at least three months), and require a pulse+fuzzy contribution based with a guideline for what's required to be a member.

Agreed, I think my current structure is lacking in finding ways for non-technical contributors to be promoted and added to the organization. I think we need to maybe workshop a bit on how we can define these roles inside the organization and what we want there for now. This governance should always be subject to change and never set in stone. It is supposed to be our North Star. Maybe we should consider reviewing the governance process on a regular basis and make sure folks are good with it as it is? Obviously, anyone can propose changes whenever they want.

3 - We can circle back to Univeral Blue's role on Bazzite after formalizing [2]. It is clear that as a related entity to Universal Blue, Universal Blue members should have an easier path to becoming (or being defacto) Bazzite Contributors.

I agree. What I wanted to make sure was clear in the document is that it is possible for Universal Blue contributors to become Bazzite contributors, and that you can be just a Bazzite contributor and not a member of Universal Blue. You can hold both roles if you wish, but your voting rights are your Bazzite voting rights by default. If you are only a Universal Blue contributor, that does not automatically make you a Bazzite contributor. You would be part of the pool of contributors that get a single vote in what I have proposed.

But Bazzite is a separate project/org. In the current document, it is listed that each UBlue member gets a vote or UB itself is limtied to a vote. If the former, it means that as UB has around 15 members now, it would also have 70% of control of the Bazzite decision process. If the latter, 1 vote out of around 8-10 Bazzite members is not much. We can discuss a 10-20% voting participation for Universal Blue members into Bazzite.

To clarify, Universal Blue as an organization gets a SINGLE vote. We can decide as part of this process who is a Bazzite Member, Maintainer, etc. to determine how much control that would actually give Universal Blue. With my current proposal, they would be influential yes, but not 70% of the vote. If there is a way I can clarify this or if we want to give a percentage vote rather than just 1 vote, I'm open to changes. I want to respect that Bazzite is part of Universal Blue, but has the capacity to act independently in matters of how Bazzite conducts itself.

Of course, when it affects communal resources such as builders, this is not a Bazzite decision but it should be brought/only concern Universal Blue members/approvers.

Exactly! This is where there would be value in having Bazzite members be part of Universal Blue to help drive this shared community effort. It is similar to what I am proposing with other upstream communities we depend on. We want to help our upstream partners make good decisions. How Universal Blue wants to handle voting related to all of this is left up to them and out of scope for your conversation :)

I have also made some slight tweaks based on Laura's recommendations in the document, so please re-read it. You should see the sections on where she commented, those are the sections I changed.

I think it is exceptionally important for a Project and a Product to be distinctly defined. Defining what the project is for anyone reading our governance is extremely important. Is there anything in the project section that you distinctly disagree with?

My overall objection to the Project paragraph was because it sets expectations too low and bars making Bazzite something useable by end consumers. Essentially, it says: this is hobby sh*, do not use it.

Bazzite is both a project and a product. What it is not, however, and there is a general but not concrete consensus for, is a commercial product. If you say Bazzite is not a product, you are saying that people should not use it or rely on it.

Also, while it is true that, currently, the people that work on Bazzite are donating their time, if Bazzite becomes adopted by orgs that will no longer be the case. Someone will get paid by someone (who may or may not be affiliated with Bazzite) to put something in there.

Of course, when it comes to SLAs and general homologation, there is a general consensus that SLAs and a large part of homologation is out of scope as far as Bazzite and contributors (in their interactions with Bazzite) are concerned.

You could just rephrase the whole paragraph to say that Bazzite is a community effort in producing a high quality gaming image, through developing new and combining existing technologies, that is provided to users as free software (as in free speech and free beer), without the expectation of support or warranty.

For sure. The biggest thing I want to maintain is a balance between "death by committee" decision-making and a lean structure that allows us to innovate quickly and efficiently. Many of the problems I see in entities (not just open source projects) is losing sight of what is important and having decisions never get made because the governance structure is too bureaucratic.
snip...
I agree. I like lazy consensus as the default and moving to a majority vote as a way to move things forward. Not only that, but I don't like the idea of folks having veto power or other ways to hold the project back for no reason. Convince me why I should think something is a good idea.

Nobody VETOs things for no reason, if they did that's where the voting process would kick in. But in general, having something people can rely on means that you cannot drop or introduce dependencies willy nilly. And that introduces a bit of friction, which is ok. In the same way life balance and not pushing to prod are ok 🙂

The major reason we are heading this way, and I am pushing this way, is to lower the amount of drive-by contributions and subsequent tech debt that is introduced without consensus, especially in cases where the individuals involved do not take responsibility of this added tech debt, or do not do it to a standard that is expected by our users. Yes, as politicians know, announcing new initiatives is fun and exciting, but supporting existing infrastructure is not.

The rest of the text is good 🙂

I will look the draft again tomorrow. I spent too much time on this today. If you make other changes LMK. Night.

lower the amount of drive-by contributions

You're probably better off spinning up into an independent foundation than doing this as part of universal blue.

I guess i should summarize the two main goals of this.

The main goal is to get Bazzite to have a normal release cadence with few late nights, as it is unfortunately the case currently, by limiting the addition of unnecessary tech debt.

Then, long term, provide some summary legal protection for marks and a self sustaining budget that can pay for conferences and any random costs. As we bear those currently, which is unfortunate.

lower the amount of drive-by contributions

You're probably better off spinning up into an independent foundation than doing this as part of universal blue.

Drive-by meaning to add technical debt then disappear without maintaining it. Which in this case is a negative term. One-off contributions are always appreciated.

@KyleGospo @antheas I wanted to check in with you all to see if you have any more thoughts on this proposal. I also have not heard from @wolfyreload @Zeglius about your thoughts regarding the governance.

Read through the doc, nice work on it. I see the email part was removed, that's better to just use GitHub. The lazy approvals will be good for the small changes as it would slow things down having to vote on everything. Voting on some of the bigger changes will stop a lot of the disagreements in discord.

I don't quite get the Bazzite Member sponsors part. Do long term contributors get assigned 2 Maintainer sponsors? How are the sponsors chosen?

I think this guide will help move the project in a positive direction. Can always amend it if parts of it don't work.

I want to remind everyone that this thread has been open for more than a week. I want to try and see if we can stick to the timeline of voting on this by August 1st.

Read through the doc, nice work on it. I see the email part was removed, that's better to just use GitHub. The lazy approvals will be good for the small changes as it would slow things down having to vote on everything. Voting on some of the bigger changes will stop a lot of the disagreements in discord.

I don't quite get the Bazzite Member sponsors part. Do long term contributors get assigned 2 Maintainer sponsors? How are the sponsors chosen?

I think this guide will help move the project in a positive direction. Can always amend it if parts of it don't work.

The way it works is that you work with one of the existing Maintainers to get sponsored and apply for membership. Then there is a vote from another maintainer to approve them getting added.

Action Items:

1. Vote on Governance - Everyone,
2. Look into Non-Profit based in the EU - Antheas,
3. Meet with Alma Linux to discuss foundation - Antheas, Noel, Kyle,
4. Look into filling open positions in governance model - Noel,
5. Update website with governance - Noel, Kyle