Il est bien sûr possible de contribuer directement sur la documentation de YunoHost, mais ce n’est pas la manière la plus pratique de le faire tant pour le·la contributeur·rice que pour la personne qui va injecter votre contribution dans la documentation. Voici un tutoriel pour comprendre et créer une contribution à la documentation de YunoHost en utilisant l’outil [Git (en)](https://git-scm.com/) et [github.com](http://github.com/) qui est le service de forge Git qui héberge et stocke le code source de YunoHost ainsi que sa documentation.
Pour pouvoir envoyer vos contributions via GitHub, il est nécessaire d’avoir un compte sur GitHub. Pour créer le compte vous aurez besoin d’une adresse e-mail valide à laquelle vous avez accès. GitHub est un outil puissant qui propose de nombreuses fonctionnalités, l’interface peut être un peu effrayante au début.
Vous n’êtes pas obligé·e de donner vos noms et prénoms, vous pouvez utiliser un pseudonyme (lors de l’inscription `Username`).
Forker le code source permet de créer une nouvelle branche de développement d’un code source de logiciel ou dans le cas présent, le code source de la documentation. En créant une nouvelle branche, cela vous permet de modifier le code et d’ajouter vos contributions sans altérer le code de la branche `master` qui est le rendu public de la documentation. Ce qui vous permet de ne pas devoir tout marquer mais le faire en plusieurs étapes. (Notamment pour les contributions demandant plus de temps de travail).
> Si vous forkez le dépôt d’un·e autre contributeur·rice que YunoHost, vous aurez les mêmes fichiers. Sauf que quand vous enverrez vos modifications, elles seront envoyées au contributeur et non au dépôt YunoHost. L’avantage est que ça vous permet de développer une autre branche créée par le·la contributeur·rice et ainsi travailler avec une autre personne à une amélioration avant proposition au dépôt principal.
Une fois le dépôt forké (copié), il faudra créer une nouvelle branche de développement au sein de votre dépôt. C’est à travers cette branche que vous allez modifier les fichiers et ainsi proposer des améliorations de la documentation. Le fait que ce soit une nouvelle branche vous permettra par la suite de faire une Pull Request, c’est à dire une demande d’ajout de vos contributions au sein de la branche `master` qui est la branche principale de la documentation. Les règles de développement sur GitHub changent selon les développeurs de chaque dépôt, certains ont une branche testing dans laquelle il faut proposer les contributions.
Plus d’informations sur ce qu’est une branche sur git-scm.com : [Les branches avec Git - Ce qu’est une branche](https://git-scm.com/book/fr/v1/Les-branches-avec-Git-Ce-qu-est-une-branche).
Faire une Pull Request correspond au moment où vous souhaitez partager votre travail avec le reste des contributeurs⋅rices et l’intégrer au dépot master (dépôt principal de YunoHost). Lors de la publication d’une Pull Request, couramment nommée PR, les contributeurs⋅rices pourront amender, commenter, ajouter, corriger votre contribution avant intégration complète au dépôt.
Lorsque vous avez déjà fait une PR (Pull Request), les modifications de votre branche de développement sur le dépôt Git se rajouteront automatiquement à la PR. Cela ne nécessite aucune action supplémentaire. Vous pouvez aussi intégrer les propositions de modifications de contributeurs, qui lorsqu’ils·elles auditeront le code, peuvent trouver des erreurs ou de nouvelles formulations plus adaptées.
YunoHost dispose d’un dépôt Git spécifique pour le recueil des issues : [github.com/YunoHost/issues](https://github.com/YunoHost/issues)
Une issue aussi appelé ticket, est un problème identifié ou alors un souhait de développement ; dans le cas présent pour la documentation, mais c’est valable pour tout dépôt logiciel. Dans le cadre de la documentation de YunoHost il sera surtout proposé des issues pour le développement de la documentation, les problèmes identifiés étant facilement corrigeables.
Utiliser la puissance de Git et ainsi travailler sur son ordinateur personnel, permet entre autres de ne pas avoir à créer de `commit` à chaque enregistrement intermédiaire des pages de documentations modifiées. Cela permet aussi d’utiliser des outils et logiciels qui permettent une distinction plus facile des codes utilisés dans une page de documentation.
- Ressource en ligne : [docs.microsoft.com - Configurer un référentiel Git localement pour la documentation](https://docs.microsoft.com/fr-fr/contribute/get-started-setup-local)
