Fix broken or missing internal links

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

developer_manual/app/routes.rst

@@ -54,7 +54,7 @@ The route array contains the following parts:
 
         }
 * **method** (Optional, defaults to GET): The HTTP method that should be matched, (e.g. GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH)
-* **requirements** (Optional): lets you match and extract URLs that have slashes in them (see **Matching subURLs**)
+* **requirements** (Optional): lets you match and extract URLs that have slashes in them (see :ref:`matching-suburls`)
 * **postfix** (Optional): lets you define a route id postfix. Since each route name will be transformed to a route id (**page#method** -> **myapp.page.method**) and the route id can only exist once you can use the postfix option to alter the route id creation by adding a string to the route id, e.g., **'name' => 'page#method', 'postfix' => 'test'** will yield the route id **myapp.page.methodtest**. This makes it possible to add more than one route/URL for a controller method
 * **defaults** (Optional): If this setting is given, a default value will be assumed for each URL parameter which is not present. The default values are passed in as a key => value par array
 
@@ -83,6 +83,8 @@ It is possible to extract values from the URL to allow RESTful URL design. To ex
 
 The identifier used inside the route is being passed into controller method by reflecting the method parameters. So basically if you want to get the value **{id}** in your method, you need to add **$id** to your method parameters.
 
+.. _matching-suburls:
+
 Matching subURLs
 ================
 Sometimes it is needed to match more than one URL fragment. An example would be to match a request for all URLs that start with **OPTIONS /index.php/apps/myapp/api**. To do this, use the **requirements** parameter in your route which is an array containing pairs of **'key' => 'regex'**:

developer_manual/bugtracker/codereviews.rst

@@ -42,8 +42,8 @@ How will it work?
 
 Examples
 --------
-Read our `coding guidelines`_ for information on what a good pull request and
-good Nextcloud code looks like.
+Read our documentation about :doc:`../general/codingguidelines` for information
+on what a good pull request and good Nextcloud code looks like.
 
 These are two examples that are considered to be good examples of how pull
 requests should be handled
@@ -58,4 +58,3 @@ Feel free to drop a line on the `forums`_ or join us on `IRC`_.
 
 .. _forums: https://help.nextcloud.com/
 .. _IRC: http://webchat.freenode.net/?channels=nextcloud-dev
-.. _coding guidelines: ../general/codingguidelines

developer_manual/bugtracker/kanban.rst

@@ -120,7 +120,7 @@ To Review
 Why do we have it?
   Instead of directly committing to master we agree that **a second set of eyes
   will spot bugs** and increase our code quality and give us an opportunity to
-  learn from each other. See also our `Code Review Documentation`_
+  learn from each other. See also our documentation about :doc:`codereviews`
 
 What does a developer think?
   "I’ll check the Scenario described earlier works as expected. If necessary

developer_manual/general/codingguidelines.rst

@@ -28,7 +28,7 @@ The most important labels and their meaning:
 * #design - this needs help from the design team or is a design-related issue/pull request
 * #technical debt - this issue or PR is about `technical debt <http://en.wikipedia.org/wiki/Technical_debt>`_
 * #starter issue - these are issues which are relatively easy to solve and ideal for people who want to learn how to code in Nextcloud
-* #needs info - this issue needs further information from the reporter, see `triaging <../bugtracker/triaging.html>`_
+* #needs info - this issue needs further information from the reporter, see :doc:`../bugtracker/triaging`
 * #high #medium #low signify how important the bug is.
 * Tags showing the state of the issue or PR, numbered 0-4:
  * #0 - Needs triage - ready to start development on this