FAQ : contribution au code¶
Comment puis-je commencer à contribuer au code de Django ?¶
Merci d’avoir posé la question ! Nous avons écrit une documentation complète sur cette question. Elle se nomme Contribution à Django.
J’ai soumis un correctif dans le système de tickets il y a maintenant plusieurs semaines. Pourquoi avez-vous ignoré mon correctif ?¶
Ne vous inquiétez pas : nous ne vous ignorons pas !
Il est important de comprendre la différence entre « le ticket est ignoré » et « le ticket n’a pas encore été traité ». Le système de tickets de Django contient des centaines de tickets ouverts, avec divers degrés d’impact sur la fonctionnalité de l’utilisateur final, et les développeurs de Django doivent les analyser et les classer par priorité.
En plus de cela, les personnes travaillant sur Django sont toutes volontaires. Par conséquent, le temps qu’elles consacrent à travailler sur Django est limité et varie chaque semaine en fonction de leur temps libre. Si elles sont occupées, elles ne peuvent pas passer autant de temps sur Django qu’elles le voudraient.
La meilleure façon de s’assurer que les tickets ne soient pas abandonnés en cours de route est de les rendre facile à comprendre et à vérifier, même pour quelqu’un qui n’est pas très familier avec la zone du code concernée :
Y a t’il des instructions détaillées sur la manière de reproduire un bug ? Si cela affecte une librarie (telle que Pillow), un module contrib, ou une base de données spécifique, les instructions sont elles assez précises même pour quelqu’un qui n’y est pas familier ?
S’il y a plusieurs correctifs joints au ticket, est-ce qu’il est facile de voir ce que chaque correctif fait, lesquels peuvent être ignorés et lesquels sont intéressants ?
Est-ce que le correctif inclut des tests unitaires ? Sinon, est-ce qu’il y a une explication précise du pourquoi ? Un test explique succinctement la nature du problème et montre que le correctif le règle vraiment.
Si votre correctif n’a aucune chance d’être inclus dans Django, nous n’allons pas l’ignorer mais juste fermer le ticket. Donc si votre ticket est toujours ouvert, cela ne signifie pas que l’on vous ignore ; nous n’avons juste pas encore eu le temps de l’examiner.
Quand et comment devrais-je relancer l’équipe principale à propos d’un correctif qui me tient à cœur ?¶
Un message poli et adressé au bon moment à la liste de diffusion est une des manières d’obtenir l’attention. Pour déterminer le bon moment, vous devez garder un œil sur la planification. Si vous envoyez un message lorsque les principaux développeurs tentent de respecter une date butoir pour une fonctionnalité ou qu’ils essayent de gérer une phase de planification, vous ne recevrez pas l’attention que vous nécessitez. En revanche, si vous attirez l’attention sur un ticket lorsque les principaux développeurs prêtent une attention particulière aux bogues – juste avant un sprint de correction de bogues, ou à l’approche de la publication d’une version bêta par exemple – vous aurez beaucoup plus de chances d’obtenir une réponse constructive.
De subtils rappels sur IRC peuvent aussi fonctionner – encore une fois, stratégiquement placés dans le temps. Par exemple durant un sprint de résolution de bogues.
Une autre manière de susciter l’attention consiste à regrouper plusieurs tickets liés. Lorsque les développeurs principaux s’attellent à la correction d’un bogue dans un endroit qu’ils n’ont pas touché depuis longtemps, il leur faut du temps pour se souvenir de tous les petits détails du fonctionnement de cette zone du code. Si vous regroupez plusieurs corrections de bogues mineurs aux thèmes communs, vous créez une cible attrayante, puisque le coût pour se remettre à jour sur une zone du code peut être étalé sur plusieurs tickets.
Retenez-vous d’envoyer un courriel aux principaux développeurs personnellement, ou de faire remonter le même problème de façon répétée. Ce genre de comportement ne vous apportera pas plus d’attention – et certainement pas le type d’attention dont vous avez besoin pour traiter votre bogue préféré.
Mais je vous ai adressé un rappel plusieurs fois et vous continuez d’ignorer mon correctif !¶
Très sérieusement : nous ne vous ignorons pas. Si votre correctif n’a aucune chance d’être inclus dans Django, nous fermerons le ticket. Pour tous les autres tickets, nous devons prioriser nos efforts, ce qui signifie parfois que certains tickets seront traités après certains autres.
L’un des critères utilisés pour prioriser les corrections de bogues est le nombre de personnes qui seront probablement affectées par un bogue donné. Les bogues qui peuvent potentiellement affecter de nombreuses personnes recevront généralement la priorité par rapport à des bogues plus marginaux.
Une autre raison pour laquelle des bogues peuvent être ignorés pendant un moment est si le bogue est un symptôme d’un problème plus large. Bien que nous puissions passer du temps à écrire, tester et appliquer nombre de petits correctifs, quelquefois la bonne solution est de reconstruire. Si une reconstruction ou une refactorisation d’un composant particulier a été proposée ou est en cours, vous constaterez que des bogues affectant ce composant ne recevront que peu d’attention. Encore une fois, cela est uniquement pour des raisons de priorisation de ressources rares. En nous concentrant sur la reconstruction, nous pouvons fermer tous les petits bogues d’un seul coup, et avec un peu de chance prévenir d’autres petits bogues de faire leur apparition dans le futur.
Peu importe la raison, gardez s’il vous plaît à l’esprit que bien que vous puissiez rencontrer régulièrement un bogue en particulier, cela ne veut pas forcément dire que chaque utilisateur de Django rencontrera le même bogue. Différentes personnes utilisent Django de différentes manières, mettent sous contraintes différentes parties du code dans des conditions différentes. Lorsque nous évaluons les priorités relatives, nous essayons généralement de considérer les besoins de la communauté toute entière, pas seulement la sévérité pour un utilisateur en particulier. Cela ne signifie pas que nous pensons que votre problème n’est pas important – seulement que dans le temps limité à notre disposition, nous privilégierons toujours la possibilité de satisfaire 10 personnes plutôt qu’une seule.
