Je ne veux pas tout faire, de toute façon je ne pourrais pas, j’ai besoin d’aide, mais ce dont j’ai besoin c’est de gens motivés pour mettre les mains dans le code, que je les forme à substrate, et qu’il puisse apporter leur pierre à l’édifice, comme l’a déjà fait un peu @tuxmain, et j’espère qu’il continuera 
je ne peux pas dire à un contributeur tout ce qu’il devra faire dans les moindres détails, car le seul moyen pour moi de le savoir, c’est de le coder, je ne peux donner que l’idée générale, et des pistes sur quelles briques utilisées, mais les contributeurs doivent ensuite réfléchir par eux-mêmes et puis discuter, échanger, avec moi et les autres contributeurs, au fur et à mesure, pour préciser.
Je veux toujours tout comprendre avant d’agir, mais comprendre ne signifie pas spécifier ultra précisément. Je ne code pas dans le vide, je comprends tout ce que je fais, mais je ne découvre les détails d’implémentation que au fur et à mesure que j’écris le code.
Pour moi cela venait de plusieurs raisons, dont ton manque de disponibilité ou de disposition, à faire des visio avec les nouveaux contributeurs pour les onboarder, pour les former, et un code trop difficile à cerner.
Dans mon cas, je serais ravie de passer du temps en visio avec les intéressés pour les former et les onboarder, comme je l’ai déjà fait un peu avec tuxmain, je préfère former en one to one que coder, et je préfère coder que discuter par écrit ici.
Aussi, il me semble qu’il est beaucoup plus facile d’entrer dans le code de duniter-v2s que dans celui de duniter v1, car c’est normalisé selon le framework substrate, qu’il y a beaucoup de doc sur ce framework et beaucoup d’autres projets qui l’utilisent.
un développeur qui connait déjà substrate pourra entrer facilement dans duniter-v2s, ce qui n’était pas possible pour duniter v1.
Si tu penses que le manque de contributeurs à duniter v1 était lié à un manque de planification, je pense que tu te trompes totalement dans le diagnostic.
Je pense que les discussions que tu ouvres sur le forum sont utiles pour la plupart, c’est bien de commencer à discuter de tout ces points, par contre je suis opposé à l’idée de commencer à spécifier formellement un nouveau protocole, j’en serais capable si je codais tout from scratch, mais là on ne fait pas tout comme on veut, on dépend de substrate.
Et comme je veux que notre implémentation de duniter-v2s soit la plus simple possible, ça impliquera parfois (voir souvent), de spécifier en fonction de la manière la plus simple de faire dans le cadre de substrate, et ça je ne peux le savoir précisément qu’après avoir codé.
je pense que la bonne manière de faire c’est de partir des usages cotés utilisateur, de commencer par savoir qu’est-ce qu’on veut comme expérience utilisateurs, comme fonctionnalités métier, après on implémente ces fonctionnalités métier, ensuite on teste et on intègre les retours jusqu’à avoir quelque chose de satisfaisant.
Et enfin en dernier on spécifie formellement le comportement effectif de l’implémentation, ce qui permet de lever les ambiguïtés et de rédiger des tests plus poussés pour s’assurer que l’implémentation fait exactement ce qu’on pense qu’elle fait, c’est la phase de stabilisation, pour moi c’est la dernière phase, pas la première.
