Move up developer instructions in the documentac-uploads-docs

1 files changed, 20 insertions, 20 deletions

diff --git a/doc/development/uploads.md b/doc/development/uploads.md
index 6b152346a19..eac57826dab 100644
--- a/doc/development/uploads.md
+++ b/doc/development/uploads.md
@@ -84,6 +84,26 @@ Scaling NFS is outside of our support scope, and NFS is not a part of cloud nati
 
 All features that require sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since sidekiq POD cannot reach into other pods, the operation will fail to read it.
 
+## How to select the proper level of acceleration?
+
+Selecting the proper acceleration is a tradeoff between speed of development and operational costs.
+
+We can identify three major use-cases for an upload:
+
+1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
+1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development.
+1. **sidekiq/asynchronous processing:** Async processing should implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
+
+### Handling repository uploads
+
+Some features involves git repository uploads without using a regular git client.
+Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md).
+
+Those uploads requires the rails controller to act as a git client in lieu of the user.
+Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size.
+
+In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq.
+
 ## Upload encodings
 
 By upload encoding we mean how the file is included within the incoming request.
@@ -245,23 +265,3 @@ This option affect the response to the `/authorize` call. When not enabled, the
 
 Once the request reachs rails, it will schedule an object storage upload as a sidekiq job.
 
-## How to select the proper level of acceleration?
-
-Selecting the proper acceleration is a tradeoff between speed of development and operational costs.
-
-We can identify three major use-cases for an upload: 
-
-1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case Object Storage acceleration is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
-1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using workhorse disk acceleration may speed up development.
-1. **sidekiq/asynchronous processing:** Async processing should implement Object Storage acceleration, the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
-
-### Handling repository uploads
-
-Some features involves git repository uploads without using a regular git client.
-Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md).
-
-Those uploads requires the rails controller to act as a git client in lieu of the user.
-Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size.
-
-In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq.
-