Contribute Howto update

pages/04.Contribute/01.procedure/docs.en.md

@@ -0,0 +1,44 @@
+---
+title: Procedures
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - procedure
+page-toc:
+    active: true
+---
+
+# Howto Procedures: What does it mean?
+The possibility of writing a tutorial and making it accessible to everyone in their own languages is fundamental in order to encourage and promote not only the use of free/libre and open source software but also collective thoughts and actions. So coordinating the amount of information to be written and translated is an important task, therefore we developed a basic set of steps to follow to help us achieve this goal.
+
+The procedure is rather simple:
+1. We get a copy of the files we are going to work on;
+2. we work locally on the files,
+3. and once we have finished, we submit them.
+
+Sounds pretty easy, doesn't it? Well, it really is. Of course, every step of the process has its own set of actions, which we will see later on, but that is it basically.
+
+# What tools do we need?
+We use three tools for our work: **Git**, **a text editor** and **Gitea**.
+
+We choose **Git** for several reasons, the main one being our documents structure and code language. Even though there are many (and very good ones) translation tools which look more "user friendly", none of them fit our use case or have **Markdown** text format support out-of-the-box. In the best scenario, it will requires us to make massive modifications on the files in order to strip them down into several "text sections" or "strings". Another important reason is that **Git** allows us to keep track on the changes made on those files, making it easier to manage and collaborate on them. And one more reason is that **Gitea** (the code hosting software we use with **Git**) has a lot of useful features to organize and improve the work in one single place.
+
+OK, let's check our tools:
+
+1. **Git**: If you are a **GNU/Linux** user it is highly probable that you already have it installed (you can check in your software package manager or through the terminal with the command `which git`). If you are using **Microsoft Windows** or **Mac OS**, you can download it from [here](https://git-scm.com/downloads).
+
+2. **A text editor**: Although there are many of them, we suggest you to use one with **Markdown** format support and **Git** integration. **Kate Editor**, **Atom Text Editor** and **VSCodium**, meet this criteria natively, and they are also Free/Libre and Open Source multiplatform software. But, **for practical reasons, we will only see how to work in Atom** (in the future we will include other tools).
+
+  **Atom Text Editor**: [Download](https://atom.io/) · [Source code](https://github.com/atom/atom)
+
+
+3. **A Disroot Gitea account**: In order to be able to submit your work, you will need to register an account on our **Gitea** instance (**Disroot** credentials will not work) and request access to our repository.
+
+  [**Register a new account**](https://git.disroot.org/user/sign_up) on **Disroot's Gitea** instance.
+
+Once you have these tools, it is time to set them up.

pages/04.Contribute/01.procedure/docs.es.md

@@ -0,0 +1,44 @@
+---
+title: Procedimientos
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - procedimiento
+page-toc:
+    active: true
+---
+
+# Procedimientos Howto: ¿Qué significa?
+La posibilidad de escribir un tutorial y hacerlo accesible para todxs en sus propios idiomas es fundamental no solo para fomentar y promover el uso de software libre y de código abierto sino también pensamientos y acciones colectivas. Así que coordinar la cantidad de información a ser escrita y traducida es una tarea importante, por lo tanto desarrollamos una serie básica de pasos a seguir para que nos ayude a lograrlo.
+
+El procedimiento es bastante simple:
+1. Obtenemos una copia de los archivos sobre los que vamos a trabajar;
+2. trabajamos localmente en ellos,
+3. y una vez que hemos terminado, los enviamos.
+
+Suena bastante fácil, ¿no?. Bueno, realmente lo es. Por supuesto, cada paso del procedimiento  tiene su propio conjunto de acciones, que veremos más adelante, pero es eso básicamente.
+
+# ¿Qué herramientas necesitamos?
+Usamos tres herramientas para nuestro trabajo: **Git**, **un editor de texto** y **Gitea**.
+
+Elegimos **Git** por varias razones, la principal es la estructura y el lenguaje de código de nuestros documentos. Aunque hay muchas (y muy buenas) herramientas de traducción que parecen más "fáciles de usar", ninguna de ellas se ajusta a nuestro caso de uso o tienen soporte para el formato de texto **Markdown** por defecto. En el mejor de los escenarios, requeriría que hagamos modificaciones enormes sobre los archivos para poder desglosarlos en muchas "secciones de texto" o "cadenas". Otra razón importante es que **Git** nos permite mantener un registro de los cambios realizados sobre esos archivos, haciéndo más sencillo manejarlos y colaborar sobre ellos. Y una razón más es que **Gitea** (el software para hospedar código que usamos con **Git**) tiene un montón de funcionalidades muy útiles para organizar y mejorar el trabajo en un solo lugar.
+
+Muy bien, repasemos nuestras herramientas:
+
+1. **Git**: Si eres usuarix de **GNU/Linux** es altamente probable que ya lo tengas instalado (puedes chequearlo en tu gestor de software o a través de la terminal con el comando `which git`). Si estás usando **Microsoft Windows** o **Mac OS**, puedes descargarlo desde [aquí](https://git-scm.com/downloads).
+
+2. **Un editor de texto**: Aunque hay muchos de ellos, sugerimos utilizar uno con soporte para el formato **Markdown** e integración con **Git**. Los editores **Kate**, **Atom** y **VSCodium**, cumplen con este criterio de forma nativa, y también son programas multiplataforma con licencias libres y de código abierto. Pero, **por razones prácticas, solo veremos cómo trabajar en Atom** (en el futuro incluiremos otras herramientas).
+
+  **Atom Text Editor**: [Descargar](https://atom.io/) · [Código fuente](https://github.com/atom/atom)
+
+
+3. **Una cuenta de Disroot Gitea**: Para poder enviar tu trabajo, necesitarás registrar una cuenta en nuestra instancia de **Gitea** (las credenciales de **Disroot** no funcionarán) y solicitar acceso a nuestro repositorio.
+
+  [**Registrar una cuenta nueva**](https://git.disroot.org/user/sign_up) en la instancia **Gitea** de **Disroot**.
+
+Una vez que tengas estas herramientas, es momento de configurarlas.

pages/04.Contribute/02.git/01.editors/01.atom/01.interface/docs.en.md

@@ -0,0 +1,63 @@
+---
+title: Interface
+published: true
+visible: true
+updated:
+        last_modified: "January 2022"
+        app: Atom Text Editor
+        app_version: 1.58.0
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - atom
+        - git
+page-toc:
+    active: true
+---
+
+# Getting familiar with Atom
+Let's start by getting to know the interface a little bit. Once we have started Atom we will see that it is quite straightforward.
+
+![](en/atom_01.png)
+
+First thing we need to do is to open the Howto project folder that we have just cloned. To do that we can either go to the **File menu** --> **Open Folder** and select the directory or directly from the **Add folders** button at the left.
+
+![](en/atom_interface.png)
+
+The left panel is the project's navigation tree and the main window is the editor where we will edit the files.
+
+![](en/navigation.gif)
+
+At the bottom is the "status bar" which displays, at the left, the path of the file we are working on and, at the right, information related to the code language, the current branch, some Git actions menu and the number of files we have modified.
+
+![](en/status.bar.png)
+
+Clicking on the **Git** button at the right side of the status bar will display the Git panel where we can view all the files we have modified as well as some Git operations that we can perform (and that we will see later on).
+
+![](en/git.panel.gif)
+
+We can also toggle the panels if we need to focus just on the text editor.
+
+![](en/panels.gif)
+
+We can activate the **Markdown preview** to have a visual idea of what are we doing on a file by pressing the keys `Ctrl` + `Shift` + `m`...
+
+![](en/preview.gif)
+
+... and we can open and work on multiple files in tabs or splitting the screen into several panels.
+
+![](en/splitted.panels.png)
+
+**Atom** is highly customizable, to the point we can tweak practically each and every one of its parts to better suit our needs.
+
+The two last things to note before we start to work are:
+
+- The unsaved files with local modifications are marked with a blue dot (depending on the theme we are using).
+
+![](en/unsaved.png)
+
+- To save the file changes we can use the **File menu** --> **Save** or the `Ctrl` + `s` keyboard shortcut.
+
+Now that we know our workspace, it is time to get down to work.

pages/04.Contribute/02.git/01.editors/01.atom/02.working/docs.en.md

@@ -0,0 +1,203 @@
+---
+title: Working with Atom + Git
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - atom
+        - git
+page-toc:
+    active: true
+---
+
+# Working with Atom + Git
+Finally we get to the most interesting part! Let's review what we have done so far.
+
+We have got an exact copy of the **Disroot Howto** folder where are all the files we can see online when we need to learn something about how a service works or how to configure a client.
+
+We have **cloned** the repository and we did it using our first git command: `git clone`. The next step will be to create a **branch**.
+
+## Creating branches
+Every git project, the Howto's project in this case, has a **main** branch (or master branch) which contains all the files we can see in *production*. The changes we make on this branch are automatically synced with the site, and become visible immediately. And that is the reason why adding any changes to this **main** branch is restricted to the owners of the project.
+
+In general terms, a branch is basically an independent workspace created from the main line of development on which we can work and test things without compromising the original code.
+
+![](en/branches.png)
+
+In the image above we have the Howto's site content represented by the main line (main). Suppose we want to translate one of its tutorials. We create a new branch (branch 1) and we start working locally on it. While we are translating, someone else wants to start writing a new howto so creates a new branch (branch 2) for that purpose. As we can see, all this happens in parallel and at the same time but without affecting the main branch.
+
+When the translation is done, it is "submitted" to the remote repository to be reviewed and integrated to the production line. In the meantime, the writing of the new howto continues and when it is ready it follows the same process, it is reviewed, updated with the changes introduced by the other branches if necessary and finally it is also integrated to the main one.
+
+OK. Let's create our branch so we can start working.
+
+In the bottom-right corner of **Atom**, click on **master** (or any other branch name) and choose **New Branch**. A good practice is to give it a name descriptive enough so that others can easily figure out what we are working on when they see it. For example, if we plan to translate the Nextcloud howto, we could call it "cloud_language_translation" or something similar.
+
+Once we are done we press **Enter** on our keyboard.
+
+![](en/atom-branch1.gif)
+
+In the terminal, we should use the `git branch` command like this:
+
+`git branch -b your.new.branch.name`
+
+To switch between branches we can also use this menu. Our current working branch is visible on the bottom bar. If we click on it other local branches will appear.
+
+![](en/atom-branch2.gif)
+
+Switching between branches in the terminal is done with the command `git checkout`. If, for example, we want to switch from our current branch to the main one, we should write:
+
+`git checkout master`
+
+And viceversa, from the main branch to our branch:
+
+`git checkout our.branch`
+
+### Publishing our branch
+We have created a local branch and we can start translating or writing a howto. For this branch we just created to also exist in the remote repository we need to **publish** it. In Atom it is done using the **Publish** function. When we click on it, we will be asked to enter our credentials. We need to enter our Gitea username and password.
+
+![](en/publish.png)
+
+In the terminal this can be done with the `git push` command, specifying the remote and the branch name we want to push. In our case it would be:
+
+`git push origin our.branch.name`
+
+When we cloned the **Howto** repository, Git automatically set up its URL as the default "remote" called `origin`. In Git a "remote" is an "alias" for a repository, so we can use this "alias" (origin in this case) instead of writing the entire URL of the remote repository every time we need to interact with it.
+
+To understand this, we can write the command `git remote -v` to see the remotes we have set up in our local repository and the URLs that they refer to.
+
+![](en/remote.png)
+
+Now that we have created a branch and already published it, we can create new files and modify the existing ones on this (our) branch.
+
+## Committing changes
+We are now on our computer translating an existing tutorial or creating a new one and we have been saving the changes we made (using `Ctrl`+`s`, for example) but those changes are only saved in our text editor. We need to **commit** them to our branch first to then "push" them to the remote repository.
+
+So, the first thing we need to understand is that a **commit** is not like doing `Ctrl`+`s` because Git is not "just a backup system". A **commit** is more like a snapshot of our project folder at a certain point. The main idea behind a version control system (Git in this case) is being able to keep track of all the changes made to our code over time so we can look back and check when, how and why it has "evolved". Every commit is, then, a "milestone" in the track history of our project. And every "milestone" is accompanied by a message which describes what has changed. We need to keep in mind that the more commits we make the more populated gets the project timeline, thus increasing the chances of generate a "confusing" record history.
+
+In a very general way, we could say a commit is a set of files created or modified on our local branch that we want to "submit" to the remote git repository.
+
+So when we have decided to create a commit we need to "tell" Git what we want to include in it.
+
+To do a "commit" of the changes is a process that consists of the following steps:
+
+1. Make sure we have saved all the modified files,
+2. "stage" those files we want to commit,
+3. write a descriptive "commit message" (a short and very specific summary of what has been changed), and finally
+4. commit the files.
+
+All the changes we have done so far in our local branch, they were made in our "working directory" and now we need to "move" them to the "staging" area. "Staging" refers to the moment in which those changes are selected to be included in the next commit.
+
+In Atom, this process is incredibly easy. Let's check the process again:
+
+![](en/committing.png)
+
+1. Make sure all files are saved and **Stage all** the files we have modified and want to commit to the repo,
+2. once they are in the "staging area" we can now
+3. write a **commit message** and finally
+4. commit the changes by clicking the **Commit** button.
+
+![](en/atom-commit.gif)
+
+Now let's see how to do the same but in the terminal.
+
+1. The Git command to "move" the files from the "working directory" to the "staging area" is `git add` and if we only have a file or two to **add** we can simply write:
+
+  `git add our.file`
+
+  But if we have several files to commit we do not need to add the changes file by file. We can use
+
+  `git add .`
+
+  and it will include all the current changes into the next commit.
+
+2. Now that the files are in the "staging area" we need to commit them. We can do that by using the `git commit` command with the option `-m` to write a commit message. For example:
+
+  `git commit -m "my commit message"`
+
+  Note that the commit message must be wrapped in quotations `"` `"`.
+
+  If we do not use the `-m` option then we will be prompted to add a message in our default text editor.
+
+  Another useful option is `-a`. It not only will automatically stages all modified files to be committed but we can also skip the `git add` command with it. For example, writing:
+
+  `git commit -a -m "my commit message"` or
+
+  `git commit -am "my commit message"`
+
+Once the files are committed, it is time to **push** (send) them to the remote repository.
+
+## Pushing the changes
+We have committed all the changes in our local branch and we want now "upload" them to the remote repository.
+
+In Atom this can be done by simply clicking on the **Push** option in the bottom bar.
+
+![](en/atom-push.gif)
+
+In the terminal, we have already seen the command to do this: `git push`. So, to push our local changes to the remote branch we have to write:
+
+`git push origin our.branch.name`
+
+## Requesting a Merge
+
+![](en/git-merge_chaos.gif)
+
+**Merging** is the process of integrating commits from different branches. Usually (but not only) the commits made on a given branch into the main one.
+
+Once we think our work is finished and ready to be published on the website, it is time to merge it to the **main branch**.
+
+This merge operation is done by the **Disroot** admins. But it is us who have to request that it be done.
+
+In **Gitea** it is called **Pull Request** and the procedure, in principle, is pretty simple.
+
+1. We go to **Disroot's Git** site at [**git.disroot.org**](https://git.disroot.org) and login with our **Gitea** credentials.
+
+2. Next we need to look for our branch in the **Howto** repository, select it and then click on the **New Pull Request** button.
+
+![](en/pull.request.gif)
+
+3. In the next page we can do a last and more visual revision of the commits we have made and, if we find it OK, then press the **New Pull Request** again.
+
+![](en/pull.request.2.png)
+
+4. Now we are required to write a "merge request" message. It does not need to be long and detailed but descriptive enough, similar to the commit message one, in order to make it easy to others to know what the changes are about. We can also (and it is recommended) add labels for better identification.
+
+![](en/pull.request.3.png)
+
+5. In the last step we can assign "Reviewers", add "Labels" (if we did not do it previously), link our Pull Request to a "Milestone" or a "Project" and define who will be assigned to manage the request (usually the same **Disroot** admins with whom we have been in contact in the Howto's XMPP room).
+
+![](en/pull.request.4.png)
+
+That's it. \O/
+
+Once the Pull Request is done, it will be reviewed by **Disroot** admins. If it is all right and the documentation meets the **Disroot** guidelines, they can approve our commits then. This means our changes will be merged with the main branch and therefore visible on the website.
+
+If there is any issue, admins could request us to correct something. And, again, once all the corrections are made, our Pull Request will be merged to the main branch.
+
+## Pulling changes from the repository
+Pull is an operation to update a local version of a remote repository.
+
+If we want to keep the local main branch for future translations or howtos we will need to "pull" the changes integrated to the recently updated remote because ours will no longer be up-to-date with the remote main one.
+
+In Atom we only need to click on the **Pull** function at the right in the status bar.
+
+![](en/atom-pull.gif)
+
+In the terminal, this is done with the command `git pull`. So if we are still on our local branch and we want to "update" it after commits were sent and accepted, we need:
+
+1. Make sure we are on the local main branch or in another. We can use the `git branch` command which will shows us the branch we are
+
+2. Once we are on the main branch, write:
+
+  `git pull`
+
+  This will download the modifications added to the main branch and update our local copy with them.
+
+Since always there are people working on the code and it changes frequently, it is highly recommended to "pull" from the remote main branch to our local one - specially before we start working on new branch - so we can easily see what is new and what has changed recently.
+
+---
+
+Check [Troubleshooting](troubleshooting) for more help and common conflict situations

pages/04.Contribute/02.git/01.editors/docs.en.md

@@ -0,0 +1,27 @@
+---
+title: "Working with Editors"
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - git
+        - editors
+        - atom
+page-toc:
+    active: true
+---
+
+# Editors
+The easiest way to work and edit the **Howto** files is through a text editor with Git integrated.
+
+As we mentioned before, for practical reasons, we will only see how to do it in **Atom Text Editor**, although you can choose to use any other. Along with every step to follow in the editor we will also see the Git commands in the terminal to learn and understand what are Atom and Git doing.
+
+We will try to add more howtos about using other editors in the future. If you want and have time, you can also write one yourself about your favorite editor and we can add it to this section.
+
+
+## [Atom](atom/interface)

pages/04.Contribute/02.git/02.Troubleshooting/docs.en.md

@@ -0,0 +1,43 @@
+---
+title: Troubleshooting
+subtitle:
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - git
+        - troubleshooting
+page-toc:
+    active: true
+---
+
+# Troubleshooting
+
+# Our local branch is "behind" the remote main branch
+While we are working on your branch, other users possibly commit and merge their own changes, especially if we are working on existing files. If those changes from the other users have already been merged to the **main branch**, the version of the files we changed may no longer be the actual ones and therefore the changes from other users may not be included in our files. In that case, if we want to let our changes be merged to the **main branch**, the process could become quite complicated.
+
+We need to update our branch **before** we **request** a **Pull** (a merge request). By doing this we will spare the admins and ourselves a lot of needless work.
+
+In Git there are two ways that allow us to integrate/merge/update branches: **git merge** and **git rebase**.
+
+**Git merge** compares the last two commits of each branch and the "common ancestor" of both branches we want to merge and creates a new commit with the changes.
+
+**Git rebase** tracks one by one the commits made on one branch and "replicates" them into other. This is helpful only if we apply it on the local commits that are not "uploaded" to any remote repository. If we do the "rebase" on a local branch which commits were already pushed to the remote one, we will surely have lots of conflicts.
+
+So if we are working on a local branch and we want to integrate to it the changes made to the remote main branch we will need to "rebase".
+
+To rebase:
+1. Make sure all the changes are committed (locally)
+
+2. In the terminal:
+ - switch to the **Main Branch**: `git checkout master`;
+ - update the **Main Branch**: `git pull`;
+ - switch back to our working branch: `git checkout our.branch`;
+ - update our working branch from the updated **Main Branch**: `git rebase master`.
+
+3. Finally, verify the changes and commit the changes to the remote repository.

pages/04.Contribute/02.git/docs.en.md

@@ -0,0 +1,86 @@
+---
+title: "Git"
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - git
+        - settings
+page-toc:
+    active: true
+---
+
+# Git?
+Yes, **Git**. It is a control version system, a software that allows us to track modifications to files, keeping a record of all the changes made, so if we need to revert to a specific version we can do it in a relatively easy way. It is also a powerful collaboration tool, since it allows many people working on the same files of a project.
+
+To learn the basics of Git and to work with it can be not only very useful but also a fun experience.
+
+
+# Scope of this tutorial
+Our use of Git doesn't require a high level of technical knowledge, anyone can learn the set of basic commands needed. And, to make it even easier, there are several text editors with Git integrated to reduce the interaction with the terminal to the minimum.<br>
+So the aim of the following tutorials is to introduce you to the basics of Git, the main tool we use to manage the **Howto** project files. Therefore, we will not cover all the aspects of its usage, only some basic concepts and commands.
+
+If you get more interested about Git, there are lots of in-depth tutorials and documentation written about it that you can easily find on the internet.
+
+
+# What does Git do?: Basic concepts
+
+![](en/git.png)
+
+When you read a **Disroot** tutorial, what you are seeing is the representation in your browser of a piece of code, in our case, a text file written in a formatting syntax called **Markdown**. The entire code of this site and its content is hosted in a **Git repository**, a folder containing all the project files and the changes history of each and every one of those files (what has changed, who has changed it and why it has changed).
+
+In this repository (or repo) there is a **main branch** (or "master branch"), which is the default project line of development and from which different other branches can be created without compromising it.
+
+Think of a tree: the "main branch" would be the trunk from which different branches "grow and develop". Once they complete their cycle, they can be integrated into the "trunk" or even "fall" from it without affecting it.
+
+So, the main branch is the one that contains the code we see online (or "in production") and the branches we create are the ones that contain our work.
+
+![](en/git_branches.png)
+
+This way, when a tutorial needs to be modified (e.g., because some software has been updated, typos were found in a document, there is information to be added/removed, etc) or translated, what we do is copy the remote repository into our machine so we can work locally on the files. This procedure is called **cloning** and once it is done, all modifications and Git operations are managed from our local repository.
+
+## Cloning the **Howto Disroot** repository
+As we mentioned before, the process of getting a copy of all the files within the project is called "**to clone**" a repository. And once we have cloned it, all modifications will be done on this copy in our local machine (most of the work is done offline).
+
+To clone the repository we just open a terminal, navigate to the directory we would like to clone the repository to, and run the `git clone` command, that is, we are "telling" git through this command to "download" it. The command is followed by the **url address** of the repo we want to clone. In our case it would be:
+
+`git clone https://git.disroot.org/Disroot/Howto`
+
+If we want to translate a page from the **Disroot Website** then we write:
+
+`git clone https://git.disroot.org/Disroot/Website`
+
+The process will then begin and in a few minutes, depending on our internet connection, we will have the repository "cloned" on our machine.
+
+![](en/cloning.png)
+
+Once this process has been completed, we will see a `Howto` (or a `Website`) directory containing all the files of the site. We can later move that directory to any place we want on our computer.
+
+Now, before we really get to work, let's setup our identity so we can move forward without distractions.
+
+## Setting your identity
+In order to be able to send our work from our machine to the remote repository, it is necessary to setup our username and email. This information is used by Git to "sign" the commits (the "snapshots" of our modifications, we will see this later on).
+
+1. We open a terminal in (or navigate to) the directory/folder where we have the cloned repository.
+
+2. Type and complete with your information the following commands:<br>
+`git config --global user.email` **user@email** `<- here goes your email address`<br>
+`git config --global user.name` **"Username"** `<- and here your username`
+
+We will not need to enter this information again.
+
+## Requesting access to the Disroot repository
+The faster and recommended way to request access is via our **Howto Chat room** at `howto@chat.disroot.org`. You can also send us an email to `howto@disroot.org`.
+
+Once admins grant you the access, you will be able to "*push*" (send) your changes to the server.
+
+!! **NOTE**<br>
+!! You could start working without access granted as all the changes happen on your local computer, and requesting it later.
+
+
+Ok. Let's move on.

pages/04.Contribute/docs.en.md

@@ -1,5 +1,5 @@
 ---
-title: How-to: Contribute
+title: How-to Contribute
 published: true
 visible: true
 updated:
@@ -14,15 +14,21 @@ page-toc:
 
 # Contribute
 
-We think that knowledge is a collective construction. In other words, knowledge is the result of working together and cooperatively, as a community.
+![](contribute.jpg)
 
-Disroot platform cost money besides our most precious value: time. While the costs of maintaining all the services working on started being covered a few months ago thanks to donations, documentation requires time.
-*"A lot of precious time..."*
+We think that knowledge is a collective construction: the result of working together and cooperatively, as a community. And whether the contributions take the form of a donation, writing/translating a tutorial or reporting bugs, they are all essentially personal time devoted to others. A bit like love.
+
+The main goal of this part of the **Disroot** project is to provide clear and accessible information about how to use and configure the services we offer and, moreover, to do so in as many languages as possible.
+It consists mostly of guides and tutorials that evolve as the software does. So we are always looking for help to check, write and translate howtos.
+
+So, for those of you who may want to contribute by donating your time and knowhow, we have tried to channel all the efforts through this section.
 
-For those users who may want to contribute to Disroot by donating their time and knowhow, we've tried to channel all the efforts through this section.
 Here you'll find basic information and guidelines for different ways to contribute, from feedback to write a how-to or translate them to your language.
 
-Thanks to all of you who support and collaborate with Disroot.
+---
 
+# Table of Contents
 
-![](contribute.png)
+## · [Howto Procedure & Tools](procedure)
+## · [Git: Configuration & set-up](git)
+## · [Working with a text editor](git/editors)