Outcome of the CPE's team's face-to-face

You may remember that we recently spoke about the Community Platform Engineering (CPE) team and the problem it is facing — our workload is growing faster than the team can scale to meet it. From June 10th to June 14th most of the CPE team members met face to face in the Red Hat office in Waterford (Ireland)

We had a great week of meetings together with well balanced socializing times. We had a few outcomes from this meeting:

A mission statement
Agreements about lowering our workload with some candidate applications
Agreements about our new workflow

Mission Statement

One of the main results of this meeting is the agreement on a team’s mission statement:

The Community Platform Engineering Team is responsible for the infrastructure and services that support developing, building, and releasing of Fedora and CentOS platform artifacts and deliverables, including:
* Hosting, automating, monitoring and maintaining infrastructure components
* Service monitoring and lifecycle management of services hosted within our infrastructure
* Feature development for infrastructure-related initiatives
* Tooling to enable all of the above

Now you may wonder what having a mission statement means. It means the team shares a common vision about what our work is or should be. It gives us clear boundaries for our work and it helps us having a critical view on our work (current or coming): “Does this fit our mission statement?”. With this in mind we can focus on bringing more value to the community. In other words, we want to maximize our value and impact in a targeted mission rather than having limited impact on a broad spectrum.

It also means, requests coming to us that do not fit this mission statement may be turned down. There will be a few cases where we will accept work that does not perfectly fit this vision but it will be more the exception than the norm.

Lowering the workload

All the members of the team have agreed that the number of services we are maintaining and running is too high and we need to reduce them. For a couple of months, before the meeting, we looked at the list of these services and wonder how to sort them. Finally, we have come up with four tiers for all of our services:

We maintain the code, we run the application
We do not maintain the code, we run the application
We do not maintain the code, we do not run the application, we provide the hosting for someone to run it
The application is no longer run

We do not have a comprehensive list of which applications will fall into which category. This is a decision that will be made in coordination with the Fedora Council. We will reach out to the Fedora Council to present our decision and validate it before sharing it with the broader community, but we expect to hand over some applications to any community member who would like to maintain them in the coming months.

We will announce this in multiple places (including in this blog) and give sufficient lead time for someone to step up. To be clear, we are not going to just abandon applications. We know that many of these are important to Fedora and want to help community members adopt them. Part of this will include porting to python3, fedora-messaging, openid-connect and moving to an openshift instance allowing any community members to manage their applications.

Requesting new work

Finally, we are also working on documenting the new workflow we want to put in place. For example, one of the documents we are currently working on is a “How to work with us”. This document will describe what we need from you in your requests (spoiler: it will involve tickets!). This work is still very much in progress though and we will announce in a follow-up blog post once we have agreed on a first version.