Tu as donc trouvé quelque chose que tu aimerais améliorer dans un exercice.
Avant tout, merci de t'en soucier et de prendre le temps de nous le dire ! 💙
Quand on modifie un exercice, il y a quelques points à prendre en compte, et ils diffèrent légèrement selon qu'il s'agit d'un exercice d'apprentissage (ceux qui enseignent les sujets du programme) ou d'un exercice d'entraînement (tous les autres).
On détaille ces différences plus bas.
Mais commençons par deux ou trois points généraux à garder en tête.
Changer un exercice a des conséquences
Modifier un exercice entraîne pas mal de conséquences :
- Ajouter de nouveaux tests peut casser des solutions existantes.
Cela a pour conséquence de rendre obsolète le travail de milliers de personnes, ce qui est frustrant pour elles si les tests supplémentaires ne mettent en évidence aucun bug existant.
- On doit retester le travail de tout le monde, ce qui a un coût à la fois environnemental et financier.
- Un ou plusieurs mainteneurs doivent prendre le temps de relire les changements, ce qui signifie qu'ils ne peuvent pas apporter d'autres améliorations au parcours pendant ce temps.
Pour toutes ces raisons, on ne modifie les exercices qu'avec prudence, et seulement lorsqu'il y a un bénéfice net et identifiable.
Évite de tendre vers l'entropie
Le but des suites de tests des exercices n'est pas d'être exhaustif sur tous les cas possibles.
Nos exercices ne sont pas des logiciels de production, et ils ne sont pas conçus pour imiter des cas d'usage réels.
Ils sont conçus comme des problèmes jouets pour t'aider à gagner en aisance dans un langage de programmation.
On évite donc délibérément de couvrir chaque cas limite, d'imposer beaucoup de validation des entrées ou d'autres préoccupations de ce genre propres au monde réel.
Si ton amélioration proposée vise à attraper un cas limite ou à vérifier la validation des entrées, elle a peu de chances d'être acceptée, sauf si elle change vraiment beaucoup de choses pour l'exercice.
Exercices d'apprentissage
Les exercices d'apprentissage sont conçus dans un seul but : enseigner des concepts.
Tout changement apporté à un exercice est d'abord évalué selon qu'il améliore ou non l'enseignement des concepts.
Les exercices d'apprentissage ne sont (surtout) pas conçus pour être exhaustifs dans leurs tests.
Ils peuvent aussi souvent être un peu artificiels ou abscons afin d'éviter d'utiliser des concepts qu'un apprenant n'a pas encore appris, ou pour ne pas submerger l'apprenant.
Si le changement que tu proposes risque de détourner l'attention de l'apprentissage du concept, il sera probablement refusé.
S'il facilite l'apprentissage, il sera examiné avec la plus grande attention.
S'il se situe entre les deux, il peut être accepté, mais il est peu probable qu'il soit priorisé.
Exercices d'entraînement
Ce qu'il faut surtout comprendre à propos des exercices d'entraînement, c'est que presque tous vivent dans un dépôt central (appelé « Problem Specifications »).
Modifier un exercice a donc des répercussions sur tous les parcours.
Cela signifie qu'un bon changement est d'autant plus utile qu'il profite à tous les langages.
Mais cela alourdit aussi le changement, car plusieurs mainteneurs inter-parcours doivent l'approuver pour qu'il soit accepté, puis les mainteneurs de chaque langage doivent récupérer les changements en aval dans leurs parcours.
Modifier des exercices peut aussi rendre plus flous les concepts auxquels ils sont liés dans les programmes, ou obliger les exercices à utiliser des fonctionnalités supplémentaires pour être résolus, ce qui change l'endroit où ils se déverrouillent.
Tout cela doit également être pris en compte à l'échelle de tous les parcours avant qu'un changement soit accepté.
Même si nous avons des mécanismes permettant à seulement certains parcours d'avoir certains cas de test, nous avons tendance à les décourager, car cette divergence peut semer la confusion chez les mainteneurs comme chez les apprenants.
Donc, quand tu proposes des changements aux exercices d'entraînement, pense à la vue d'ensemble entre les parcours.
Même s'il y a beaucoup de raisons pour lesquelles nous refusons des suggestions, il arrive très souvent que les gens proposent d'excellentes idées que nous acceptons !
Nous sommes aussi presque toujours ouverts aux changements de formulation qui apportent de la clarté, en particulier dans les exercices d'apprentissage.
Pour donner à tes suggestions les meilleures chances d'être approuvées, détaille-les en montrant que tu as pris en compte les points suivants :
- L'amélioration concrète que ce changement apporte (idéalement avec des exemples de code montrant ce qu'il permet ou empêche).
- L'impact sur les solutions existantes, et pourquoi cela en vaut la peine.
- Les éventuels changements aux concepts enseignés ou utilisés.
- Une compréhension des raisons pour lesquelles les choses sont peut-être comme elles sont. (Lis notre article sur la clôture de Chesterton.)
Et surtout, n'oublie pas d'exprimer les opinions comme des opinions et les faits comme des faits.
C'est ce qui donne généralement les échanges les plus productifs.
Merci encore d'avoir pris le temps de faire une suggestion et de lire ce document !
