Update lifetime of documents based on feedback

Add a bunch of small clarifications to lifetime of documents based on
feedback provided by users.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

content/concepts/document_lifetime.md

@@ -13,20 +13,22 @@ of systems for embedded devices as well as a whole infrastructure to make that
 possible. During its evolution changes are necessary and updating documentation
 is a key point to making it user friendly.
 
-With the goal of having documentation that really express the current state of
-the distribution, a process and procedure to manage the lifetime of documents
-is crucial. This document describes the guidelines to later implement this
-process to achieve the desired goal.
+With the goal of having documentation that really expresses the current state of
+the distribution, having a process and procedure to manage the lifetime of
+documents is crucial since each new release introduces changes than can lead to
+documentation to become outdated. This document describes the process and procedure to
+follow from creation until the end-of-life of documents to achieve the desired
+goal.
 
 # Document types
 
-After the migration to the new website a massive reconstruction of the
+After the migration to the new website a massive restructuring of the
 documentation has been made. As a result of this process, a clear organization
 has been implemented, leading to different document types being identified.
 
 ## Architecture
 
-Documents under this category are meant to show the current state of the
+Documents of this type are meant to show the current state of the
 distribution, from a high level point of view. They are the result of design
 decision that were adopted in the past to provide users with the basis to build
 their solutions.
@@ -37,15 +39,17 @@ Information under this category express a concept that has been analyzed to
 improve Apertis in some way. They are an essential part of the development
 process since they set the basis for future work.
 
-These documents, since they reflect a plan, should have a validity according
-to the plan they describe. It is expected that once the plan has been executed
-the document should be refactored and moved to one or more suitable sections,
+Since these documents reflect an implementation plan, their validity should
+match the one of the plan they describe and reflect the adaptations that
+may have chosen during the implementation to provide better results.
+It is expected that once the plan has been executed
+the document should be refactored and moved to more suitable sections,
 since it should describe the current state of one aspect of Apertis.
 
 ## Guides
 
 Guides are meant to be more practical documents describing the steps for executing
-a procedure. These documents generally include command line examples, screenshots
+a procedure. These documents generally include command line examples, sample sources
 and logs.
 
 The information validity for this type of document is expected to be short
@@ -67,8 +71,8 @@ meant to help users bring up Apertis on those devices.
 ## Releases
 
 Documents under this section are meant to be kept as a historical reference,
-therefore they should be preserved without any modification, except for links
-updates.
+to show how Apertis has been evolving across time. Therefore they should be
+preserved without any modification, except for links updates.
 
 # Default review period
 
@@ -118,7 +122,8 @@ that the whole document has been reviewed and the committer is confident about
 its state.
 
 - `reviewperiod`, which shows the number of months after a document requires a review
-to confirm it is still valid if the default value is not adequate. This could be
+to confirm it is still valid if the default value from the [table](#default-review-period)
+is not adequate. This could be
 helpful to highlight documents that might need to be reviewed sooner than the
 default as they could be affected by the natural evolution of the project.
 
@@ -173,7 +178,9 @@ value, since it will bring thousands of results. On the other hand, a tag like
 `licensing` will probably be useful.
 
 - In order to enforce the previous comment, the tags used in a document should
-be checked against a list of valid tags.
+be checked against a list of valid tags. This list should be part of the
+documentation so new tags can by added by developers in the same way documentation
+is updated.
 
 - Tags can be implemented gradually, as tagging will require a manual work in
 order to highlight the relevant information. Initially tags can appear at the
@@ -246,7 +253,7 @@ and up to date
 - `reviewperiod` should be added/updated if for some reason the default value
 does not fit
 - `status` and `statusDescription` should be updated to reflect important aspects
-of a document, for instance that the document requires an update
+of a document, for instance that the document requires a review or update
 
 ## End-of-life