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
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.
requires development work (a script/ansible to be written) or non-straight forward debugging work.
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.
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.
The Fedora Infrastructure runs a fairly larged number of applications. CPE 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 CPE. 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: CPE run and maintain - Critical path
koji is: CPE run and don’t maintain (type a) - Critical path
waiverdb is: CPE run and don’t maintain (type b) - Critical path
simple-koji-ci is: CPE run and don’t maintain (type b) - Not critical path
- CPE 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.
- CPE 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.
Want to help? Learn how to contribute to Fedora Docs ›