Συχνές Ερωτήσεις: Συνεισφέροντας κώδικα¶
Πως μπορώ να ξεκινήσω να συνεισφέρω κώδικα στο Django;¶
Ευχαριστούμε για την ερώτηση! Έχουμε γράψει ολόκληρο άρθρο αφιερωμένο για αυτήν ακριβώς την ερώτηση. Έχει τον τίτλο Συνεισφέροντας στο Django.
Κατέθεσα ένα fix για ένα bug μέσω του ticket system πριν από πολλές εβδομάδες. Γιατί αγνοείτε το patch μου;¶
Μην ανησυχείτε: Δε σας αγνοούμε!
Είναι σημαντικό να καταλάβετε τη διαφορά μεταξύ «ενός ticket το οποίο αγνοείται» και «ενός ticket στο οποίο δεν έχει δοθεί προσοχή ακόμα». Το ticket system του Django περιέχει εκατοντάδες ανοικτά tickets (open tickets), πάνω σε διάφορους τομείς που οι developers του Django πρέπει να τα επιθεωρήσουν (review) και να τους αναθέσουν τις κατάλληλες προτεραιότητες (prioritize).
Εκτός αυτού, οι άνθρωποι που δουλεύουν για το Django είναι όλοι εθελοντές. Ως αποτέλεσμα αυτού, ο χρόνος που απαιτείται για την αφιέρωση στο framework είναι περιορισμένος και θα διαφέρει από βδομάδα σε βδομάδα αναλόγως τον ελεύθερο χρόνο μας. Αν είμαστε απασχολημένοι, ίσως να μην μπορέσουμε να αφιερώσουμε τον χρόνο που θέλουμε στο Django.
Ο καλύτερος τρόπος να σιγουρευτείτε ότι τα tickets δεν “κρεμάνε” κατά το checkin είναι να κάνετε πολύ κατανοητό, ακόμη και γι” αυτούς που δεν είναι εξοικειωμένοι με αυτό το κομμάτι του κώδικα, το πρόβλημα και να επιβεβαιώσετε το fix:
- Υπάρχουν ξεκάθαρες οδηγίες για το πως να αναπαραχθεί το σφάλμα (bug); Αν το σφάλμα επηρεάζει κάποιο dependency (όπως το Pillow), ένα contrib module, ή κάποια συγκεκριμένη βάση δεδομένων, είναι οι οδηγίες αρκετά ξεκάθαρες ούτως ώστε να τις διαβάσει κάποιος ο οποίος δεν είναι εξοικειωμένος με αυτό;
- Αν υπάρχουν αρκετά patches για ένα ticket, είναι ξεκάθαρο το τι κάνει το καθένα, ποια μπορούν να αγνοηθούν και ποια είναι μένουν;
- Το patch περιέχει κάποιο unit test; Αν όχι, υπάρχει κάποια σαφής εξήγηση γιατί; Ένα τεστ εκφράζει ευκρινώς ποιο είναι το πρόβλημα και δείχνει ότι το patch στην πραγματικότητα το διορθώνει.
Αν το patch σας δεν συμπεριληφθεί στο Django, δεν το αγνοούμε – απλά κλείνουμε το ticket (close ticket). Οπότε, αν το ticket σας είναι ακόμη ανοικτό, αυτό δε σημαίνει ότι σας αγνοούμε. Απλά ότι δεν είχαμε χρόνο να το κοιτάξουμε.
Πότε και πως μπορώ να υπενθυμίσω στην core ομάδα ένα patch το οποίο με ενδιαφέρει;¶
Ένας τρόπος να σας δώσουμε προσοχή είναι ένα ευγενικό και επίκαιρο μήνυμα στη mailing list. Αυτό που θα καθορίσει το πόσο επίκαιρο είναι το μήνυμα σας είναι να παρακολουθείτε το schedule. Αν στείλετε το μήνυμα σας όταν οι core developers προσπαθούν να διεκπεραιώσουν ένα feature εντός κάποιου deadline ή βρίσκονται υπό τη φάση κάποιου σχεδιασμού, τότε δεν θα έχετε την προσοχή που περιμένατε. Ωστόσο, όταν στείλετε το μήνυμα σας κατά τη διάρκεια που οι core developers ασχολούνται με τα bugs – ακριβώς πριν το διορθώσουν ή βρίσκεται πριν την beta έκδοση του – τότε είναι πολύ πιο πιθανό να έχετε την πολύτιμη ανταπόκριση τους.
Ένας άλλος τρόπος που μπορεί να δουλέψει είναι οι ευγενικές υπενθυμίσεις μέσω του IRC – και πάλι, δώστε προσοχή στην περίοδο που στέλνετε το μήνυμα σας. Μία καλή χρονική στιγμή είναι κατά τη διάρκεια του bug sprint (η περίοδος που οι core developers ασχολούνται με την επιδιόρθωση σφαλμάτων).
Άλλος ένας τρόπος είναι να κάνετε pull πολλά παρόμοια, μεταξύ τους, tickets. Όταν οι core developers ασχολούνται με την επιδιόρθωση ενός bug σε κάποιον τομέα που έχουν να ασχοληθούν καιρό, μπορεί να τους πάρει μερικά λεπτά για να θυμηθούν όλες τις λεπτομέρειες σχετικά με τη λειτουργία του κώδικα αυτού. Αν συγκεντρώσετε πολλές διορθώσεις που αφορούν τον ίδιο τομέα κώδικα (π.χ template tags ή model fields κλπ) σε ένα γκρουπ, δημιουργείτε έναν ελκυστικό στόχο αφού το όφελος διανέμεται σε πολλαπλά tickets και έτσι επιταχύνονται οι διαδικασίες.
Παρακαλούμε αποφύγετε να στέλνετε προσωπικά email στους core developers ή να κάνετε raise το ίδιο issue επανειλημμένως. Με αυτού του είδους τη συμπεριφορά δεν θα τραβήξετε την προσοχή – πόσο μάλλον την προσοχή που ζητάτε για να διευθετηθεί το bug σας.
Αλλά σας το έχω επισημάνει αρκετές φορές και εσείς συνεχίζετε να αγνοείτε το patch μου!¶
Σοβαρά τώρα - δεν σας αγνοούμε. Αν το patch σας δεν έχει καμία πιθανότητα να ενσωματωθεί στο Django, θα κλείσουμε το ticket. Για όλα τα άλλα tickets, χρειάζεται να θέσουμε κάποιες προτεραιότητες και επομένως μερικά να διευθετηθούν νωρίτερα από κάποια άλλα.
Ένα από τα κριτήρια τα οποία χρησιμοποιούμε για να θέσουμε προτεραιότητες στα bug fixes είναι ο αριθμός των ανθρώπων που θα επηρεαστούν από το συγκεκριμένο bug. Τα bugs που ενδεχομένως να επηρεάζουν αρκετό κόσμο θα πάρουν προτεραιότητα εν συγκρίσει με τις ακραίες περιπτώσεις.
Another reason that bugs might be ignored for while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little patches, 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.
