CPE Infrastructure Projects

Summary

The purpose of this document is to unify Community Platform Engineering (CPE) Infrastructure Projects and general Fedora Community Initiatives into a single, prioritized living list that can be worked on by community members (which includes CPE). This list is to be prioritised by FESCo, who will make decisions as the technical leadership group of the Fedora Project. This process is a living process and may be modified.

If ratified, this process should live in a SCM repository (Example: FESCo docs repo) for easy forking, editing, and submitting of changes (see Changing The Process).

tl;dr Version

The purpose of this process is to bring proposed project work to a single entity for prioritization. The prioritization would be made public via an ordered list and anyone in the community (which includes the CPE team) could choose to take an item on. This list is not a “must do” list for anyone, but instead signals the highest value/impact work for the greater Fedora community in a central and clear living document.

The proposed process is meant to provide a way for FESCo and CPE to work together efficiently with clear steps and ownership at each point without doubling workload. This is just a proposal and we are open to adding or removing steps/areas/etc.. to best fit the need.

Short Version of the Prioritized List Process

Someone proposes a project for prioritization
One or more community members help refine the proposal in discourse
CPE PO takes it to FESCo
FESCo decides if it goes on the list or not, as well as what it’s priority on the list should be
CPE PO updates and publishes the list

Goals

Have a central prioritized list of project/initiative work for all interested people
Have said list be prioritized by FESCo
Have said list be updated and published by the CPE PO
Encourage an increase in community members (CPE included) working together towards common goals that benefit the Fedora Project
Increase the visibility of high impact contribution opportunities as well as the visibility when said contribution is finished

Anti-Goals

A central list of work the community (including CPE) must do
Disincentivize anyone from working on what they believe is the best set of work they can produce for/with the community (IE: If it’s not on the list then it shouldn’t be done)
Add undue process hoops for community members

Detailed Description

This document defines a lightweight process that:

Moves CPE Infrastructure Projects and similar community requests in to one entry point
Introduces an Infrastructure Projects List which is a public, ordered, prioritized, and limited list
All persons and groups continue to retain their agency in choosing what they will focus on including projects and ideas outside of the Infrastructure Projects List
FESCo would set the priority of all accepted Infrastructure Projects
The CPE Product Owner (PO) will update and publish the list
The list acts as a public acknowledgement of the highest priority Infrastructure Projects that FESCo sees as beneficial to the community through the input of the community
Submitting an Infrastructure Project does not require those who submitted to own or work on the Infrastructure Project
This is a living process and may be modified as needed in the future
This process may be nullified if there is an impasse

Infrastructure Projects List

The Infrastructure Projects List is a public, ordered, prioritized and limited list that shows the highest priority Infrastructure Projects seen as most beneficial to the community as decided by FESCo.

Public

The list is always public and available at an agreed upon space at fedoraproject.org. It is recommended to send out changes periodically through the mechanism that FESCo/CPE PO uses and sees fit.

Ordered

The list is ordered as such:

Order starts with 0
Numbers increase by 1
Numbers do not get skipped
Numbers that are empty may be left off the list until filled
There is a 1:1 relationship between a number and an Infrastructure Project. A number can not house multiple Infrastructure Projects.

Prioritized

Before any Infrastructure Projects may be put on the list, it must be prioritized by FESCo.

Given that there is a 1:1 relationship between the priority number and an Infrastructure Project, there can not be 2 or more Infrastructure Projects to a single number.
The lower the number, the higher the priority. For example 3 is a higher priority then 5.
When a new Infrastructure Project is chosen for a priority and that priority number is currently filled, it shifts 1 down in priority as does every other Infrastructure Project under it.

Limited

Like backlogs, a list of priorities can easily grow towards infinity. To help keep people focused on the most impactful and helpful Infrastructure Projects, the Infrastructure Projects List is limited to a maximum number. This number should be large enough that it can house the highest priority items but small enough that it doesn’t overwhelm individuals or dilute the importance of priority. Using 0-5 as the scale is a recommended starting point, but can be changed by FESCo if needed.

Proposed Process Flow

A community member, or members, submit a proposal through the creation of a dedicated thread on Discourse specifically designated for discussions under the topic "Infrastructure Projects." The topic is public and anyone with an account can create an Infrastructure Projects request.
Community members, including CPE, continuously review the Infrastructure Projects Issue topic, discuss with requestor(s) if anything is unclear, and help refine if time allows. The goal is to ensure FESCo gets Infrastructure Project requests which are ready to accept/reject.
CPE Product Owner (PO) takes the Infrastructure Projects request(s) to FESCo for review.
1. If an Infrastructure Project request is rejected from the list, a reason will be provided by FESCo and submitted by the CPE PO to the original Infrastructure Project thread. Not prioritizing on the list is effectively a rejection.
2. If an Infrastructure Project request is accepted, it is then prioritized by FESCo and placed in the public Infrastructure Projects List.
The updated Infrastructure Projects List is published by the CPE PO.
Anyone can work on items in the public Infrastructure Projects List.

