chore: Configure Sphinx. Fix warnings.

.gitignore

@@ -1,3 +1,4 @@
 *.full.csv
 *.json.full
 .~lock.*
+/docs/_build

.readthedocs.yaml

@@ -3,3 +3,8 @@ build:
   os: ubuntu-20.04
   tools:
     python: "3.9"
+python:
+  install:
+    - requirements: docs/requirements.txt
+sphinx:
+  fail_on_warning: true

docs/C1/Seccion1.md

@@ -1,4 +1,4 @@
-## An Introduction to the Open Contracting Data Standard
+# An Introduction to the Open Contracting Data Standard
 
 > *This introduction has been taken from the chapter [An introduction to the Open Contracting Data Standard](https://github.com/rparrapy/ocds-r-manual/blob/master/manual.Rmd#an-introduction-to-the-open-contracting-data-standard) of the Manual [Analyzing Open Contracting data using the R programming language](https://github.com/rparrapy/ocds-r-manual/blob/master/manual.Rmd) by [Rodrigo Parra](https://github.com/rparrapy)*
 
@@ -8,7 +8,7 @@ The data standard, designed and developed through an open process by [Open Contr
 
 The intention of this section is to introduce the reader to the standard, the use cases it was designed for and the basic concepts needed to apply it. Most of the content was taken from the official documentation of the standard; for a more thorough introductory walktrough, please refer to the [OCP getting started guide](http://standard.open-contracting.org/latest/en/getting_started/).
 
-### Users and use cases
+## Users and use cases
 
 The standard was designed with four main groups of user needs:
 
@@ -24,7 +24,7 @@ To find out about who is using OCDS-compliant data around the globe and how they
 * Biddings: allow private firms to understand the potential pipeline of procurement opportunities by looking at information related to past and current procurements.
 * Monitoring Service Delivery: helping interested actors to track procurement processes for monitoring purposes, linking budgets and donor data to the contracts and results.
 
-### The contracting process
+## The contracting process
 
 The standard defines a contracting process as:
 
@@ -34,7 +34,7 @@ The standard covers all the stages of a contracting process, even though some pr
 
 
 
-### Documents
+## Documents
 
 Contracting processes are represented as **documents** in OCDS. Each document is made up of several **sections**, mentioned below:
 
@@ -48,7 +48,7 @@ Contracting processes are represented as **documents** in OCDS. Each document is
 
 An example JSON snippet compliant with this structure looks as follows:
 
-```{json}
+```json
 {
    "language": "en",
    "ocid": "contracting-process-identifier",
@@ -73,13 +73,13 @@ There are two types of documents defined in the standard:
 
 * **Records** are snapshots of the current state of a contracting process. A record should be updated every time a new release associated to its contracting process is published; hence, there should only be a single record per contracting process.
 
-### Fields
+## Fields
 
 Each section may contain several **fields** specified in the standard, which are used to represent data. These objects can appear several times in different sections of the same document; for example, items can occur in tender (to indicate the items that a buyer wishes to buy), in an award object (to indicate the items that an award has been made for) and in a contract object (to indicate the items listed in the contract). Some example fields, accompanied by corresponding JSON snippets, are presented below.
 
-#### Parties (Organizations)
+### Parties (Organizations)
 
-```{json, eval=FALSE}
+```json
 {
     "address": {
         "countryName": "United Kingdom",
@@ -103,22 +103,22 @@ Each section may contain several **fields** specified in the standard, which are
         "uri": "http://www.barnet.gov.uk/"
     },
     "name": "London Borough of Barnet",
-    "roles": [ ... ]
+    "roles": [ ]
 }
 ```
 
-#### Amounts
+### Amounts
 
-```{json, eval=FALSE}
+```json
 {
     "amount": 11000000,
     "currency": "GBP"
 }
 ```
 
-#### Items
+### Items
 
-```{json, eval=FALSE}
+```json
 {
     "additionalClassifications": [
        {
@@ -147,18 +147,18 @@ Each section may contain several **fields** specified in the standard, which are
 }
 ```
 
-#### Time periods
+### Time periods
 
-```{json, eval=FALSE}
+```json
 {
     "endDate": "2011-08-01T23:59:00Z",
     "startDate": "2010-07-01T00:00:00Z"
 }
 ```
 
-#### Documents
+### Documents
 
-```{json, eval=FALSE}
+```json
 {
     "datePublished": "2010-05-10T10:30:00Z",
     "description": "Award of contract to build new cycle lanes to AnyCorp Ltd.",
@@ -171,9 +171,9 @@ Each section may contain several **fields** specified in the standard, which are
 }
 ```
 
-#### Milestones
+### Milestones
 
-```{json, eval=FALSE}
+```json
 {
     "description": "A consultation period is open for citizen input.",
     "dueDate": "2015-04-15T17:00:00Z",
@@ -183,7 +183,7 @@ Each section may contain several **fields** specified in the standard, which are
 ```
 
 
-### Extensions and codelists
+## Extensions and codelists
 
 In addition to regular fields, the OCDS schema defines some fields that can only be used in certain sections, e.g. *titles* and *descriptions* of tenders, awards and contracts. In some cases, publishers may require fields that are not provided by the core schema; an **extension** allows defining new fields that can be used in these cases. A list of available extensions is available [here](http://standard.open-contracting.org/latest/en/extensions); if no existing extension addresses a publisher's needs, the publisher is encouraged to collaborate on the creation of a new community extension.
 

docs/C1/Seccion2.md

@@ -1,6 +1,9 @@
+# Open Contracting Data
+
+```{note}
 Even though most of this manual's information can be used to analyze any data set, our efforts concentrate on analyzing Open Contracting Data published by the Ministry of Finance and Public Credit.
+```
 
-## Open Contracting Data
 Open Contracting Data has existed for many years in Mexico. Our records are available at the [CompraNet web page](http://compranet.funcionpublica.gob.mx/), which has an Excel file with information since 2002. This data has been analyzed thoroughly throughout time, and is available in a variety of civic tech that makes it simpler to evaluate. These are some that are currently accessible:
 * [QuienEsQuienWiki](https://www.quienesquien.wiki)
 * [ContratoBook](http://contratobook.org/#/contratos)

docs/C2/Seccion1.md

@@ -44,6 +44,16 @@ ELK platform has a linear architecture.
 
 Have a closer look at each tool:
 
-- [ElasticSearch](/en/latest/C2/Seccion1/1_ElasticSearch.html)
-- [Logstash](/en/latest/C2/Seccion1/2_Logstash.html)
-- [Kibana](/en/latest/C2/Seccion1/3_Kibana.html)
+- [ElasticSearch](Seccion1/1_ElasticSearch)
+- [Logstash](Seccion1/2_Logstash)
+- [Kibana](Seccion1/3_Kibana)
+
+
+```{toctree}
+:hidden: true
+
+Seccion1/1_ElasticSearch
+Seccion1/2_Logstash
+Seccion1/3_Kibana
+Extra
+```

docs/C2/Seccion4.md

@@ -4,9 +4,9 @@ Now that the platform is up and running, we can look in depth into the collectio
 
 **IMPORTANT:** Everything we will mention next is implemented in the code as a part of Docker containers. It is not necessary to repeat these steps, we just mention this here for a better understanding of the process.
 
-# Preparing OCDS data in packages
+## Preparing OCDS data in packages
 
-## Available and required format
+### Available and required format
 
 The file obtained from gob.mx is in format [Record Package](http://standard.open-contracting.org/latest/en/schema/record_package/)
 
@@ -56,7 +56,7 @@ is an OCDS document.
 
 In this manner, we can process it with Logstash and later send one document at a time to ElasticSearch.
 
-## Converting the format with `jq` tool
+### Converting the format with `jq` tool
 
 An open source and MIT license tool is available to work with JSON files: [jq](https://stedolan.github.io/jq/).
 
@@ -75,7 +75,7 @@ jq
     "file.json" = File to be read
     "file.ocds_per_line" = The file created as a result
 ```
-### Jq filter and data structure
+#### Jq filter and data structure
 
 The filter is the most important part of this command. We must review carefully the data structure introduced in the original file in order to understand it.
 ```
@@ -103,9 +103,9 @@ Putting all instructions together, and in jq filter note, we should get: `.[].re
 The files created by this command are compatible with Logstash. Now, we will continue with the pipeline creation, but first we should review some important concepts.
 
 
-# Basic Concepts for Logstash Pipelines
+## Basic Concepts for Logstash Pipelines
 
-## Syntax
+### Syntax
 
 Logstash Pipelines definitions use a similar language to simplified programming code blocks.
 
@@ -134,11 +134,11 @@ We may have different types of option values:
 - Arrays `option => [ "Text", 123, false ]`
     > Arrays are a different sort of sets
 
-## Pipeline
+### Pipeline
 
 In the file [pipeline.conf](https://github.com/ProjectPODER/ManualKibanaOCDS/blob/master/pipeline/pipeline.conf), we can find the already designed pipeline for this dataset; let's check each of the blocks composing it.
 
-# Input
+## Input
 
 This component indicates Logstash where and how to read the original data.
 
@@ -151,7 +151,7 @@ input {
 ```
 For this pipeline, we have decided to read the file from the program standard input. Each line received will be treated as a JSON document and stored in memory for the following step.
 
-# Transformation (filter)
+## Transformation (filter)
 
 This block indicates Logstash what to do with each of the records read from Input module.
 
@@ -204,7 +204,7 @@ It would be transformed as:
 ```
 Finally, the `compiledRelease` property is removed; in the same way as  `releases`, `host` and `path`.
 
-# Output
+## Output
 
 This section indicates Logstash what to do with the new documents. In our case, we want the results to be sent to ElasticSearch.