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.

I submitted a bug fix several weeks ago. Why are you ignoring my 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 ?
• If there are several branches linked to the ticket, is it clear what each one does, which ones can be ignored and which matter?
• Does the change include a unit test? If not, is there a very clear explanation why not? A test expresses succinctly what the problem is, and shows that the branch actually fixes it.

If your contribution is not suitable for inclusion in Django, we won’t ignore it – we’ll close the ticket. So if your ticket is still open, it doesn’t mean we’re ignoring you; it just means we haven’t had time to look at it yet.

When and how might I remind the team of a change I care about?

A polite, well-timed message in the forum/branch is one way to get attention. To determine the right time, you need to keep an eye on the schedule. If you post your message right before a release deadline, you’re not likely to get the sort of attention you require.

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.

But I’ve reminded you several times and you keep ignoring my contribution!

Seriously - we’re not ignoring you. If your contribution is not suitable for inclusion in Django, we will close the ticket. For all the other tickets, we need to prioritize our efforts, which means that some tickets will be addressed before others.

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.

Another reason that a bug might be ignored for a while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little changes, sometimes the right solution is to rebuild. If a rebuild or refactor of a particular component has been proposed or is underway, you may find that bugs affecting that component will not get as much attention. Again, this is a matter of prioritizing scarce resources. By concentrating on the rebuild, we can close all the little bugs at once, and hopefully prevent other little bugs from appearing in the future.

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.