Visualisation

Example

All names in this example are fictitious. Any resemblance to real people would be coincidental.

Kate, a member of the Fedora community has an idea that she believes will increase the security of Fedora releases and updates. She logs into her Fedora account and creates a post in the Infrastructure Projects topic on discourse using a provided template as a guide.
Roberto, a CPE member, sees the request in the Infrastructure Projects topic. Knowing he’s on point to watch the topic, he reviews the request and asks some clarifying questions.
Together Roberto, Kate, and others discuss and refine the proposal. Roberto also lets the CPE PO know that an Infrastructure Project request has come in which can be taken to FESCo for review at the next meeting.
Jing, the CPE PO, takes the Infrastructure Project request to the next FESCo meeting for review.
In the FESCo meeting the group decides the request would be a great Infrastructure Project for Fedora and places it on the list at number 3 out of 10 items.
Because the Infrastructure Projects List had an Infrastructure Project in slot 3 it, and all lower priority items on the list, moved down in priority by 1.
Because the Infrastructure Projects List was not full, nothing had to be removed.
Jing denotes on the original request that the Infrastructure Project was approved, updates the Infrastructure Projects List, and publishes it publicly.
After some amount of time, 5 community members (2 of them CPE members) decide to work on the Infrastructure Project, denote they are taking the work on, and collaborate.
The virtual team forms and work begins.

Maintenance Considerations

CPE is able to maintain a finite amount of services and infrastructure, which is why CPE first pre-reviews all Infrastructure Project requests before sending them to FESCo for prioritization. The following are the guidelines used to determine if CPE will be able to take on new infrastructure or services.

To ensure SLEs, truly critical services and infrastructure must be maintained by CPE. Here is a list of the current services noted as critical. NOTE: This does not mean CPE must be the only maintainers of the infrastructure.
As capacity allows CPE can maintain services and infrastructure that fits in its preferred technology stack.
CPE may provide exceptions if a service/infra must be done outside of the documented preferred technology stack if said service/infra is important or critical.

Changing the Process

This is a living process which may be modified as needed. This section provides a step by step process for open and transparent modifications.

The SCM repo housing the policy is forked or branched
Changes are made to the forked or branched version of the policy
An MR/PR is opened up against the original SCM repo default branch housing the policy for discussion
The person(s) proposing the change lets the community know through a devel@ mailing list post requesting review by FESCo.
FESCo and CPE’s Product Owner give their approval or rejection notice as a comment in the MR/PR. If all parties approve, the change is merged and immediately takes effect.
If 30 calendar days go by (starting the day after the MR/PR is created) without approval the changes are automatically rejected.

Process Nullification

If at any time the process becomes overly burdensome, problematic, etc.. and either FESCo (as a group) or the CPE team are unable to agree on a path forward; this process will cease enforcement with the expectation that one or more processes will be created in its stead.

In order to nullify a process, one of the two stakeholder groups (i.e. FESCo or CPE) must formally request process nullification. Before drafting a request for nullification the stakeholder group must have majority agreement to nullify. No single individual nor sub group of the stakeholder groups may unilaterally enact process nullification. A notification requesting process nullification must be sent to the devel@ mailing list. The existing process is deemed null and void upon the creation of a first draft of a new process, which must then be negotiated and approved by both stakeholder groups.

Appendix

Definitions

Infrastructure Project Proposal: A structured request describing a set of work that will end with an expected outcome.
Infrastructure Project Template: Template used to collect the minimum amount of required information to discuss an Infrastructure Project.
Discourse: The fedora official discourse instance at https://discussion.fedoraproject.org/
Infrastructure Projects List: Numerically limited set of accepted Infrastructure Projects in priority order where the lower the number the higher the priority.
FESCo: FESCo is the Fedora Engineering Steering Committee. It is a fully community elected body and represents the technical leadership in Fedora. (Source)
CPE: The Community Platform Engineering Team (CPE) is a Red Hat team dedicated to the Fedora and CentOS projects where they contribute to the infrastructure and release engineering. (Source)
Service/Infrastructure Priority: The importance of the service/infra to the community’s continued success.

Caption text
Priority Name	Description	Examples
Critical	Without these everything stops	Koji, Bodhi, Noggin
Important	Functions in the community are degraded without these	Fedora Messaging, rpmautospec, Copr, Status
Moderate	Helpful services but their downtime doesn’t stop community movement	Badges, Planet
Low/Nice to Have	Everything else	Ask, Nuancier

Search