Συχνές Ερωτήσεις: Συνεισφέροντας κώδικα¶
Πως μπορώ να ξεκινήσω να συνεισφέρω κώδικα στο 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 που ενδεχομένως να επηρεάζουν αρκετό κόσμο θα πάρουν προτεραιότητα εν συγκρίσει με τις ακραίες περιπτώσεις.
Ένας άλλος λόγος που ένα bug μπορεί να αγνοηθεί είναι η περίπτωση που το ίδιο αποτελεί ένα σύμπτωμα ενός μεγαλύτερου προβλήματος. Παρόλο που ξοδεύουμε χρόνο για να γράψουμε, τεστάρουμε και εφαρμόσουμε πολλά μικρά patches, μερικές φορές είναι πιο φρόνιμο να το χτίσουμε από την αρχή (rebuild). Αν έχει προταθεί ή είναι καθοδόν κάποιο rebuild ή κάποιο refactor ενός συγκεκριμένου component, θα διαπιστώσετε ότι τα bugs που επηρεάζουν αυτό το component δε θα λάβουν τη δέουσα προσοχή. Για ακόμη μια φορά, αυτό είναι θέμα προτεραιοτήτων. Συγκεντρώνοντας την προσοχή μας σε κάποιο rebuild, μπορούμε να κλείσουμε, μονομιάς, όλα τα μικρά bugs και να ελπίζουμε ότι άλλα bugs μικρής κλίμακας δεν θα εμφανιστούν στο μέλλον.
Οποιοσδήποτε και αν είναι ο λόγος, παρακαλούμε έχετε υπόψιν σας ότι αν κάποιο συγκεκριμένο bug, εμφανίζεται συχνά στον κώδικα σας, αυτό δεν σημαίνει ότι εμφανίζεται και σε όλους τους άλλους Django χρήστες. Διαφορετικοί χρήστες χρησιμοποιούν το Django με διαφορετικούς τρόπους και υπό διαφορετικές συνθήκες. Όταν αξιοποιούμε τις σχετικές προτεραιότητες, προσπαθούμε, γενικά, να εξετάσουμε τις ανάγκες του συνόλου της κοινότητας και όχι αυστηρά κάποιον συγκεκριμένο χρήστη. Αυτό δεν σημαίνει ότι το πρόβλημα σας είναι ασήμαντο – αλλά ότι στον ήδη περιορισμένο χρόνο που έχουμε, θα βάλουμε τα δυνατά μας να κάνουμε 10 ανθρώπους χαρούμενους παρά έναν.
