diff --git a/docs/bug-triage-prioritize.svg b/docs/bug-triage-prioritize.svg
new file mode 100644
index 0000000000..5649051dbb
--- /dev/null
+++ b/docs/bug-triage-prioritize.svg
@@ -0,0 +1,639 @@
+
+
+
+
diff --git a/docs/bug-triage-verify.svg b/docs/bug-triage-verify.svg
new file mode 100644
index 0000000000..243c03f43d
--- /dev/null
+++ b/docs/bug-triage-verify.svg
@@ -0,0 +1,539 @@
+
+
+
+
diff --git a/docs/bug-triage.md b/docs/bug-triage.md
new file mode 100644
index 0000000000..360ab60602
--- /dev/null
+++ b/docs/bug-triage.md
@@ -0,0 +1,93 @@
+# Bug triage process
+
+## Actions
+
+When triaging a bug in most cases there is a single action required. Actions can be
+executed on an GitHub Issue either by adding the label `action-` or
+adding `~` as the last line of the comment.
+
+For example if an issue is missing information you could comment:
+
+```
+There is not enough information here, and I'm not following the steps-to-reproduce.
+
+~missing-info
+```
+
+You could also for example just add the label `action/priority-regression` to an issue.
+
+## Triaging bugs
+
+### Verify the issue
+
+The first step is to verify if the issue is a valid issue following these questions:
+
+![Bug triaging - Verify!](bug-triage-verify.svg "Bug Triage - Verify")
+
+If an issue is not valid add a comment with some explanation, and add `~` as the last line of the comment
+to trigger corresponding action.
+
+In cases where it is clear that no additional comment is needed you can just add the `action/` label. For
+example if the description only states `It doesn't work` then there's not much point in explaining what information is
+missing.
+
+### Prioritize the issue
+
+Second step is to prioritize the bug depending on how common the use-case is, if it's a regression,
+or not blocking anything, for example a typo:
+
+![Bug triaging - Prioritize!](bug-triage-prioritize.svg "Bug Triage - Prioritize")
+
+When selecting the priority for an issue add the `action-` label to the issue.
+
+
+## Missing information
+
+Bugs with insufficient information are assigned the labels `status/missing-info` and `status/auto-expire`, and the
+`status/triage` label is removed.
+
+If the original reporter provides additional information the issue is automatically move back to triage by re-adding
+the `status/triage` label. Otherwise, if the reporter does not provide additional information within 14 days the issue
+is automatically closed.
+
+This effectively means that teams do not actively have to look at issues with missing information, since the issue
+will be moved back to their triage backlog of more information is provided.
+
+To prevent an issue with missing information to be automatically closed, remove the `status/auto-expire` label.
+
+
+## Low and normal priority issues
+
+In most cases these are not issues we will fix, and we will look for contributions (by adding the `help wanted` label)
+to resolve them. As such the team does not actively monitor issues with these priorities.
+
+The bot will automatically bump the priority based on reactions added to the issue description:
+
+* Low priority bumped to normal if there are 10 or more reactions
+* Normal priority bumped to important if there are 20 or more reactions
+
+To prevent an issue from being automatically bumped, remove the `status/auto-bump` label.
+
+If there are no updates to low or normal priority issues they will be automatically closed:
+
+* Low priority are closed after 90 days
+* Normal priority are closed after 180 days
+
+To prevent an issue from being automatically closed, remove the `status/auto-expire` label.
+
+
+## Changing priority
+
+To change the priority of an issue that has already been triaged simply add the new priority label.
+The bot will take care of removing the existing priority label. It will also remove auto bumping and auto expiration
+for the issue if the priority is set to important or blocker.
+
+The priority for an issue is also bumped to important if the `team/rh-iam` label is added.
+
+
+## Backporting
+
+When triaging or fixing an issue consider if the fix should be backported. If it should be backported add the
+corresponding `backport/` label.
+
+For convenience, use the `.github/scripts/pr-backport.sh` to help create the backport PRs.
\ No newline at end of file