Cette information se trouve dans l’issue associée, sur laquelle j’avais mis à plat mes réflexions sur la conception en me répondant régulièrement à moi-même.
Tu trouveras d’autres issues, dont certaines encore ouvertes, où je couche par écrit l’état de mes réflexions de la même façon 
Au contraire j’ai volontairement modifié le workflow pour forcer le squash, c’est le seul moyen que j’ai trouvé pour permettre de déplacer coté mainteneur la responsabilité du nommage des commits qui finiront sur la branche principale, car le nom du commit final peut alors être choisi par le mainteneur juste avent de merger, sans avoir besoin de push force.
Sans le squash, j’exclue toute contribution des personnes qui ne maîtrise pas assez bien git, comme @vincentux par exemple, c’est d’ailleurs la 1er MR de vincentux qui m’a définitivement convaincu d’adopter ce nouveau workflow, auquel je réfléchissais depuis déjà quelques mois.
Ce nouveau workflow me conviens beaucoup mieux, je ne compte pas revenir en arrière
La liste originale des commits reste trackée par gitlab:
Ce sont des commits de travail, qui peuvent être mal faits, et qui ne sont pas censer apporter d’informations utiles pérennes.
S’il te manque des informations, c’est que le code n’est pas assez commenté où/et qu’il n’y a pas assez de documentation. Ajouter de la documentation est une bonne 1ère contribution, j’avais commencé comme ça pour rentrer dans duniter V1