Changes by create-pull-request action (#104)

Changes by create-pull-request action

docs/guides/sda-dev-test-doc.md

@@ -1,13 +1,14 @@
 ## Getting Started developing components of the SDA stack
 
-If you wish to work on the SDA stack itself you'll first need [Go](https://www.golang.org/) installed on your machine. The recommended version can be checked by running:
+Should one wish to engage in the development of the SDA stack itself, the prerequisite is the installation of [Go](https://www.golang.org/) on the respective machine.
+The recommended version can be checked by running:
 
 ```sh
 $ make go-version-check
 ...
 ```
 
-For local dev first make sure Go is properly installed, including setting up a [GOPATH](https://golang.org/doc/code.html#GOPATH). Ensure that $GOPATH/bin is in your path as some distributions bundle the old version of build tools. Next, clone this repository. SDA uses [Go Modules](https://github.com/golang/go/wiki/Modules), so it is recommended that you clone the repository outside of the GOPATH. You can then download any required build tools by bootstrapping your environment:
+In preparation for local development, it is essential to verify the proper installation of Go, including the establishment of a [GOPATH](https://golang.org/doc/code.html#GOPATH). Confirm that $GOPATH/bin is included in the system's path, as certain distributions may package outdated versions of build tools. Subsequently, proceed to clone the repository. SDA employs [Go Modules](https://github.com/golang/go/wiki/Modules), and it is advisable to perform the cloning operation outside the GOPATH. Following this, obtain any necessary build tools by initializing the environment through bootstrapping:
 
 ```sh
 $ make bootstrap

docs/services/sda.md

@@ -19,5 +19,5 @@ There are also additional support services:
 
 1. [Intercept](intercept.md) relays messages from `CentralEGA` to the system.
 2. [s3inbox](s3inbox.md) proxies uploads to the an S3 compatible storage backend.
-3. [sync](sync.md) The sync service mirrors ingested data between sites in the [Bigpicture](https://bigpicture.eu/) project.
-4. [syncapi](syncapi.md) The sync-api service is used in the [Bigpicture](https://bigpicture.eu/) project for mirroring data between two installations of SDA.
+3. [sync](sync.md) mirrors ingested data between sites in the [Bigpicture](https://bigpicture.eu/) project.
+4. [syncapi](syncapi.md) is used in the [Bigpicture](https://bigpicture.eu/) project for mirroring data between two installations of SDA.

docs/services/sftpinbox.md

@@ -4,32 +4,27 @@
 
 `CentralEGA` contains a database of users, with IDs and passwords.
 
-We have developed a solution based on [Apache Mina SSHD](https://mina.apache.org/sshd-project/)
-to allow user authentication via either a password or an RSA key against the CentralEGA database
-itself. The user is locked within their home folder, which is done programmatically using 
+A solution has been devised using [Apache Mina SSHD](https://mina.apache.org/sshd-project/) to facilitate user authentication through either a password or an RSA key, directly against the CentralEGA database. The user is locked within their home folder, which is done programmatically using 
 [RootedFileSystem](https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/common/file/root/RootedFileSystem.java).
 
 The solution uses `CentralEGA`'s user IDs but can also be extended to
-use LifeScience AAI IDs (of which we strip the ``@elixir-europe.org`` suffix).
+use LifeScience AAI IDs (from which the ``@elixir-europe.org`` suffix is removed).
 
 The procedure is as follows. The inbox is started without any created
 user. When a user wants to log into the inbox (actually, only ``sftp``
 uploads are allowed), the code looks up the username in a local
-cache, and, if not found, queries the `CentralEGA` [REST endpoint](https://nss.ega-archive.org/spec/). Upon
-return, we store the user credentials in the local cache and create
-the user's home directory. The user now gets logged in if the password
+cache, and, if not found, queries the `CentralEGA` [REST endpoint](https://nss.ega-archive.org/spec/). Upon the user's return, their credentials are stored in the local cache, and a home directory is established for the user. The user now gets logged in if the password
 or public key authentication succeeds. Upon subsequent login attempts,
 only the local cache is queried, until the user's credentials
 expire. The cache has a default TTL of 5 minutes, and is wiped clean
 upon reboot (as a cache should). Default TTL can be configured via ``CACHE_TTL`` env var.
 
 The user's home directory is created when its credentials upon successful login.
-Moreover, for each user, we detect when the file upload is completed and compute its
-checksum. 
+Moreover, for each user, detection is performed to ascertain when the file upload is completed, and the checksum for the uploaded file is computed.
 
 ## S3 integration
 
-Default storage back-end for the inbox is local file-system. But we also support S3 service as a back-end. It can be 
+Default storage back-end for the inbox is local file-system. Additionally, support for the S3 service is provided as a back-end option. It can be 
 enabled using S3-related env-vars (see configuration details below).
 
 If S3 is enabled, then files are still going to be stored locally, but after successful upload, they will going to be