Contribuer

Les contributions utiles naissent presque toujours du même point de départ : quelqu'un tombe sur quelque chose. Une page se comporte autrement que prévu, un réglage ne fait pas ce que le manuel laissait entendre, une phrase de la documentation se lit de deux façons, une étape suppose un accès que vous n'avez pas. C'est de cela qu'un projet meilleur est fait — et décrire clairement l'un de ces points est déjà une contribution.

Vous n'avez rien à réparer pour aider. Un récit précis de ce que vous attendiez, de ce qui s'est produit et du document que vous suiviez vaut souvent plus qu'un correctif, parce qu'il montre en quoi consiste réellement le travail.

Une contribution est une proposition, et ce sont les personnes qui maintiennent le projet qui décident de ce qu'elles acceptent. Une modification peut être reprise telle quelle, ajustée, mise en attente ou refusée : parce qu'elle ne correspond pas à la raison d'être du projet, parce qu'elle déplacerait une limite tracée volontairement, parce qu'elle n'est pas correcte, ou simplement parce que personne n'a encore eu le temps de l'examiner.

Ce que cela ne change pas, c'est votre propre copie. La licence vous donne déjà le droit de modifier le logiciel pour vous et de distribuer votre propre version, sans l'accord de quiconque. Renvoyer une amélioration au projet est ce qui la rend utile à tous les autres : c'est pourquoi on le fait, et pourquoi personne n'y est tenu.

Ce que vous attendiez et ce qui s'est produit. L'écart entre les deux, c'est le défaut. « J'ai changé de langue et le sélecteur est resté en anglais » dit quelque chose ; « le site est cassé » ne dit rien.

Où cela se produit. La version de Foundation qu'utilise le site, la page ou la route et — si un seul langage est concerné — ce langage. Un défaut dans une langue et un défaut dans toutes sont deux travaux différents.

Ce que vous avez modifié. Un projet Foundation neuf et un site adapté sont deux cas différents : un défaut de la plateforme et un défaut du site construit sur elle ne se traitent pas de la même façon.

Le message tel quel. Le texte de l'erreur est souvent le chemin le plus court vers la cause, et le reformuler supprime justement les détails qui comptent.

Ce que vous avez déjà essayé. Cela évite de refaire le même travail et montre parfois que la documentation a conduit dans la mauvaise direction : c'est aussi un défaut, mais un défaut de documentation.

Si vous souhaitez apporter du travail technique et pas seulement signaler quelque chose, les attentes du projet se trouvent dans le dépôt, et elles valent la lecture avant d'investir du temps dans une modification. Trois documents les rassemblent : les règles de fonctionnement pour les agents de programmation décrivent comment on travaille dans une installation Foundation ; l'architecture expose les couches, les limites et le sens des dépendances ; le manuel de validation fixe ce qu'une vérification doit démontrer — y compris la règle selon laquelle aucune capacité ne peut être annoncée au-delà du niveau que son implémentation et ses tests vérifient réellement.

Ces documents relèvent de la discipline de maintenance du projet, non d'un règlement de contribution. Ils ne disent rien de ce que vous pouvez faire de votre propre copie : c'est la licence qui le règle. Ils décrivent ce qui maintient ce code cohérent et ils sont honnêtes sur la capacité disponible : un petit nombre de responsables examine ce qui arrive, et une modification accompagnée de ses propres tests, décrivant clairement le problème résolu et sans changements étrangers au sujet a bien plus de chances d'être reprise qu'une autre qui laisse à d'autres le travail de la comprendre.