Tout d’abord, c’est une attitude très dictatoriale, et si je suis d’accord avec le fait qu’un projet doit être dirigé par un dictateur bienveillant, je ne suis pas à l’aise avec l’idée d’écarter aussi radicalement les autres contributeurs de mes travaux.

De plus, ce processus est complètement différent de celui suivi par les contributeurs, puisqu’ils ajoutent leur code à celui d’atoum via le mécanisme de pull request de Github, et je ne pense pas que le fait d’être le créateur d’atoum me donne le droit de déroger aux règles que je demande aux autres d’appliquer.

Mais surtout, ce processus de développement implique que je ne peux bénéficier d’aucun retour technique ou fonctionnel de la part des contributeurs ou des utilisateurs à propos de mon code avant que je ne décide de le diffuser.

En conséquence, je me prive d’un feedback qui pourrait m’être très utile pour rendre atoum encore plus simple, moderne et intuitif, même s’il arrive souvent que je discute des fonctionnalités sur lesquelles je suis en train de travailler sur le canal IRC du projet.

J'ai donc modifié depuis quelques jours ma façon de travailler sur atoum.

Je commence dorénavant par créer une issue décrivant la fonctionnalité que je compte ajouter ou l’évolution que je compte effectuer, ce qui permet à tout le monde de donner son opinion à son sujet.

Et à l’avenir, mon code sera ajouté au projet après être passé par l’étape pull request afin qu’il fasse l’objet (du moins, je l’espère) d’une revue poussée avant d’être fusionné définitivement dans celui d’atoum.

Cerise sur le gâteau, cela me permettra de garder une trace de mes développement en cours.

En effet, j’avais laissé plusieurs d’entre eux en attente lorsque je suis parti en vacances dernièrement, et à mon retour, j’ai eu le plus grand mal à m’y retrouver, voir même à simplement à me souvenir de l’objectif final de certains.

J’espère donc que cette nouvelle façon de travailler sur atoum me permettra d’éviter ce genre de désagrément à l’avenir.