SLO: combine MIR and security better

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Author: cpaelzer

README.md

@@ -1211,19 +1211,30 @@ we can do two things:
 1. List all distinct binary packages that should be promoted.  Often a source package will have binary packages that aren't actually needed in main.  Things like `-doc`, `-autopilot` or `-dbgsym`.  These can stay in universe, and it is a kindness to list only the packages we need for the archive team member that does the promotion.
 1. Recommend the owning team to add their corresponding team bug subscriber during the MIR process.
 
-## MIR Review - service level objective
+# Constraints and Service Level Objectives
 
-MIR reviews take time, scaling up with the complexity of the case. Sadly it is usually
-the very complex, very special cases that come in very late then are not happy with the
-velocity of review.
+Reviews take time, scaling up with the complexity of the case. Sadly it is usually
+the very complex, very special cases that tend to come in very late then be unhappy
+with the velocity of the review.
+For transparency and to manage expectations we hereby defined the service level
+objectives we defined for this process.
+
+Furthermore to be clear - you can help!
+You know in advance what we will check.
+History shows that a well prepared case will pass through more quickly in each
+phase. By truly caring about tests, quality, warnings and the many other things
+we check for you can help efficiency. So please take all the statements we ask
+for serious and try to fulfill them.
+
+## MIR Review SLO
 
 While we aim for more when possible, our goal is to assign (in the weekly meeting)
-one review per active MIR member per week, and coming back with the result until
-the next meeting or earlier. That usually means we can handle ~4 cases per week,
+one review per active MIR member per week, and coming back with the result before
+the next meeting. On average that means we can handle ~4 cases per week,
 sometimes more (if we can make the space or they are trivial) and sometimes
 less (PTO times).
 
-So far this used to be always enough and allowed <week responses for almost
+So far this used to be always enough and allowed < 1 week responses for almost
 all cases for several years now. Except in spikes of everyone dumping huge
 changes last minute right before feature freeze. Try to avoid that phase
 to help yourself getting a timely review.
@@ -1232,17 +1243,27 @@ The above of course is for the initial review, if everything is fine and no
 security review needed that is it and you are done. But findings have to be
 answered or fixed and if needed a security review has to be exercised. The time
 for this depends on the complexity of the findings and remember that there have
-been cases as bad as being rejected forcing the requester to look for
+been cases as bad as being rejected, forcing the requester to look for
 alternative solutions.
 Please consider this in your estimations when you plan a contribution.
 
-## Security Reviews
+## Security Review SLO
 
-Security team MIRs are laborious and require lead time. Make MIR requests as early in a release cycle as possible, ideally well before Feature Freeze. For a MIR to be considered for a release, it must be assigned to the Security team (by the MIR team) before Beta Freeze. This does not guarantee that a security review can be completed by Final Release. Ask the director of Security for exceptions.
+Security team MIRs are laborious and require lead time. Make MIR requests as
+early in a release cycle as possible, ideally well before Feature Freeze. For
+a MIR to be considered for a release, it must be assigned to the Security
+team (by the MIR team) before Beta Freeze. This does not guarantee that a
+security review can be completed by Final Release. Ask the director of
+Security for exceptions.
 
-The best ways to contact the Security team about MIRs is the [MIR / Audits Jira Page](https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594) or through the Mattermost channels `~mir-security-review-priority` or `~security-engineering`.
+The best ways to contact the Security team about MIRs is the
+[MIR / Audits Jira Page](https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594)
+or through the Mattermost channels `~mir-security-review-priority` or `~security-engineering`.
 
-Teams are encouraged to set the relative importance of MIRs they own on the [MIR / Audits Jira Page](https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594). Security attempts to work across and prioritize all teams equally. Jira priority drives the order we work on MIRs.
+Teams are encouraged to set the relative importance of MIRs they own on the
+[MIR / Audits Jira Page](https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594).
+Security attempts to work across and prioritize all teams equally.
+Jira priority drives the order we work on MIRs.
 
 ## Bug Lists