Categorize and move content

doc/development/contributing/merge_request_workflow.md

@@ -12,6 +12,27 @@ to GitLab code, tests, and documentation. The issues that are specifically suita
 for community contributions have the [`Seeking community contributions`](issue_workflow.md#label-for-community-contributors)
 label, but you are free to contribute to any issue you want.
 
+## Working from issues
+
+If you find an issue, please submit a merge request with a fix or improvement,
+if you can, and include tests.
+
+If you want to add a new feature that is not labeled, it is best to first create
+an issue (if there isn't one already) and leave a comment asking for it
+to be labeled as `Seeking community contributions`. See the [feature proposals](issue_workflow.md#feature-proposals)
+section.
+
+If you don't know how to fix the issue but can write a test that exposes the
+issue, we will accept that as well. In general, bug fixes that include a
+regression test are merged quickly. New features without proper tests
+might be slower to receive feedback.
+
+If you are new to GitLab development (or web development in general), see the
+[how to contribute](index.md#how-to-contribute) section to get started with
+some potentially easy issues.
+
+## Merge request ownership
+
 If an issue is marked for the current milestone at any time, even
 when you are working on it, a GitLab team member may take over the merge request to ensure the work is finished before the release date.
 
@@ -31,28 +52,18 @@ we credit the original author by adding a changelog entry crediting the author
 and optionally include the original author on at least one of the commits
 within the MR.
 
-If you want to add a new feature that is not labeled, it is best to first create
-an issue (if there isn't one already) and leave a comment asking for it
-to be labeled as `Seeking community contributions`. See the [feature proposals](issue_workflow.md#feature-proposals)
-section.
+## Merge request guidelines for contributors
+
+### Getting started
 
 Merge requests should be submitted to the appropriate project at GitLab.com, for example
 [GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests),
 [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests), or
 [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests).
 
-If you are new to GitLab development (or web development in general), see the
-[how to contribute](index.md#how-to-contribute) section to get started with
-some potentially easy issues.
-
-To start developing GitLab, download the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit)
+To start developing GitLab locally, download the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit)
 and see the [Development section](../../index.md) for the required guidelines.
 
-## Merge request guidelines for contributors
-
-If you find an issue, please submit a merge request with a fix or improvement,
-if you can, and include tests.
-
 NOTE:
 Consider placing your code behind a feature flag if you think it might affect production availability.
 Not sure? Read [When to use feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
@@ -64,11 +75,7 @@ this by tagging them in an MR before submitting the code for review. Talking
 to team members can be helpful when making design decisions. Communicating the
 intent behind your changes can also help expedite merge request reviews.
 
-If
-you don't know how to fix the issue but can write a test that exposes the
-issue, we will accept that as well. In general, bug fixes that include a
-regression test are merged quickly. New features without proper tests
-might be slower to receive feedback.
+### Creating a merge request
 
 To create a merge request: