search

zestedesavoir / zds-site

Cœur du projet technique de Zeste de Savoir
https://zestedesavoir.com
Other
268 stars 162 forks source link

Convention dans les messages de commits #568

Closed GerardPaligot closed 10 years ago

GerardPaligot commented 10 years ago

Actuellement, les messages des commits des contributeurs ne sont pas très explicites sur les changements apportés. J'aimerais discuter sur une convention à appliquer pour ce projet. Personnellement, je suis participant de la convention initiée par AngularJS et maintenant utilisée par beaucoup de projets.

Qu'en pensez-vous ?

firm1 commented 10 years ago

Cette issue est là pour en discuter, pas pour imposer les choses. :)

Je sais pas, ça me parait couler de source. Le code ne recevra aucune (je dis bien aucune) contribution par un anglosaxon avant qu'on ne décide de s'internationaliser. Parce que le mec quand il va lancer l'application il va voir Accueil, Derniers Tutoriels, Zestes, blabla ... il pigera rien.

Il faut placer chaque conventions dans son contexte, on ne développe pas ici une lib, ni un outil spécifique, ni encore un simple forum. On développe toute une plateforme qui sera AMHA pendant ses deux premières années uniquement en langage francophone. Donc, je vois bien les avantages que ça peut avoir, mais ils sont tellement négligeables devant les inconvénients, que ça me parait juste logique de commiter en français.

cgabard commented 10 years ago

En fait ce qui me gène avec un ticket systématique c'est qu'il va falloir créer plein de meta-ticket type "correction orthographe", "completer la doc", "optimisation", etc.

Alex-D commented 10 years ago

Mon idée de base c'est d'être obligé de mettre le numéro de l'issue si elle existe.

Si c'est un truc fait en passant, osef, la discussion s'il y en a une se fera sur la PR directement.

SpaceFox commented 10 years ago

D'où ma proposition de ne pas ticketer ce qui est évident :)

La doc en particulier, me semble ne pas avoir besoin de ticket, sauf besoin très particulier. Idem pour l'orthographe, sauf le jour où on sortira toutes les clés de trads dans un vrai fichier (et de toutes façons, les 2 tickets existent déjà).

Pour l'optimisation, ça dépend. Certaines peuvent être évidentes et se faire sans ticket ; d'autres sont clairement à réfléchir (tout ce qui touche au cache en particulier).

2014-05-20 13:59 GMT+02:00 Christophe Gabard notifications@github.com:

En fait ce qui me gène avec un ticket systématique c'est qu'il va falloir créer plein de meta-ticket type "correction orthographe", "completer la doc", "optimisation", etc.

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43616283 .

cgabard commented 10 years ago

C'etait des exemples, on peut rajouter la suppression de code mort, l'ajout de commentaires sur des parties obscures, le ractoring, etc.

cgabard commented 10 years ago

Perso je préfère considérer qu'on est entre gentlemen et qu'on va insiter les contributeurs à faire des messages clairs et précis. Ce qui nous permetra de refuser des PR avec des "fix" unique. Masi de là à aller imposer des tonnes de trucs...

edit: D'autant que ce n'est pas gagné qu'on est des tonnes de contributeurs supplémentaires. Surtout qu'avant de commiter ils vont devoir comprendre le code et le modifier pour ajouter un truc ou corriger un truc avant que @firm1 soit passé par là, ils vont pas être nombreux

GerardPaligot commented 10 years ago

@SpaceFox: Quand je commit, j'essaye d'avoir 2 informations qui me semble importantes : "Quoi" et "Où“. Il m'arrive donc de référencer certaines classes, méthodes ou attributs dans mes messages de commits pour appuyer ces informations.

@firm1: C'est évident pour toi mais pas pour tout le monde. :)

Je rejoindrais la majorité mais une issue, un commit et un PR sont trois choses différentes.

SpaceFox commented 10 years ago

Quand je commit, j'essaye d'avoir 2 informations qui me semble importantes : "Quoi" et "Où“.

Ha, je comprends : je pars du principe que le "où" (d'un point de vue technique) m'est de toutes façons donné par la liste des fichiers modifiés et de leurs diffs, présents systématiquement avec le diff.

Le 20 mai 2014 14:09, Gerard notifications@github.com a écrit :

@SpaceFox https://github.com/SpaceFox: Quand je commit, j'essaye d'avoir 2 informations qui me semble importantes : "Quoi" et "Où“. Il m'arrive donc de référencer certaines classes, méthodes ou attributs dans mes messages de commits pour appuyer ces informations.

@firm1 https://github.com/firm1: C'est évident pour toi mais pas pour tout le monde. :)

Je rejoindrais la majorité mais une issue, un commit et un PR sont trois choses différentes.

  • Un commit référence une issue pour garder une historique des commits facilement (directement dans l'issue) et pour enrichir les discussions dans l'issue donnée ;
  • Un PR référence tous les commits pour une issue donnée et enrichie à son tour une issue en spécifiant son identifiant.
  • Une issue regroupe une discussion entre les contributeurs et son avancement complet du début (commits) à la fin (le merge ou non de la PR).

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/568#issuecomment-43617190 .

GerardPaligot commented 10 years ago

Il l'est mais c'est quand même plus simple quand tu le mentionnes dans le message du commit. Pour notre cas, tu évites à la personne qui va faire une review des recherches inutiles pour comprendre ce que tu as fais comme modifications et où est ce que tu les as faites.

SpaceFox commented 10 years ago

Comme tu veux.

Personnellement j'arrête de répondre ici, ça me paraît plus intéressant de mettre de l'énergie dans l'une des 86 autres issues encore ouvertes que de réfléchir à un standard de commit pour 5 développeurs.

Eskimon commented 10 years ago

BTW mettre #xxx en debut de commit a pas l'air de marcher pour referencer dans les issues... Je vous conseils donc de faire comme le commit au dessus de ce message, mettre l'issue à la fin du message...

Taluu commented 10 years ago

Il faut mettre un espace avant. Car sinon c'est considéré comme un commentaire par git.

Alex-D commented 10 years ago

(D'où le préfixe en fait :-° )

Eskimon commented 10 years ago

Ah ste boulet une fois de plus... dorenavant jle mettrais a la fin, na!

firm1 commented 10 years ago

Cette issue me semble donc résolu suite au contributing.md