Glossary

This document explains some of the terminology used by the team.

Pain vs Gain

When evaluating tickets during the stand ups, the team evaluates the pain vs gain of the task asked. These estimates can then be used to prioritize work ( low pain, high gain would be the first one considered and high pain, low gain the last).

Here is an idea of what each level corresponds to:

Low trouble: easyfix that we know how to do, is documented and doesn’t take more than a few minutes.
Medium trouble: something that is (or sounds) doable, requires a little investigation work but should not take too long (done in a day max).
High trouble: something that we have never done before and will require some investigation work and impact analysis before we can get started on it or something we know but will take more than a day to do properly.
Low gain: we have done without fine until now, it impacts very few people and has a work around available.
Medium gain: there is a work around available but it impacts quite a number of people.
High gain: is a supported use-case, impacts a lot of people, there is no work around available.

Dev vs Ops

When evaluating tickets during the stand ups, the team also evalutes if the ticket requires a developper to be involved or not. The result of this evaluation is captured by the dev or ops tags that are set to the ticket. They also allow to add the ticket to the respective boards which the team uses to coordinate work.

dev: requires development work (a script/ansible to be written) or non-straight forward debugging work.
ops: it related to configuring an app or running an existing script to change a behaviour or requires a little debugging to figure what is going on before it can be assessed as requiring a code fix or a config fix.

Priorities

We are actually mis-using the priority field to reflect the status of the ticket.

Needs Review: This is the default status set on the ticket when it is opened. These tickets are meant to be reviewed during the stand up.
🔥 URGENT 🔥: World is on fire, if we have set the ticket to that status, you can assume we’re working on it and you can subscribe to the ticket to get updates, please do not ping us so we can focus on it.
Next Meeting: This marks tickets that needs to be discussed within the team during our weekly team meeting on irc.libera.chat.
Waiting on Assignee: This marks tickets that have been triaged and are either waiting on someone to pick them up or waiting on the assignee to work/finish them.
Waiting on Reporter: This marks tickets in which a question was asked to the reporter whose answer is needed to progress the ticket.
Waiting on External: This marks tickets that are blocked waiting on something or someone outside of the team.

Application categories

The Fedora Infrastructure runs a fairly larged number of applications. CLE runs most of them and maintain (as in maintain the code base, writing code and patches) quite a few of them. However, not all applications will get the same level of attention from CLE. So they have been categorized into two maintenance status and two maintenance level.

Each appliction can then be categorized using these, for example:

bodhi is: CLE run and maintain - Critical path
koji is: CLE run and don’t maintain (type a) - Critical path
waiverdb is: CLE run and don’t maintain (type b) - Critical path
simple-koji-ci is: CLE run and don’t maintain (type b) - Not critical path

Maintenance status

CLE run and maintain

these are the applications that we run and for which the team is responsible for the code base. We lead the project upstream and run it in the infrastructure. If something break, we will look at it and if that requires patching we will do it.

CLE run and don’t maintain

these are applications that are running in the infrastructure but for which we do not write the code base. There are two types of applications in this sections:

a) applications that for which we look after the deployment
b) applications for which other people look after the deployment, in which case our work can be described as providing "power and pings", in other words, providing power and network. If something goes wrong, we will try to restart the service and if the service doesn’t recove, we will contact the maintainers of the application.

Maintenance level

Critical path: these are applications that are needed to build or ship one of our deliverables to our users.
Not critical path: these are applications that while important for the community will not impact the production or delivery of the project’s artifacts.

Want to help? Learn how to contribute to Fedora Docs ›