From cca8cb4386e2126e82733ccc3c13e132ee01d61d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= <jfd@butonic.de>
Date: Wed, 9 Dec 2020 15:48:11 +0100
Subject: [PATCH] Apply suggestions from code review

Co-authored-by: Alex Unger <6905948+refs@users.noreply.github.com>
---
 docs/adr/0002-persist-accounts-using-cs3-storage.md | 4 ++--
 docs/adr/0003-outsource-user-management.md          | 6 ++----
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/docs/adr/0002-persist-accounts-using-cs3-storage.md b/docs/adr/0002-persist-accounts-using-cs3-storage.md
index 13b75b9c53..7433fa1f02 100644
--- a/docs/adr/0002-persist-accounts-using-cs3-storage.md
+++ b/docs/adr/0002-persist-accounts-using-cs3-storage.md
@@ -8,7 +8,7 @@ Technical Story: [File system based indexing](https://github.com/owncloud/ocis-a
 
 ## Context and Problem Statement
 
-To set up HA or a geo replicated setup we need to persist accounts in a distributed way. Furthermore, the bleve index makes the accounts service stateful, which we wand to avoid for a scale out deployment.
+To set up High Availability (HA) or a geo-replicated setup we need to persist accounts in a distributed way. Furthermore, the [bleve](https://github.com/blevesearch/bleve) index makes the accounts service stateful, which we want to avoid for a scale out deployment.
 
 ## Considered Options
 
@@ -17,7 +17,7 @@ To set up HA or a geo replicated setup we need to persist accounts in a distribu
 
 ## Decision Outcome
 
-Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo replication and HA.
+Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo-replication and HA.
 
 ### Positive Consequences <!-- optional -->
 
diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md
index 55cea3336c..0e63dd8fd2 100644
--- a/docs/adr/0003-outsource-user-management.md
+++ b/docs/adr/0003-outsource-user-management.md
@@ -1,4 +1,4 @@
-# 3. Outsource Usermanagement
+# 3. Outsource User Management
 
 * Status: accepted <!-- optional -->
 * Deciders: @butonic, @mbarz, @kfreitag, @hd, @pmaier1 <!-- optional -->
@@ -13,7 +13,7 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass
 ## Decision Drivers <!-- optional -->
 
 * OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server.
-* Time: we want to build a release candiddate asap.
+* Time: we want to build a release candidate asap.
 
 ## Considered Options
 
@@ -59,7 +59,6 @@ Currently, the accounts service is the source of truth and we use it to implemen
 * Good, because we can manage users out of the box
 * Good, because we can persist accounts in a CS3 storage provider
 * Bad, because it maintains a separate user repository: it needs to either learn or sync users.
-* … <!-- numbers of pros and cons can vary -->
 
 ### Move accounts functionality to GLauth and name it accounts
 
@@ -88,4 +87,3 @@ We should use an existing ldap server and make GLauth a drop in replacement for
 * Good, because we can use the CS3 user proviter with the existing ldap / rest driver.
 * Bad, because OCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.) 
 * Bad, because OCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLauth.
-* … <!-- numbers of pros and cons can vary -->