# ADSILLH - projet tuteuré

## 1.Consignes - bonnes pratiques

### Ressources:
* Comment contribuer à un logiciel libre?
http://www.7avoir.net/2020/07/comment-contribuer-aux-developpement-de-logiciels-open-source.html

### Consignes:
* projet anglophone à l'écrit
* code source existant (plongée dans code existant)
* plonger dans le code source avant la première intégration avec le(s) mainteneur(s)

---

## 2.Choix du logiciel libre auquel contribuer

### 2.a. Intérêts personnels et groupe de travail
#### Intérêt personnel d'Habib:
A priori: choisir le logiciel libre d'une communauté qui comprend des contributeurs intéressés par les questions de vivre ensemble (et qui pourraient 6etre intéressés par le projet Château-Phare de [Tedua](https://association-tedua.fr) pour nous aider).

#### Intérêt personnel de [écris ton prénom ici si tu es intéressé.e]
Lorem ipsum ................................

### 2.b. Liste de logiciels:
* https://github.com/framasoft/mobilizon
* interactive storytelling
* http://povmagazine.com/articles/view/4-tools-for-creating-interactive-docs
* https://directorsnotes.com/2016/08/08/interactive-documentary-guide/
* https://en.wikipedia.org/wiki/Web_documentary

---

## 3. OUTILS pour contribuer

Avec Alexis Lahouze - SysNove

### 3.a. Pourquoi contribuer?

- AMÉLIORER:
- documentation
- traductions
- corriger bugs/anomalies

- APPRENDRE:
- découvrir les techniques des autres devs, expérience
- confiance en soi (soumettre des améliorations, recevoir des retours)

- PARTAGER:
- faire profiter les autres: donnant-donnant

### 3.b. Quel logiciel ? Quand et Comment contribuer?

1) Choisir un logiciel qu'on utilise déjà de préférence, vraiment! beaucoup + simple de comprendre son fonctionnement en découvrant son code source, et donc de contribuer.

2) Quand contribuer: dès que possible

3) Comment contribuer?
- se préparer:
- prise de notes
- imprecrans au fil de l'eau
- éviter de se reposer les mêmes questions lors d'une ré-installation
- trouver/récupérer les sources:
- forge logicielle publique
- download .tar.gz:
- penser à garder une copie de l'arborescence originale qui servira de point de départ pour la création du patch. permet de faire la ifférence entre le répertoire original et le répertoire de travail

### 3.c. Méthode pour proposer une amélioration de code:
1) lire la doc du projet
2) installer les dépendances
3) déterminer la toolchain
- "autotools": `./configure && make`
- `CMake` (plus simple): `cd build && cmake .. && make`
- parfois juste un fichier Makefile : `make`
- NodeJS, Python , Ruby: pas forcément de build (scripts interprétés)
- **options de debug**: voir la doc du projet

### 3.d. Cibler l'endroit à modifier dans un code source
- rajouter des **traces** : commande `print()` par exemple
- ou utiliser un debuger (selon langage)

### 3.e. Modifier le code
- suivre les indications de style (indentations, accolades...)
- voir **linting** éventuel
- à chaque modification percue, faire un` commit` (le plus souvent possible), C'est un équilibre à trouver:
- comme ca on peut revenir en arrière sur un commit

### 3.f.Tester le nouveau code
- tests unitaires
- tests fonctionnels

### 3.g. Diff et patch
Voir la photo sur smartphone d'Habib

POur voric haque modification apportée et voir choisir si on veut les ajouter ou pas
`git add -p [nomdufichier]`
Puis:
`s` (pour split: séparer les modifs à ajouter pour els traiter une par une)
`y` (pour yes : ajout)
`n` (pour no: on n'ajoute pas la modif)

Affichage en vert = chache mis à jour

`git diff --cached`

Autres commandes utiles:
`git branch --list` : pour voir les branches existantes
`git branch master` :a jour d'une branche master
`git branch v2 `: ajout d'une branche v2
`git checkout v2` : basculement sur la branche v2
`tig` : logs des changements

`git merge` ou `git mergetool` pour la gestion de conflits (differentes versions de part et d'autre : LOCAL: master/BASE /REMOTE :v2)

>>>>>>>>> : marque la fin d'un conflit

### 3.h. Envoi du patch
- envoi par **mail avec patch en PJ** directement
- **bugtracker**: nouveau ticket ou réponse à ticket existant lié au bug corrigé pour le suivi
- pull request sur github

### 3.i. Netiquette
RFC 1855 : https://tools.ietf.org/html/rfc1855

---

### Git (ou Suversion)
Git tool

### Branches

/---TRUNK (branche principale)

Branches
7.1
fix_log XX

Releases
7.1.1
7.2.0