Συχνές Ερωτήσεις: Συνεισφέροντας κώδικα¶

Πως μπορώ να ξεκινήσω να συνεισφέρω κώδικα στο Django;¶

Ευχαριστούμε για την ερώτηση! Έχουμε γράψει ολόκληρο άρθρο αφιερωμένο για αυτήν ακριβώς την ερώτηση. Έχει τον τίτλο Συνεισφέροντας στο Django.

I submitted a bug fix several weeks ago. Why are you ignoring my contribution?¶

Μην ανησυχείτε: Δε σας αγνοούμε!

Είναι σημαντικό να καταλάβετε τη διαφορά μεταξύ «ενός ticket το οποίο αγνοείται» και «ενός ticket στο οποίο δεν έχει δοθεί προσοχή ακόμα». Το ticket system του Django περιέχει εκατοντάδες ανοικτά tickets (open tickets), πάνω σε διάφορους τομείς που οι developers του Django πρέπει να τα επιθεωρήσουν (review) και να τους αναθέσουν τις κατάλληλες προτεραιότητες (prioritize).

Εκτός αυτού, οι άνθρωποι που δουλεύουν για το Django είναι όλοι εθελοντές. Ως αποτέλεσμα αυτού, ο χρόνος που απαιτείται για την αφιέρωση στο framework είναι περιορισμένος και θα διαφέρει από βδομάδα σε βδομάδα αναλόγως τον ελεύθερο χρόνο μας. Αν είμαστε απασχολημένοι, ίσως να μην μπορέσουμε να αφιερώσουμε τον χρόνο που θέλουμε στο Django.

Ο καλύτερος τρόπος να σιγουρευτείτε ότι τα tickets δεν “κρεμάνε” κατά το checkin είναι να κάνετε πολύ κατανοητό, ακόμη και γι” αυτούς που δεν είναι εξοικειωμένοι με αυτό το κομμάτι του κώδικα, το πρόβλημα και να επιβεβαιώσετε το fix:

• Υπάρχουν ξεκάθαρες οδηγίες για το πως να αναπαραχθεί το σφάλμα (bug); Αν το σφάλμα επηρεάζει κάποιο dependency (όπως το Pillow), ένα contrib module, ή κάποια συγκεκριμένη βάση δεδομένων, είναι οι οδηγίες αρκετά ξεκάθαρες ούτως ώστε να τις διαβάσει κάποιος ο οποίος δεν είναι εξοικειωμένος με αυτό;

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

Gentle reminders in the #contributing-getting-started channel in the Django Discord server can work.

Another way to get traction is to pull several related tickets together. When someone sits down to review a bug in an area they haven’t touched for a while, it can take a few minutes to remember all the fine details of how that area of code works. If you collect several minor bug fixes together into a similarly themed group, you make an attractive target, as the cost of coming up to speed on an area of code can be spread over multiple tickets.

Please refrain from emailing anyone personally or repeatedly raising the same issue over and over again. This sort of behavior will not gain you any additional attention – certainly not the attention that you need in order to get your issue addressed.

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.

Ένα από τα κριτήρια τα οποία χρησιμοποιούμε για να θέσουμε προτεραιότητες στα bug fixes είναι ο αριθμός των ανθρώπων που θα επηρεαστούν από το συγκεκριμένο bug. Τα bugs που ενδεχομένως να επηρεάζουν αρκετό κόσμο θα πάρουν προτεραιότητα εν συγκρίσει με τις ακραίες περιπτώσεις.

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.

Whatever the reason, please keep in mind that while you may hit a particular bug regularly, it doesn’t necessarily follow that every single Django user will hit the same bug. Different users use Django in different ways, stressing different parts of the code under different conditions. When we evaluate the relative priorities, we are generally trying to consider the needs of the entire community, instead of prioritizing the impact on one particular user. This doesn’t mean that we think your problem is unimportant – just that in the limited time we have available, we will always err on the side of making 10 people happy rather than making a single person happy.

I’m sure my ticket is absolutely 100% perfect, can I mark it as «Ready For Checkin» myself?¶

Sorry, no. It’s always better to get another set of eyes on a ticket. If you’re having trouble getting that second set of eyes, see questions above.