2021-12-07 16:50:08 +01:00
|
|
|
= How to handle new tickets in fedora-infrastructure
|
|
|
|
|
|
|
|
This SOP describes the process of handling incoming tickets on
|
|
|
|
https://pagure.io/fedora-infrastructure.
|
|
|
|
|
|
|
|
== Contact Information
|
|
|
|
|
|
|
|
Owner::
|
|
|
|
Fedora Infrastructure Team
|
|
|
|
Contact::
|
|
|
|
#fedora-admin, #fedora-noc
|
|
|
|
Location::
|
|
|
|
https://pagure.io/fedora-infrastructure
|
|
|
|
Purpose::
|
|
|
|
Fedora infra ticket tracker
|
|
|
|
|
|
|
|
|
|
|
|
== Ticket workflow for standard tickets
|
|
|
|
|
|
|
|
This ticket workflow is applied to any ticket Infra Team finds in tracker and it's related to
|
|
|
|
issue that really falls under Fedora Infra Team umbrella. This will be evaluated by the Infra
|
|
|
|
Team itself, but everything related to apps Fedora Infra Team maintains automatically falls
|
|
|
|
in this category.
|
|
|
|
|
|
|
|
. Identifying new tickets
|
|
|
|
+
|
|
|
|
The tracker is being checked by the Fedora Infrastructure Team twice per day from Monday to
|
|
|
|
Thursday. The new tickets can be recognized by not having any label and are in priority
|
|
|
|
*Needs Review*.
|
|
|
|
|
|
|
|
. Adding labels to tickets
|
|
|
|
+
|
|
|
|
____
|
|
|
|
The team will look at each ticket and evaluate the trouble and gain this ticket
|
|
|
|
represents.
|
|
|
|
|
|
|
|
Gain could be:
|
|
|
|
|
|
|
|
* *low*
|
|
|
|
+
|
|
|
|
Affects only few users
|
|
|
|
|
|
|
|
* *medium*
|
|
|
|
+
|
|
|
|
Affects some of the Fedora users
|
|
|
|
|
|
|
|
* *high*
|
|
|
|
+
|
|
|
|
Affects most of the community
|
|
|
|
|
|
|
|
Trouble could be:
|
|
|
|
|
|
|
|
* *low*
|
|
|
|
+
|
|
|
|
Will take less than a day
|
|
|
|
|
|
|
|
* *medium*
|
|
|
|
+
|
|
|
|
Will take less than a week
|
|
|
|
|
|
|
|
* *high*
|
|
|
|
+
|
|
|
|
Infra team is not sure how much time this will take or it takes more than one week
|
|
|
|
|
|
|
|
There are also two additional types of tickets *ops* (needs sysadmin attention) and *dev*
|
|
|
|
(needs developer attention).
|
|
|
|
|
|
|
|
If there are some things we need to clear with the reporter, we switch the ticket to
|
|
|
|
*Waiting for reporter* priority and wait for the reply before adding the trouble, gain, ops/dev
|
|
|
|
label.
|
|
|
|
____
|
|
|
|
|
|
|
|
. Assigning tickets
|
|
|
|
+
|
|
|
|
If the ticket has labels we can switch it to *Waiting on Assignee* or assign it, if there
|
|
|
|
is someone who wants to take it.
|
|
|
|
|
|
|
|
== Ticket workflow for apps we don't maintain
|
|
|
|
|
|
|
|
This ticket workflow is applied to any ticket Infra Team finds in tracker and it's related to
|
|
|
|
app that Fedora Infra doesn't maintain.
|
|
|
|
|
|
|
|
. Identifying new tickets
|
|
|
|
+
|
|
|
|
The tracker is being checked by the Fedora Infrastructure Team twice per day from Monday to
|
|
|
|
Thursday. The new tickets can be recognized by not having any label and are in priority
|
|
|
|
*Needs Review*.
|
|
|
|
|
|
|
|
. Find the maintainer
|
|
|
|
+
|
|
|
|
Look for the maintainer of this app.
|
|
|
|
|
|
|
|
* Maintainer is known
|
|
|
|
+
|
2021-12-13 12:46:29 +01:00
|
|
|
Ping it in the ticket or close the ticket and ask reporter to create it upstream (close it
|
|
|
|
with the reason *Upstream*). This depends on the project.
|
2021-12-07 16:50:08 +01:00
|
|
|
|
|
|
|
* Maintainer is not identified or not active
|
|
|
|
+
|
|
|
|
In this case new ticket should be created "<App> is without maintainer" and the following
|
|
|
|
should be done:
|
|
|
|
|
|
|
|
** Add your investigation outcome to ticket
|
|
|
|
+
|
|
|
|
Anything found out or known about the application should be added to this ticket.
|
|
|
|
|
|
|
|
** Short time outage (optional)
|
|
|
|
+
|
|
|
|
If there isn't clear if the application is used in infrastructure schedule a short outage
|
|
|
|
and see who will respond.
|
|
|
|
|
|
|
|
** Decide what to do with it
|
|
|
|
+
|
|
|
|
The app is without maintainer and the investigation revealed what is the purpose of this application.
|
|
|
|
There are now multiple options to choose from:
|
|
|
|
|
|
|
|
*** It's no longer useful
|
|
|
|
+
|
|
|
|
Shut it down and remove the ownership.
|
|
|
|
|
|
|
|
*** It's useful, but doesn't fit Fedora Infra mission
|
|
|
|
+
|
|
|
|
Put a 3 quarter timer for a shutdown
|
|
|
|
|
|
|
|
**** File a ticket with the appropriate board/council that the application has no owner and is a threat
|
|
|
|
to the stability of the project for reasons documented in the ticket. Let them know that you will need
|
|
|
|
to either remove/replace/get an owner for it. Give a 1 quarter deadline for guidance so they can come to a conclusion.
|
|
|
|
|
|
|
|
**** Put it in a quarterly planning cycle to do what is needed to shutdown it.
|
|
|
|
|
|
|
|
**** Use the last quarter to deal with any roadblocks (we could not replace it, we could not remove it,
|
|
|
|
we could not get an owner for it.)
|
|
|
|
|
|
|
|
*** It's something we need
|
|
|
|
+
|
|
|
|
Find POC in CPE team for it.
|
|
|
|
|
|
|
|
*** It's something that could be offloaded/migrated away from
|
|
|
|
+
|
|
|
|
In this case Fedora Infra should investigate the situation.
|
|
|
|
|
|
|
|
**** Add an investigation to https://pagure.io/fedora-infra/arc[ARC team board], prioritized by Product Owner
|
|
|
|
|
|
|
|
**** Figure out if it's an iniative, or a mini-initiative or just standard ticket
|
|
|
|
|
|
|
|
**** Schedule it, do it, drop our application
|
|
|
|
|
|
|
|
. Resolve the ticket
|
|
|
|
|
|
|
|
* Close it if the application is shut down
|
|
|
|
|
|
|
|
* Work on it if it's now Fedora Infra owner application
|
|
|
|
|
|
|
|
* Let the maintainer work on it and leave the resolution on them
|