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 il y a maintenant plusieurs semaines. Pourquoi avez-vous ignoré ma contribution ?¶
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 branches liées 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 la modification 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 la branche le corrrige vraiment.
Si votre contribution n’est pas destinée à être intégrée dans Django, nous n’allons pas l’ignorer mais 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 de développement à propos d’un changement qui me tient à cœur ?¶
Un message poli et écrit au bon moment sur le forum ou la branche 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 juste avant l’arrivée d’une nouvelle publication, vous ne recevrez probablement pas l’attention que vous nécessitez.
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 quelqu’un s’attelle à la relecture d’un bogue dans un endroit qu’il n’a pas touché depuis longtemps, il lui 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 des courriels personnels 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.
Mais je vous ai adressé un rappel plusieurs fois et vous continuez d’ignorer ma contribution !¶
Très sérieusement : nous ne vous ignorons pas. Si votre contribution ne convient pas pour une intégration 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 un bogue peut être ignoré pendant un moment est si ce bogue est un symptôme d’un problème plus large. Bien que nous puissions passer du temps à écrire, tester et appliquer nombre de petites modifications, 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.
Je suis certain que mon ticket est absolument parfait à 100%, puis-je le marquer moi-même comme « Ready For Checking » (prêt pour le commit) ?¶
Désolé, mais non. Il est toujours préférable qu’une autre paire d’yeux examine un ticket. Si vous peinez à obtenir cette deuxième relecture, relisez les questions ci-dessus.
