Reformat ADR

Signed-off-by: Sven Strittmatter <[email protected]>

docs/adr/adr_0005.md

@@ -10,18 +10,19 @@ SPDX-License-Identifier: Apache-2.0
   Please add a cross-reference link to the new ADR on 'superseded' ADR.
   e.g.: [ADR superseded by](ADR-NNNN.md)
 -->
-| <!-- -->       | <!-- -->                                                                             |
-|----------------|--------------------------------------------------------------------------------------|
-| **Status**:    | PROPOSED |
-| **Date**:      | 2022-10-25                                                                          |
-| **Author(s)**: | Amar Bolkan <[email protected]                         |
+| <!-- -->       | <!-- -->                              |
+|----------------|---------------------------------------|
+| **Status**:    | PROPOSED                              |
+| **Date**:      | 2022-10-25                            |
+| **Author(s)**: | Amar Bolkan <[email protected] |
 
 
 
 ## Context
 
-Teamdojo has a feature, which tracks a score for each team. Calculation of this score is currently done client side.
+TeamDojo has a feature, which tracks a score for each team. Calculation of this score is currently done client side.
 To calculate the score for a specific team the following entities are queried from the backend:
+
 - all available skills: `api/skills`
 - teamskills: `/api/team-skills`
 - team: `/api/teams`
@@ -42,12 +43,10 @@ current amount of data. This calls for more viable solution to be implemented.
 
 ### Solution 1: Moving the calculation into the backend
 
-
 #### Non-persistent approach
 Move team score calculations to the backend and create an Api, which 
 the client can query. The calculation of the score is done on demand and is not persisted.
 
-
 Proposed API:
 
 `/api/team-score/:teamId` : Accepts GET requests and returns the current score for the queried team. 
@@ -64,6 +63,7 @@ Proposed API:
 - more java classes need to be added to the backend, these might need to be changed when updating to new versions of the `Jhipster Generator`
 
 Files to be added to the backend:
+
 - `CustomTeamscoreResource`
 - `CustomTeamScoreService`
 
@@ -74,24 +74,23 @@ Files to be changed in the frontend:
 Files to be deleted:
 - `src/main/webapp/app/custom/helper/team-score-calculation.ts`
 
-
 #### Persistent Approach
+
 Not persisting `Teamscore` calculations means that the same calculation might be done over and over again.
 This is quite redundant and might lead to unnecessary load for the server. Instead the score for each team can be 
 persisted inside the database. This might be done by adding a score field to the team entity.
 
-
 #### Pros
+
 - should be more resource efficient (no redundant calculations of `Teamscores` )
 - third party systems could still easily query scores for each team
 - separate Api, which retrieves the `Teamscore` could later be added
 - client performance should increase (calculations now done in the backend)
 
 #### Cons
+
 - persisted `Teamscores` now need to be maintained (server needs to react when events occur which might influence the `Teamscore`, for example a skill expires or isn't relevant anymore)
 - generated code might need to be extended or changed
-- 
-
 
 <!--
 Relevant files for score calculation:
@@ -109,26 +108,29 @@ Variable used in TeamScore calculation: team (containing all achieved skills), a
 Another solution would be to keep sending queries until all entities have been returned by the backend.
 
 ### Pros
+
 - low implementation effort, query for `Teamskills` only needs to be put into a loop
 - doesn't add new custom files to the backend, which would need to be maintained separately from the generated ones 
 
 
 ### Cons
+
 - keeps the computational load on the client
 - `Teamscores` can't easily be queried by third party software 
 - might negatively impact scalability of the system, due to increasing amounts of data needing to be queried
+
 ## Consequences
 
 ### Solution 1:
+
 This change would shift the computational load onto the server and provide a clear and easy way for the client to
 query scores for each individual team. In turn new classes are added to the backend and the client code also needs to be adapted to use this new Api.
 It would also lead to code duplication as `RelevanceCheck` and `CompletionCheck` are also used in different parts of the frontend.
 
 
-### Solution 2: 
+### Solution 2:
+
 This would simply be a small adaption in the client code. Where the single query is replaced 
 by a loop that checks if all pages have been queried.
 In case of large datasets this solution could lead to higher network traffic and be a strain on the 
 clients resources. 
-
-