Proposal: Update Universal Blue's Governance, Code of Conduct, Mission Statement, and Membership Roles

[chandeleer1698]

Discussed here: https://discord.com/channels/1072614816579063828/1072617059265032342/1465976562506661994

Purpose

With recent events I felt that it was necessary to update Universal Blue's governance to better reflect how the organization is ran today, and not how it was started. We have since grown past just a simple github repo, and are a now a full team with different fields of expertise, and I believe everyone deserves to be recognized as a staff member. Universal Blue also needs to make its commitment to remaining a Non Profit more clear for both user and members. I also believe Universal Blue needs to make a stronger commitment to working with and communicating with upstream to further push and improve Bootc on the linux desktop.

Proposal

1. Update Code of Conduct

• Add "Intentionally or maliciously not disclosing actions to the org through official channels or allowing a full 72 hour period to pass that's required to get lazy consensus will be considered a bannable offense. Examples include but are not limited to representing Universal Blue, Bazzite, Aurora, or Bluefin in official communications with vendors or press without prior notice to the org, or force pushing PRs and Proposals without any reasonable attempts to obtain lazy consensus."

2. Update Mission Statement

• Add "Bootc" to the Commitment to the Ecosystem section. Making this a project goal should be able to help drive more contributions to Bootc with the end goal of making it completely distro agnostic.

• Add "This project will not operate for profit or personal gain", "There is no dedicated support, SLA (Service Level Agreement) or warranty for Universal Blue images", and "Universal Blue will not enter into contracts or offer support guarantees to hardware vendors and corporations." to the Community and Project section.

• Add "Universal Blue is a joint venture between the Universal Blue Image Projects" to the preamble

3. Update Membership Roles

• Add Community Manager Role
• Add Community Moderator Role
• Add Artist Role
• Rename "Member" role to Maintainer
• Rename "Approver" role to Administrator

Benefits of Proposal:

1. More recognition of non github staff members as being apart of the team.
2. Stronger commitment to Bootc and opening stronger communication channels with Fedora, Flatpak, and Homebrew.
3. More concise language for Universal Blue's governance that is less open to interpretation.

Downsides of Proposal:

1. Slower responses in our communications with Vendors, and Press
2. Limiting the scope of the relationship that Universal Blue can have with prospective Hardware Vendors
3. Limiting the scope of the ways Universal Blue can generate revenue.

[noelmiller]

+1, I have been asking for governance changes for a long time and I appreciate clarifications around ambiguity in the current documents.

[bsherman]

Add skirting around the lazy consensus model as a bannable offense, and increase its scope to include "representing Universal Blue, Bazzite, Aurora, or Bluefin in official communications with vendors or press without prior notice to the org"

The meaning of "skirting around the lazy consensus model" is not clear to me.

I frequently have trouble getting approvals on uCore PRs. I've many times had to rush a force merge for a bug fix.

If we are adding "bannable offenses" they should not be vaguely defined.

[bsherman]

More consolidation of power into the Universal Blue org, with the potential of lesser autonomy for the individual projects to run how they want to.

I think this is beyond a negative, this is quite opposed to the purpose of the org.

Universal Blue has always been a facilitor, a place to collaborate, but not an "oversight committee" or body meant to govern the individual projects. Admittedly this was easier when it was basically just Bluefin and Bazzite.

[Synby]

The meaning of "skirting around the lazy consensus model" is not clear to me.

I frequently have trouble getting approvals on uCore PRs. I've many times had to rush a force merge for a bug fix.

If we are adding "bannable offenses" they should not be vaguely defined.

I believe this is because of the recent issues with GPD and Bazzite, where Antheas made promises to them without informing the rest of the org since it technically wasn't a change to Bazzite itself. The thought being that all proposals that affect the org or one of the projects actually need to be put through the lazy consensus model, even if they aren't contained to some change within the org itself.

[KyleGospo]

More consolidation of power into the Universal Blue org, with the potential of lesser autonomy for the individual projects to run how they want to.

I think this is beyond a negative, this is quite opposed to the purpose of the org.

Universal Blue has always been a facilitor, a place to collaborate, but not an "oversight committee" or body meant to govern the individual projects. Admittedly this was easier when it was basically just Bluefin and Bazzite.

I agree with your concerns, let's make me a -1 until some adjustments are made around this

[chandeleer1698]

More consolidation of power into the Universal Blue org, with the potential of lesser autonomy for the individual projects to run how they want to.

I think this is beyond a negative, this is quite opposed to the purpose of the org.
Universal Blue has always been a facilitor, a place to collaborate, but not an "oversight committee" or body meant to govern the individual projects. Admittedly this was easier when it was basically just Bluefin and Bazzite.

I agree with your concerns, let's make me a -1 until some adjustments are made around this

Okay I may have used too strong of language for what I meant.

