Restructure support.html
How to report a bug and request a new feature, is more vital information
than how long it may take to get it fixed and who potentially might fix
it.
Therefore move the "Bugs", "New Features" and "Bug Triaging"
sections to above "Response time and SLO".
Change-Id: Ibefaa9a26a11cd96019c9e5ff28862f9bbbbc749
diff --git a/pages/site/support.md b/pages/site/support.md
index 98a1c9b..33c07eb 100644
--- a/pages/site/support.md
+++ b/pages/site/support.md
@@ -73,6 +73,52 @@
You could also check the questions tagged with "gerrit" on
[Stack Overflow][stack-overflow].
+## Bugs
+
+If the issue/question you posted on Repo Discuss is considered a bug
+the community will ask you to create an issue for tracking it.
+Bugs are reported to the [issue tracker][issue-tracking].
+The issue tracker is not always the best place to initially request
+new features, as the main focus for those consuming it is fixing
+bugs.
+
+## New Features
+
+The Gerrit project has adopted a
+[feature request model][feature-request] where you are asked to
+submit your feature request together with some valid, general,
+use-cases.
+
+## Bug Triaging
+
+All incoming issues should be triaged to decide on their
+[priority](#priorities). The priority should be based on the severity, the
+frequency and the risk of the issue.
+
+Besides finding the right priority we also aim to clarify the issue so it is
+well understandable what the problem is.
+
+The triage is not meant to investigate the cause of bugs or assign issues.
+
+Triaging should include the following steps:
+
+1. Determine the right [priority](#priorities).
+2. Mark feature requests as `Type-Feature`.
+3. Check that the component is correctly set, and update it if necessary.
+4. If necessary, update the issue summary to be clear.
+5. Set label `Security` if it's a security or privacy issue.
+6. Close incomplete issues as `Incomplete`.
+7. Close spam issues as `Invalid`, flag them as spam and then delete them.
+8. Check if the issue has been reported before and close it as `Duplicate` if
+ possible.
+9. Check if reproduction steps are present and clear. If not, ask the reporter
+ to provide them and set the status to `AwaitingInformation`.
+10. Set the status to `Accepted` and add the label `Triaged-Yes` when the
+ triaging is done.
+
+Triaging incoming issues is a community effort and is done on a best effort
+basis (also see [below](#response-time-and-slo)).
+
## Response time and [SLO](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/)
Gerrit Code Review is an open-source project, which means that the people
@@ -199,52 +245,6 @@
The support for plugins follows the same [CS](#community-support) and [ES](#enterprise-support)
policies adopted for Gerrit Code Review.
-## Bugs
-
-If the issue/question you posted on Repo Discuss is considered a bug
-the community will ask you to create an issue for tracking it.
-Bugs are reported to the [issue tracker][issue-tracking].
-The issue tracker is not always the best place to initially request
-new features, as the main focus for those consuming it is fixing
-bugs.
-
-## New Features
-
-The Gerrit project has adopted a
-[feature request model][feature-request] where you are asked to
-submit your feature request together with some valid, general,
-use-cases.
-
-## Bug Triaging
-
-All incoming issues should be triaged to decide on their
-[priority](#priorities). The priority should be based on the severity, the
-frequency and the risk of the issue.
-
-Besides finding the right priority we also aim to clarify the issue so it is
-well understandable what the problem is.
-
-The triage is not meant to investigate the cause of bugs or assign issues.
-
-Triaging should include the following steps:
-
-1. Determine the right [priority](#priorities).
-2. Mark feature requests as `Type-Feature`.
-3. Check that the component is correctly set, and update it if necessary.
-4. If necessary, update the issue summary to be clear.
-5. Set label `Security` if it's a security or privacy issue.
-6. Close incomplete issues as `Incomplete`.
-7. Close spam issues as `Invalid`, flag them as spam and then delete them.
-8. Check if the issue has been reported before and close it as `Duplicate` if
- possible.
-9. Check if reproduction steps are present and clear. If not, ask the reporter
- to provide them and set the status to `AwaitingInformation`.
-10. Set the status to `Accepted` and add the label `Triaged-Yes` when the
- triaging is done.
-
-Triaging incoming issues is a community effort and is done on a best effort
-basis (also see [above](#response-time-and-slo)).
-
[feature-request]: https://gerrit-review.googlesource.com/Documentation/dev-design-docs.html#propose
[issue-tracking]: /issues.html
[repo-discuss]: https://groups.google.com/forum/#!forum/repo-discuss
