docs: reorganize FAQ

Author: ldez

docs/src/docs/usage/faq.mdx

@@ -2,55 +2,22 @@
 title: FAQ
 ---
 
-## How do you add a custom linter?
-
-You can integrate it yourself, see this [manual](/contributing/new-linters/).
-Or you can create a [GitHub Issue](https://github.com/golangci/golangci-lint/issues/new) and we will integrate when time permits.
-
-## How to integrate `golangci-lint` into large project with thousands of issues
-
-We are sure that every project can easily integrate `golangci-lint`, even the large one.
-
-The idea is to not fix all existing issues. Fix only newly added issue: issues in new code.
-To do this setup CI to run `golangci-lint` with option `--new-from-rev=HEAD~1`.
-
-Also, take a look at option `--new`, but consider that CI scripts that generate unstaged files will make `--new` only point out issues in those files and not in the last commit.
-In that regard `--new-from-rev=HEAD~1` is safer.
-
-By doing this you won't create new issues in your code and can choose fix existing issues (or not).
-
-## Why `--new-from-rev` or `--new-from-patch` don't seem to be working in some cases?
-
-The options `--new-from-rev` and `--new-from-patch` work by comparing `git diff` output and issues.
-
-If an issue is not reported as the same line as the changes then the issue will be skipped.
-This is the line of the issue is not inside the lines changed.
+## Which Go versions are supported
 
-To fix that you have to use the option `--whole-files`.
-
-The side effect is the issues inside file that contains changes but not directly related to the changes themselves will be reported.
+The same as the Go team (the 2 latest minor versions)
 
 ## How to use `golangci-lint` in CI
 
 Run `golangci-lint` in CI and check the exit code. If it's non-zero - fail the build.
 
 See [how to properly install `golangci-lint` in CI](/usage/install#ci-installation)
 
-## Which Go versions are supported
-
-The same as the Go team (the 2 last minor versions)
-
 ## `golangci-lint` doesn't work
 
 1. Please, ensure you are using the latest binary release.
 2. Run it with `-v` option and check the output.
 3. If it doesn't help create a [GitHub issue](https://github.com/golangci/golangci-lint/issues/new) with the output from the error and #2 above.
 
-## Why running with `--fast` is slow on the first run
-
-Because the first run caches type information. All subsequent runs will be fast.
-Usually this options is used during development on local machine and compilation was already performed.
-
 ## Why do you have `typecheck` errors?
 
 `typecheck` is like a front-end for the Go compiler errors.
@@ -77,3 +44,36 @@ How to troubleshoot:
 - [ ] Ensure building works with `go run ./...`/`go build ./...` - whole package.
 - [ ] Ensure you are not running an analysis on code that depends on files/packages outside the scope of the analyzed elements.
 - [ ] If using CGO, ensure all require system libraries are installed.
+
+## Why running with `--fast` is slow on the first run
+
+Because the first run caches type information. All subsequent runs will be fast.
+Usually this options is used during development on local machine and compilation was already performed.
+
+## How do you add a custom linter?
+
+You can integrate it yourself, see this [manual](/contributing/new-linters/).
+Or you can create a [GitHub Issue](https://github.com/golangci/golangci-lint/issues/new) and we will integrate when time permits.
+
+## How to integrate `golangci-lint` into large project with thousands of issues
+
+We are sure that every project can easily integrate `golangci-lint`, even the large one.
+
+The idea is to not fix all existing issues. Fix only newly added issue: issues in new code.
+To do this setup CI to run `golangci-lint` with option `--new-from-rev=HEAD~1`.
+
+Also, take a look at option `--new`, but consider that CI scripts that generate unstaged files will make `--new` only point out issues in those files and not in the last commit.
+In that regard `--new-from-rev=HEAD~1` is safer.
+
+By doing this you won't create new issues in your code and can choose fix existing issues (or not).
+
+## Why `--new-from-rev` or `--new-from-patch` don't seem to be working in some cases?
+
+The options `--new-from-rev` and `--new-from-patch` work by comparing `git diff` output and issues.
+
+If an issue is not reported as the same line as the changes then the issue will be skipped.
+This is the line of the issue is not inside the lines changed.
+
+To fix that you have to use the option `--whole-files`.
+
+The side effect is the issues inside file that contains changes but not directly related to the changes themselves will be reported.