cle/docs
36
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Add a glossary page

Browse source 
With definitions of the different terms we use in our triage process.

Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
This commit is contained in:
Pierre-YvesChibon 2020-09-18 11:03:01 +02:00
commit 9342416f31
2 changed files with 69 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
modules/ROOT/nav.adoc
View file

@ -3,6 +3,7 @@
** xref:day_to_day_centos.adoc[Day to day in CentOS]
** xref:initiatives.adoc[Initiatives]
*** xref:time_tables.adoc[Time tables]
** xref:glossary.adoc[Glossary]
** xref:sle.adoc[SLE]
*** xref:sle_services.adoc[Services]
* xref:about.adoc[About the Team]

68
modules/ROOT/pages/glossary.adoc Normal file
View file

@ -0,0 +1,68 @@
:experimental:
= 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/freenode.
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.