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 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.
\nSi le problème ou la demande de fonctionnalité se rapporte à un élément visuel, voici quelques consignes supplémentaires à suivre :
\nInclude screenshots in your ticket which are the visual equivalent of a\nminimal test case. Show off the issue, not the crazy customizations\nyou’ve made to your browser.
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.
If you’re offering a patch that changes the look or behavior of Django’s\nUI, you must attach before and after screenshots/screencasts.\nTickets lacking these are difficult for triagers to assess quickly.
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 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.
If there’s a consensus agreement on the feature, then it’s appropriate to\ncreate a ticket. Include a link to the discussion on django-developers in the\nticket description.
\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 un fork Django sur GitHub, ajoutez une branche de fonctionnalité et montrez-nous votre code !
Voir aussi Documentation de nouvelles fonctionnalités.
\nWhenever possible, we strive for a rough consensus. To that end, we’ll often\nhave informal votes on django-developers or the Django Forum about a feature.\nIn these votes we follow the voting style invented by Apache and used on Python\nitself, where votes are given as +1, +0, -0, or -1.\nRoughly translated, these votes mean:
\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 ».
Although these votes are informal, they’ll be taken very seriously. After a\nsuitable voting period, if an obvious consensus arises we’ll follow the votes.
\nHowever, consensus is not always possible. If consensus cannot be reached, or\nif the discussion toward a consensus fizzles out without a concrete decision,\nthe decision may be deferred to the steering council.
\nInternally, the steering council will use the same voting mechanism. A\nproposition will be considered carried if:
\nThere are at least three « +1 » votes from members of the steering council.
There is no « -1 » vote from any member of the steering council.
Les votes devraient être soumis en l’espace d’une semaine.
\nSince this process allows any steering council member to veto a proposal, a\n« -1 » vote should be accompanied by an explanation of what it would take to\nconvert that « -1 » into at least a « +0 ».
\nVotes on technical matters should be announced and held in public on the\ndjango-developers mailing list or on the Django Forum.
\n