Update lifetime of documents with examples

In order to make the proposed workflow clearer provide examples of real
world situations.

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

content/concepts/document_lifetime.md

@@ -272,6 +272,61 @@ In case the document is obsolete but need to be published for different reasons,
 such as historical reason, this fact should be reflected with the `status` and
 `statusDescription` fields.
 
+# Examples
+
+In this section some examples will be introduced to described how the workflow
+is implemented with some real scenarios.
+
+Case 1: Developer edits a document to update an URL
+
+Since the problem is minimal and does not invalidate the usefulness of the document
+the metadata does not need to be updated. However, if during this process the
+developer performs a review of it, he can update the `lastreview` date accordingly.
+
+Case 2: Developer needs to update a section of a document
+
+In this case, a minimal understanding of the document is required, which should
+be sufficient to find the value of keeping it updated. As consequence, `lastmod`
+date should be updated to reflect that this document is alive and worth
+to keep it updated. As in the previous case, if during this process the developer
+performs a review of it, he can update the `lastreview` date accordingly.
+
+However, if during this process the developer understands that the document
+is outdated or with no value for the project he should rise a warning. To do it
+he should change the `status` to document following:
+
+- Requires Review: The developer suspects that some information on the document
+  is not accurate or update as there were changes in the project after the last
+  document update.
+
+- Requires Update: The developer is confident that the document requires an
+  update to show the current state of the project.
+
+In both cases the field `statusDescription` should be updated to provide
+additional information.
+
+Case 3: Developer reviews a document
+
+The purpose of reviewing a document is to validate that it still has value,
+it is accurate and updated. During this process the developer should read
+the whole document and make an statement, according to the best of his knowledge.
+There can be different situations:
+
+- The document has value, is accurate and updated, in which case the developer
+  is confident to approve it and updates `lastreview` to the current date.
+
+- The document has value but some minor updates are needed. In this case, in
+  order to avoid any overhead, the developer updates the document as required
+  and sets `lastmod` and `lastreview` accordingly.
+
+- The document has value but some major updates are needed. In this case, the
+  `status` should be updated to "Requires update" and `statusDescription`
+  should be used to describe the situation.
+
+- The document has no longer value, in which case the developer should submit
+  a MR to drop the document.
+
+
 # Statistics
 
 The main purpose of documentation is to be consumed by users. In this regard,
@@ -369,6 +424,8 @@ checks should be performed to ensure the health of documentation:
   are highlighted. A task should be automatically created to change the
   `status` to "Requires review" for all the documents in this situation. A
   separated task should be created to review each of these documents
+  - Documents with `status` "Requires review" or "Requires update" have a task
+  associated to address the issue on them.
   - A task is created to ensure documents that have reached their lifetime
   period since the `lastreview` will be reviewed
   - Update statistics reports available trough the [dashboard](#dashboard)