Add rules to re-evaluate very old renames

README.md

@@ -124,6 +124,50 @@ Starting in 20.04, Ubuntu Desktop ISOs will support installing hardware specific
 
 See [exceptions/OEM.md](exceptions/OEM.md).
 
+## Re-Reviews
+
+Historically if something was in main once there was no re-evaluation done
+later unless if teams asked for it based on huge changes. Doing regular
+re-evaluations on all packages would be a nice, but also rather huge effort.
+
+We want to be pragmatic, therefore:
+- All we identify shall be recommended tasks (not required to continue) unless we find something really intolerable.
+- We'd appreciate if the owning team could file a MIR-reporter bug for it, but would not insist on it if they can't. In that case we create a stub for it.
+
+The benefit of this is, that the stricter rules that we have today (added for
+good reasons usually triggered by painful lessons learned no one wants to
+repeat), will be considered and thereby might create useful suggestions for
+components that are central to Ubuntu, its quality and maintainability.
+
+We'd create a MIR bug if there was none. But if there was a bug already
+we'd want to keep the context together and avoid flooding launchpad with
+multiple MIR bugs for a single package. Therefore in this case, just
+as we do when we retroactively promote in an SRU we'd add per-series bug tasks
+to show the state of each review independently.
+If source renames are involved those can be tracked the same way all associated
+to one bug.
+
+### Renamed or Reorganized sources
+
+We can use some regular events to start with re-reviews at a small scale,
+and that is when things pop up on our radar anyway.
+
+In the past, if a source was already in main, but then appeared in a different
+form - common cases that come to mind are renames or code split out - have
+gotten a fast-path approval based on being in main already.
+
+But from now on, for packages old enough to not have any audit-trail via a MIR
+bug, we want to do a re-evaluation when they show up as component mismatch.
+
+### opt-in re-review
+
+For special cases (read: do not dump hundreds of requests to the MIR team at
+once) teams can also request a re-review. That might even be worthwhile if
+there already is a former MIR bug - for example if the project was rewritten in
+another language all former assumptions might be invalid anyway.
+
+For that a team should contact the MIR team directly in the MIR team meeting.
+
 # Filing a MIR bug
 
 The steps of the MIR process require a reporter (the one who wants a