Signalement d’anomalies ou demandes de fonctionnalités

Important

Veuillez signaler les problèmes de sécurité uniquement à l’adresse [e-mail]. C’est une liste privée uniquement ouverte à des développeurs Django de longue date et extrêmement fiables, et ses archives ne sont pas publiques. Pour plus de détails, veuillez consulter nos politiques de sécurité.

Sinon, avant de signaler une anomalie ou de demander une nouvelle fonctionnalité dans le suivi des tickets, tenez compte des point suivants :

• Vé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 le forum Django ou 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 le forum Django ou la liste django-developers.

Signalement d’anomalies

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 :

• Lisez 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 rapidement la validité du problème rencontré.
• N’écrivez pas à django-developers seulement 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.

Signalement d’anomalies ou de fonctionnalités de l’interface utilisateur

Si le problème ou la demande de fonctionnalité se rapporte à un élément visuel, voici quelques consignes supplémentaires à suivre :

• Incluez 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.

Demandes de fonctionnalités

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 :

• Vé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 le forum Django ou 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 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 pourquoi vous souhaitez cette fonctionnalité. En présentant un cas d’utilisation minimal, cela aidera d’autres à comprendre le contexte de la demande et s’il existe déjà d’autres manières d’arriver au même résultat.

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.

Comme 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 un fork Django sur GitHub, ajoutez une branche de fonctionnalité et montrez-nous votre code !

Voir aussi Documentation de nouvelles fonctionnalités.

Comment nous prenons des décisions

Autant que possible, nous visons à obtenir un consensus général. Dans ce but, il arrive fréquemment que des votes informels au sujet d’une fonctionnalité aient lieu sur la liste django-developers ou sur le forum Django. 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 :

• +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 ces votes soient informels, ils sont pris très au sérieux. Après une période de vote raisonnable et si un consensus clair se dessine, nous suivons les votes.

Cependant, 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é de pilotage.

En interne, le comité de pilotage utilise le même mécanisme de vote. Une proposition sera considérée comme validée si :

• Il y a au moins trois votes « +1 » des membres du comité de pilotage.
• Il y n’y a aucun vote « -1 » des membres du comité de pilotage.

Les votes devraient être soumis en l’espace d’une semaine.

Étant donné que ce processus permet à tout membre du comité de pilotage 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.

Les votes sur les questions techniques devraient être annoncés et tenus en public sur la liste de diffusion django-developers ou sur le forum Django.