The entire discussion about that proposal for Bazzite to have its own governance (which Antheas heavily pushed for) separate from Ublue, was to essentially push out the rest of ublue from its decision making. I feel like its necessary to close the possibility of something like that in the future. If a project disagrees with what UBlue is doing they can always leave.

I also feel like it is already the current reality the Universal Blue members are the governing body for the projects, even if people don't like how that sounds.

But if thats still not good enough of a reason I can just remove the part about Universal Blue being the "governing authority"

[chandeleer1698]

Add skirting around the lazy consensus model as a bannable offense, and increase its scope to include "representing Universal Blue, Bazzite, Aurora, or Bluefin in official communications with vendors or press without prior notice to the org"

The meaning of "skirting around the lazy consensus model" is not clear to me.

I frequently have trouble getting approvals on uCore PRs. I've many times had to rush a force merge for a bug fix.

If we are adding "bannable offenses" they should not be vaguely defined.

please give suggestions on what the exact phrasing should be. I am all ears. Maybe its better to say "Failure to give a proper 72 hour notice to the rest of the org before forcing through actions, which include but are not limited to pushing PRs, Proposals, and officially representing Universal Blue in communications with vendors and the press".

Also technically with how the lazy consensus model works, as long as you made proper care to inform the org, if no one makes any objections after 72 hours. technically you already have the authority to force merge. At least under my interpretation of whats written. Im mainly looking to expand the scope of it to cover communications with vendor and press. You should have to inform the org ahead of time.

[chandeleer1698]

Okay there I feel like thats a more clear explanation of the bannable offense I am proposing.

Also I removed the governing authority line, its not a hill thats worth dying over. Even though I still personally prefer closing the possibility of the ublue projects having their own governance. because thats exactly what Antheas fought tooth and nail over.

[NiHaiden]

+1

[ledif]

I am a bit confused about the rule where "force pushing PRs" is labeled as a bannable offense. I have a couple questions:

1. Could you give an example of what types of behavior that this supposed to prevent? (i.e., something actively malicious vs genuine mistake)
2. Force merging sometimes happens by accident (e.g., refactor: switch to polars countme#87 was accidentally merged last week). I want to make sure that these types of events will not result in a ban.

[chandeleer1698]

I am a bit confused about the rule where "force pushing PRs" is labeled as a bannable offense. I have a couple questions:

1. Could you give an example of what types of behavior that this supposed to prevent? (i.e., something actively malicious vs genuine mistake)

2. Force merging sometimes happens by accident (e.g., [refactor: switch to polars countme#87](https://github.com/ublue-os/countme/pull/87) was accidentally merged last week). I want to make sure that these types of events will not result in a ban.

its specifically prohibiting something actively malicious, and intentionally trying to skirt around the lazy consensus model. I'll update the verbage to clarify

[m2Giles]

Also. Some things need to be force pushed in order to merge.

Somethings that immediately come to mind are changes to markdown files, anything that we exclude from automated builds, and fixing gha (especially on items that cannot easily be tested locally like signing)

I think why something is being force pushed should be considered.

[chandeleer1698]

Also. Some things need to be force pushed in order to merge.

Somethings that immediately come to mind are changes to markdown files, anything that we exclude from automated builds, and fixing gha (especially on items that cannot easily be tested locally like signing)

I think why something is being force pushed should be considered.

lazy consensus is already something that is outlined as a justification to force push. I changed the phrasing to "intentionally, or maliciously"

[KyleGospo]

I think individual projects should have autonomy as they enjoy today, with the leadership of the project being based on the CODEOWNERS file.

I am all in favor of the community roles concept and there are some bits that could use clarification, but perhaps we can work with someone who specializes in this sort of thing on smaller issues on a per-change basis? That way there's less to argue about and we can focus on one thing at a time until all parties are happy?

I get the sentiment here and what this is trying to prevent, but our failure was not applying existing rules rather than those rules never being there in the first place.

A maintainer of a project should be allowed to force push or even commercialize a project, so long as they have consensus. The problem was people doing that outside the model, or worse, by bullying to get their way. CoC should have stepped in a year ago or more.

[chandeleer1698]

I think individual projects should have autonomy as they enjoy today, with the leadership of the project being based on the CODEOWNERS file.

I am all in favor of the community roles concept and there are some bits that could use clarification, but perhaps we can work with someone who specializes in this sort of thing on smaller issues on a per-change basis? That way there's less to argue about and we can focus on one thing at a time until all parties are happy?

I get the sentiment here and what this is trying to prevent, but our failure was not applying existing rules rather than those rules never being there in the first place.

A maintainer of a project should be allowed to force push or even commercialize a project, so long as they have consensus. The problem was people doing that outside the model, or worse, by bullying to get their way. CoC should have stepped in a year ago or more.

Can I propose us having an Ublue meeting to discuss governance or just setting up dedicated channel to communicate this. Im fine splitting up the member roles proposal from the rest of it. Since its the part no one is against.

Also my point with the force push thing, was intentionally doing stuff without consensus or making no attempts to even obtain it.