Universal Blue Project Governance

Contributing
1

Main Images

When people refer to Universal Blue or “uBlue” they will likely mean the base images. These are described as “OCI base images of Fedora with batteries included”. This means:

  • Daily, automatic ingestion of Fedora OSTree desktops.
    • Silverblue, Kinoite, Vauxite, Sericea, and others.
    • Note that these are unofficially built images, Fedora doesn’t expect to publish official images until release 41.
    • Images in the ublue-org should derive from these images and not be standalone.
    • Continuously built and delivered via an OCI container from a registry (currently ghcr.io).
    • Our goal is to build two currently supported versions of Fedora, the most recent and one previous version.
    • The images are tagged with specific version, a date, plus most recent is tagged latest and the previous version is tagged gts.
  • Focus on things that Fedora CANNOT ship:
    • Hardware enablement.
    • Non-free codecs aka. “a bunch of that RPMFusion stuff”.
    • Built-in Nvidia drivers.
  • Quality of Life Services:
    • Automatic Updates,
      • System set to auto stage updates,
      • Flatpaks set to auto update.
    • Additional udev rules for better controller support and 2FA keys.
  • The images are “Light Touch:”
    • They are intended to be close(ish) to Fedora.
      • In certain cases we may add packages that are in Fedora Workstation but not in Silverblue to offer a more consistent experience.
    • Exceptions to this may granted if multiple maintainers agree based on community feedback in an issue.
      • If an application is available as a Flatpak it will NOT be included.
      • If it works in a Distrobox: SHOULD NOT be included.
      • If it only works on the host AND is required for hardware functionality: SHOULD be included.
    • Kernel modules MUST NOT be included, they are added to ublue-os/akmods.
    • If it only works on the host AND IS NOT required for hardware functionality: MAY be included.

Universal Blue Toolkit

  • The actions and scripts we use to make the Universal Blue images should be designed for consumption by others so that they can make whatever they want.
  • Both the toolkit and the images are a work in progress; we’re kind of “building the bridge while we’re crossing the river,” so, we need volunteers here who are willing to experiment.
  • Special consideration for existing open source projects that consume Fedora:
    • We want to enable orgs like asus-linux, linux-surface, Framework laptops, etc. to end up on vanilla Fedora, we should act as an unofficial playground for them to prototype, and be flexible enough to want to work with us to just fix the stuff they need. I want to explicitly say “base off of us” if it gets people working computers. If it works, we act as an on ramp for Fedora.
    • We should help them enable their repos if they want to do custom images; don’t force them to come here and integrate, if they want to start on our images and then do their own thing, cool, whatever, just give people working computers — by now everyone knows the sustainable way is by working upstream.

Project Scope and Mission

3 Likes
3

Membership

This doc outlines the various responsibilities of contributor roles in Universal Blue.

This document is derived from Kubernetes.

New contributors

New contributors should be welcomed to the community by existing members,
helped with PR workflow, and directed to relevant documentation and communication channels.

This informal level is designed for drive-by contributors or those who might be
interested in participating in open source and using this project to learn how.

We encourage anyone to participate, and for those who wish to earn more responsibilities and begin their open source journey with us … apply within. Vegeta tests us all.

Fellow Guardians

Since Universal Blue is meant to be a toolkit, we strive to generate fun experiments.
Our example for this our collaboration with Cassidy James Blaede on GNOME Beyond, where Cassidy is given direct Approver role of that repository along with our maintainers.

We hope to continue this trend, in the hopes that it spreads the cloud native desktop pattern to as many projects that want to take advantage of it.

Members and Approvers

Established community members are expected to demonstrate their adherence to the
principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc., and technical and/or writing ability. Role-specific expectations, responsibilities, and requirements are enumerated below.

Needs of the Project

In places where the project has a strong need for expertise in an area that lacks contributors, Approvers may make exceptions to grant elevated review permissions to underserved areas of the project. This is determined by lazy concensus of at least three Approvers.

Member

Members are continuously active contributors in the community. They can have
issues and PRs assigned to them, and participate in GitHub teams. Members are expected to remain active contributors to the community. This role includes responsiblities that are defined as “Reviewers” in other cloud native projects.

