Sinon, avant de signaler une anomalie ou de demander une nouvelle fonctionnalité dans le suivi des tickets, tenez compte des point suivants :
\nVérifiez que quelqu’un n’a pas déjà signalé le problème ou demandé la fonctionnalité en cherchant ou en exécutant des requêtes personnalisées dans notre système de tickets.
N’utilisez pas le système des tickets pour poser des questions d’aide. Utilisez la liste django-users ou le canal IRC #django à cet effet.
Ne réouvrez pas des rapports qui ont été marqués comme wontfix sans d’abord chercher un consensus sur la liste django-developers.
N’utilisez pas le système des tickets pour de longues discussions, car elles risquent de se perdre. Si un ticket particulier est sujet à controverse, veuillez faire passer la discussion sur la liste django-developers.
Des rapports d’anomalies bien écrits sont extrêmement utiles. Cependant, il y a toujours un certain travail à effectuer dans un système de gestion des anomalies, votre aide pour conserver notre système utilisable est donc appréciée. En particulier :
\nLisez la FAQ pour voir si votre problème n’est pas une question régulièrement posée.
Demandez d’abord sur django-users ou #django si vous n’êtes pas sûr que ce que vous voyez est réellement une anomalie.
Écrivez des rapports d’anomalies complets, reproductibles et précis. Vous devez inclure une description claire et concise du problème ainsi qu’une série d’instructions pour le reproduire. Ajoutez autant d’informations de débogage que possible : extraits de code, cas de test, traces d’exceptions, captures d’écran, etc. Un petit cas de test bien fait est la meilleure manière de signaler une anomalie, car cela permet de confirmer facilement et rapidement la validité du problème rencontré.
N’écrivez pas à django-developers simplement pour annoncer que vous avez rédigé un rapport d’anomalie. Tous les tickets apparaissent dans une autre liste, django-updates, qui est suivie par les développeurs et les membres intéressés de la communauté ; nous les voyons au fur et à mesure de leur création.
Pour comprendre le cycle de vie d’un ticket après sa création, consultez Tri des tickets.
\nSi le problème ou la demande de fonctionnalité se rapporte à un élément visuel, voici quelques consignes supplémentaires à suivre :
\nIncluez des captures d’écran dans le ticket, ce qui correspond à l’équivalent visuel d’un cas de test minimal. Mettez en évidence le problème, pas les personnalisations incroyables que vous avez appliquées à votre navigateur.
Si le problème est difficile à démontrer par une image figée, envisagez de capturer une brève séquence vidéo. Si votre logiciel le permet, ne capturez que la partie significative de l’écran.
Si vous proposez un correctif qui modifie l’apparence ou le comportement de l’interface de Django, vous devez joindre les captures avant et après. Les tickets qui ne possèdent pas ces éléments sont difficiles à traiter rapidement par ceux qui classent les tickets.
Les captures d’écran ne dispensent pas des autres bonnes pratiques de signalement. Prenez soin d’inclure des URL, des extraits de code et des instructions pas à pas sur la façon de reproduire les comportements visibles dans les captures d’écran.
Prenez soin de cocher l’option UI/UX du ticket afin que les personnes les plus concernées puissent trouver votre ticket.
Nous essayons de constamment améliorer Django, et vos demandes de fonctionnalités constituent un élément clé de ce processus. Voici quelques astuces pour rédiger une demande de la manière la plus efficace possible :
\nVérifiez que la fonctionnalité demande effectivement des modifications dans le cœur de Django. SI votre idée peut être développée en tant qu’application ou module indépendant, par exemple pour ajouter la prise en charge d’un nouveau moteur de base de données, on vous suggérera certainement de la développer de manière indépendante. Puis, si le projet obtient suffisamment de soutien de la communauté, il pourra être considéré comme candidat à l’inclusion dans Django.
Parlez d’abord de la fonctionnalité sur la liste de diffusion django-developers, et non dans le système des tickets. L’audience sera plus large sur la liste. C’est d’autant plus important si la demande de fonctionnalité est d’une certaine ampleur. Les développeurs de Django apprécient de discuter premièrement des changements importants sur la liste de diffusion avant de commencer à travailler concrètement sur le code.
Décrivez clairement et courtement la fonctionnalité manquante et la manière dont vous souhaiteriez qu’elle soit implémentée. Ajoutez si possible du code d’exemple (même non fonctionnel).
Expliquez le pourquoi de la fonctionnalité. Dans certains cas, c’est évident, mais comme Django est conçu pour aider des développeurs réels à travailler sur des projets réels, il faudra expliquer la fonctionnalité dans le cas où son utilité n’est pas si évidente que cela.
S’il existe un consensus concernant la fonctionnalité, il convient alors de créer un ticket. Ajoutez dans la description du ticket le lien vers la discussion sur django-developers.
\nComme pour la plupart des projets de logiciels libres, le code parle. Si vous êtes disposé à écrire vous-même le code de la fonctionnalité ou même mieux, si vous l’avez déjà écrit, les probabilités de son acceptation sont encore plus fortes. Créez simplement un fork Django sur GitHub, ajoutez une branche de fonctionnalité et montrez-nous votre code !
Voir aussi Documenting new features.
\nAutant que possible, nous visons à obtenir un consensus général. Dans ce but, il arrive fréquemment que des votes informels aient lieu sur la liste django-developers au sujet d’une fonctionnalité. Dans ces votes, nous suivons le style de vote initié par Apache et aussi utilisé pour Python, où les votes sont donnés comme +1, +0, -0 ou -1. Grossièrement traduits, ces votes signifient :
\n+1 : « J’aime bien l’idée et je l’appuie sans réserve ».
+0 : « Ça me semble OK ».
-0 : « Je ne suis pas convaincu, mais je n’ai pas l’intention de m’y opposer ».
-1 : « Je désapprouve fortement et je serai contrarié de voir l’idée se concrétiser ».
Bien que les votes sur django-developers soient informels, ils seront pris très au sérieux. Après une période de vote raisonnable et si un consensus clair se dessine, nous suivrons les votes.
\nCependant, le consensus n’est pas toujours possible. Si le consensus ne peut pas être obtenu ou si la discussion en vue d’un consensus s’éternise sans décision concrète, la décision peut être déférée au comité technique.
\nEn interne, le comité technique utilise le même mécanisme de vote. Une proposition sera considérée comme validée si :
\nIl y a au moins trois votes « +1 » des membres du comité technique.
Il y n’y a aucun vote « -1 » des membres du comité technique.
Les votes devraient être soumis en l’espace d’une semaine.
\nÉtant donné que ce processus permet à tout membre du comité technique d’opposer un veto à une proposition, un vote « -1 » doit obligatoirement être accompagné d’une explication de ce qui est nécessaire pour transformer ce « -1 » en « +0 » à minima.
\nLes votes sur les questions techniques devraient être annoncés et tenus en public sur la liste de diffusion django-developers.
\n