Fix broken links in developer docs

ARCHITECTURE.md

@@ -11,7 +11,7 @@ This document is far from complete. Hopefully it can evolve over time and become
 introduction to OTP architecture. The OTP project GitHub issues are a good place to look for
 detailed discussions on many design decisions.
 
-We document [Decision Records](DECISION_RECORDS.md) in a log. Make sure you as a developer are familiar 
+We document [Decision Records](DEVELOPMENT_DECISION_RECORDS.md) in a log. Make sure you as a developer are familiar 
 with the decisions and follow them. Reviewers should use them actively when reviewing code and may
 use them to ask for changes.
 
@@ -22,7 +22,7 @@ Be sure to also read the [developer documentation](doc/user/Developers-Guide.md)
 The diagram shows a simplified/generic version on how we want to model the OTP components with 2 
 examples. The Transit model is more complex than the VehiclePosition model.   
 
-![MainModelOverview](doc/user/images/ServiceModelOverview.png)
+![MainModelOverview](doc/dev/images/ServiceModelOverview.png)
 
  - `Use Case Service` A service which combine the functionality in many `Domain Services` to fulfill
    a use-case or set of features. It may have an api with request/response classes. These are 
@@ -45,10 +45,6 @@ but this is a start and we would like to expand this list in the future.
 The Configuration module is responsible for loading and parsing OTP configuration files and map them
 into Plan Old Java Objects (POJOs). These POJOs are injected into the other components.
 
-### [REST API](src/main/java/org/opentripplanner/api/package.md)
-
-Short introduction to the REST API.
-
 ### [GTFS import module](src/main/java/org/opentripplanner/gtfs/package.md)
 
 Used to import GTFS transit data files.

doc/dev/decisionrecords/Codestyle.md

@@ -58,7 +58,7 @@ Editor > Code Style_. Then select **Project** in the \_Scheme drop down.
 You can run the Prettier Maven plugin as an external tool in IntelliJ. Set it up as an
 `External tool` and assign a key-shortcut to the tool execution.
 
-![External Tool Dialog](../../../doc/user/images/ExternalToolDialog.png)
+![External Tool Dialog](../images/ExternalToolDialog.png)
 
 ```
 Name:              Prettier Format Current File

doc/dev/decisionrecords/NamingConventions.md

@@ -60,7 +60,7 @@ These prefixes are also "allowed", but not preferred - they have some kind of ne
 
 ## Service, Model and Repository
 
-![MainModelOverview](doc/user/images/ServiceModelOverview.png)
+![MainModelOverview](../images/ServiceModelOverview.png)
 
 
 

doc/dev/decisionrecords/UseDecisionRecords.md

@@ -1,9 +1,9 @@
 # Decision Records
 
-[TODO - Not precise] An OTP Decision Record is a justified software design choice that addresses a
-significant functional or non-functional requirement. [Architectural Decision Records](https://adr.github.io/)
-is a similar concept, but we have widened the scope to include any relevant decision about
-OTP development.
+An OTP Decision Record is a justified software design choice that addresses a significant 
+functional or non-functional requirement. [Architectural Decision Records](https://adr.github.io/) is a similar 
+concept, but we have widened the scope to include any relevant decision about OTP development.
+
 
 ## Process
 
@@ -26,12 +26,12 @@ the decision.
 - The final approval is done in the developer meeting, at least 3 developers representing 3
   different organisations should approve it. No vote against the proposal. If the developers
   are not able to agree, the PLC can decide.
-- References to Architectural Decision Records in reviews can be done by linking or just typing
-  e.g. `Use-Dependency-Injection` or [Use-Dependency-Injection](/DECISION_RECORDS.md#use-dependency-injection)
+- References to Development Decision Records in reviews can be done by linking or just typing. 
+  For example `Use-Dependency-Injection` or [Use-Dependency-Injection](../../../DEVELOPMENT_DECISION_RECORDS.md#use-dependency-injection)
 
 ### Checklist
 - [ ] Give it a meaningful title that quickly lets the reader understand what it is all about.
 - [ ] Get it approved in a developer meeting with 3 votes in favor (3 organisations).
-- [ ] Add the name and description to the list in the [Decision Records](/DECISION_RECORDS.md) list.
+- [ ] Add the name and description to the list in the [Development Decision Records](../../../DEVELOPMENT_DECISION_RECORDS.md) list.
       Maximum two sentences should be used. Try to keep it as short as possible.
 - [ ] Remember to link to the PR.

doc/user/Developers-Guide.md

@@ -206,7 +206,7 @@ that have the code checked out locally.
 
  - [Architecture](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/ARCHITECTURE.md) 
  - [Code Conventions](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/CODE_CONVENTIONS.md)
- - [Development Decision Records](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/DECISION_RECORDS.md)
+ - [Development Decision Records](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/DEVELOPMENT_DECISION_RECORDS.md)
 
 
 ## Continuous Integration