Defined by: Inclusion in the Member team in the Universal Blue GitHub organization

  • Enabled two-factor authentication on their GitHub account
  • Have made multiple contributions to the project or community, enough to
    demonstrate an ongoing and long-term commitment to the project.
    Contributions may include, but is not limited to:
    • Authoring or reviewing PRs on GitHub, with at least one merged PR.
      NOTE: The PR(s) must demonstrate an ongoing and active commitment.
      A few examples include:
      • A single issue/PR that has taken several weeks of driving consensus
      • A larger number of smaller PRs over several weeks to months
      • A smaller number of complex or technical PRs that required working with
        community members to resolve an issue (e.g. regressions, bugs fixes etc)
    • Filing or commenting on issues on GitHub
    • Contributing to community discussions
    • Special consideration of established open source contributions
      • Distribution maintainer, CNCF Contributor, Apache, etc.
      • This one means a lot - it’s the life blood.
  • Have read the contributor guide
  • Actively contributing to 1 or more repositories.
  • Sponsored by 2 Approvers. Note the following requirements for sponsors:
    • Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating
      on issues, etc.
    • Sponsors must be reviewers or approvers in at least one repo in the organization.
  • [Open an issue][membership request] against the ublue-os/main repo
    • Ensure your sponsors are @mentioned on the issue
    • Complete every item on the checklist
    • Make sure that the list of contributions included is representative of your work on the project.
  • Have your sponsoring reviewers reply confirmation of sponsorship: +1
  • Once your sponsors have responded, your request will be reviewed by the Owners and acted upon. You have ascended.

Responsibilities and privileges

  • Proactively act when builds are failing
    • Internal project outages should be prioritized over external dependencies
    • If outage is complex ensure that the rest of the team is aware of your work by filing an issue
  • Responsive to issues and PRs assigned to them
  • Responsive to mentions of teams they are members of
  • Active owner of code they have contributed (unless ownership is explicitly transferred)
    • Code is well tested
    • Keeps the tree green
    • Addresses bugs or issues discovered after code is accepted
  • They can be assigned to issues and PRs, and people can ask members for reviews with a /cc @username.

Note: Members who frequently contribute code are expected to proactively
perform code reviews and work towards becoming a primary approver for the
reopository that they are active in.

Approver

Code approvers are able to both review and approve code contributions. While
code review is focused on code quality and correctness, approval is focused on
holistic acceptance of a contribution including: backwards / forwards
compatibility, subtle performance and correctness issues, alignment with upstream
features and plans, and in general are the drivers of the project.

Defined by: Inclusion in the Approver team in the Universal Blue GitHub organization

Requirements

  • Member for at least 3 months
  • Primary reviewer for at least 5 PRs to the codebase
  • Reviewed or merged at least 20 substantial PRs to the codebase
  • Demonstrate sound technical judgement
  • Responsible for project quality control via code reviews
    • With a focus on long term sustainability to the project
  • Expected to be responsive to review requests as per [community expectations]
  • Mentor new contributors and members
  • Deep understanding of our working relationship with Fedora and other upstreams
    • Is invested in keeping track of upstream issues that affect our repositories
    • Is comfortable reporting and testing issues upstream

Responsibilities and privileges

  • Approver status may be a precondition to accepting large code contributions
  • Demonstrate sound technical judgement
    • Is actively monitoring upstream projects and participating accordingly as good open source citizens.
    • This may include rejecting ideas in order to maintain project scope
  • Responsible for project quality control via code reviews
  • Expected to be responsive to review requests as per [community expectations]
  • Mentor new contributors and reviewers

Inactive members

Members are continuously active contributors in the community.

A core principle in maintaining a healthy community is encouraging active
participation. It is inevitable that people’s focuses will change over time and
they are not expected to be actively contributing forever.

However, being a member of one of the Universal Blue GitHub organizations comes with an elevated set of permissions. These capabilities should not be used by those
that are not familiar with the current state of the project.

Therefore members with an extended period away from the project with no activity
will be removed from the Universal Blue GitHub Organizations and will be required to
go through the org membership process again after re-familiarizing themselves
with the current state.

How inactivity is measured

Inactive members are defined as members of one of the Universal Blue Organizations
with no contributions across any organization over the past 6 months. This is
measured by GitHub activity.

After an extended period away from the project with no activity those members would need to re-familiarize themselves with the current state before being able to contribute effectively.

Owner

Jorge Castro (@castrojo) and Marco Ceppi (@ceppimarco) are in the owner group for a few reasons:

  • Administrative things like billing info, and later on taxes and stuff.
  • Distributed ownership is hard thing for a small open source project
    • Therefore are codified as as adminstrative owners, not a community leadership group
    • Are just Approvers that get stuck with the cloud bill

Defined by: Inclusion in the Owners team in the Universal Blue GitHub organization

1 Like
4

Community Values

Derived from the Kubernetes Community Values but with a more hometown feel:

Distribution is better than centralization

Distributed asynchronous ownership, collaboration, communication and decision making.

Automation over process

We value time spent automating repetitive work more highly than toil.

Inclusive is better than exclusive

Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Our community respects the time and effort put into a discussion.

Evolution is better than stagnation

Openness to new ideas and studied technological evolution make us a stronger project.

Transparency

We endeavour to utilize the latest in open-source technology (like sigstore) to ensure our users can verify the processes used to build these images.

… and we can’t have all that without the quote:

“Culture eats strategy for breakfast.” --Peter Drucker

1 Like