Sebaliknya, sebelum melaporkan sebuah kesalahan atau meminta fitur baru pada ticket tracker, pertimbangkan titik-titik ini:
\nPeriksa seseorang yang belum mengajukan kesalahan atau permintaan fitur dengan searching atau menjalankan custom queries di pelacak tiket.
Jangan gunakan sistem tiket untuk meminta dukungan pertanyaan. Gunakan daftar django-users atau saluran #django IRC untuk itu.
Jangan membuka kembali masalah-masalah yang telah ditandai "wontfix" tanpa menemukan pemufakatan untuk melakukannya pada django-developers.
Jangan menggunakan pelacak tiket untuk obrolan panjang, karena mereka sepertinya hilang. Jika sebagian tiket kontroversial, silahkan pindahkan obrolan ke django-developers.
Penulisan-bagus laporan kesalahan adalah luar biasa sangat membantu. Bagaimanapun, ada jumlah tertentu dari atas ikut dalam bekerja dengan sistem pelacakan kesalahan apapun sehingga bantuan anda dalam menjaga pelacak tiket berguna mungkin sangat dihargai. Khususnya:
\nLakukan baca FAQ untuk melihat jika masalah anda mungkin menjadi pertanyaan dikenal.
Lakukan tanya pada django-users atau #django pertama jika anda tidak yakin jika apa yang anda lihat adalah sebuah kesalahan.
Lakukan tulis lengkap, dapat digandakan, laporan kesalahan tertentu. Anda harus menyertakan jelas, gambaran ringkas dari masalah, dan kumpulan perintah untuk menggandakannya. Tambah sebanyak informasi mencari kesalahan yang anda bisa: potongan kode, kasus percobaan, pengecualian pelacakan kembali, tampilan layar, dll. Sebuah kasus percobaan kecil adalah jalan terbaik untuk melaporkan sebuah kesalahan, seperti dia memberikan kami jalan untuk memastikan kesalahan dengan cepat.
Jangan menempatkan ke django-developers hanya untuk mengumumkan bahwa anda telah mengajukan laporan kesalahan. Semua tiket disurelkan ke daftar lain, django-updates, yang dilacak oleh pengembang dan anggota komunitas yang tertarik; kami melihat mereka seperti yang diajukan.
Untuk memahami siklus hidup tiket anda pertama anda telah membuatnya, mengacu ke Mendahulukan tiket.
\nJika kesalahan atau fitur anda menyentuh pada apapun penglihatan dalam alami, terdapat beberapa tambahan panduan untuk diikuti:
\nSertakan tampilan layar dalam tiket anda yaitu setara penglihatan dari uji kasus minimal. Pamerkan masalah, bukan penyesuaian gila anda tlah buat ke perambah anda.
Jika masalah sulit untuk ditunjukkan menggunakan gambar diam, pertimbangkan mengambil rekaman layar singkat. Jika perangkat lunak anda mengizinkannya, tangkap hanya kawasan yang sesuai dari layar.
Jika anda sedang menawarkan tambalan yang merubah tampilan atau perilaku dari UI Django, anda harus melampirkan sebelum dan sesudah cuplikan layar/rekaman layar. Tiket melacak ini sangat sulit untuk mengurutkan untuk menilai dengan cepat.
Cetak layar tidak membebaskan anda dari praktik pelaporan bagus. pastikan menyertakan URL, potongan kode, dan petunjuk langkah-demi-langkah pada bagaimana membuat kembali kebiasaan nampak dalam cetak layar.
Pastikan menyetel bendera UI/UX pada tiket sehingga pihak tertarik dapat menemukan tiket anda.
Kami selalu mencoba membuat Django lebih baik, dan permintaan fitur anda adalah kunci bagian dari itu. Disini ada beberapa tip dalam bagaimana membuat permintaan paling efektif:
\nPastikan fitur sebenarnya membutuhkan perubahan di inti Django. Jika ide anda dapat dikembangkan sebagai aplikasi terpisah atau modul - sebagai contoh, anda ingin mendukung mesin basisdata lain - kami akan mungkin menduga bahwa anda untuk mengembangkannya secara mandiri. Kemudian, jika proyek anda mengumpulkan cukup dukungan komunitas, kami mungkin mempertimbangkannya untuk menyertakan di Django.
Permintaan pertama pada daftar django-developers,bukan di pelacak tiket. Dia akan membaca lebih dekat jika dia berada di daftar penyuratan. Ini bahkan lebih penting untuk permintaan fitur skala-besar. Kami suka mengobrol perubahan besar apapun pada inti Django pada daftar penyuratan sebelum sebenarnya bekerja dengan mereka.
Gambarkan dengan jelas dan secara singkat apa fitur yang hilang dan bagaimana anda ingin melihatnya diterapkan. Sertakan kode contoh (bukan-fungsional OKE) jika memungkinkan.
Jelaskan kenapa anda menyukai fitur. Dalam beberapa kasus sudah jelas, tetapi sejak Django dirancang untuk membantu pengembang asli menyelesaikan pekerjaannya, anda akan butuh menjelaskannya, jika tidak jelas mengapa fitur akan berguna.
Jika ada sebuah persetujuan pemufakatan pada fitur, kemudian itu adalah sesuai untuk membuat sebuah tiket. Sertakan sebuah tautan obrolan pada django-developers dalam gambaran tiket.
\nSeperti kebanyakan proyek sumber-terbuka, code talk. Jika anda akan menulis kode untuk fitur itu sendiri atau, bahkan lebih baik, jika anda telah menulisnya, itu jauh lebih mungkin untuk diterima. Hanya cabangkan Django di GitHub, buat fitur cabang, dan tunjukkan kami pekerjaan anda!
\nLihat juga: Mendokumentasikan fitur baru.
\nKapan saja memungkinkan, kami berjuang untuk pemufakatan kasar. Sampai akhir itu, kami akan sering mempunyai pilihan tidak resmi pada django-developers tentang sebuah fitur. Di pilihan ini kami mengikuti gaya yang dibuat oleh Apache dan menggunakan Python itu sendiri, dimana pilihan diberikan sebagai +1, +0, -0, atau -1. Diterjemahkan kasar, pilihan ini berarti:
\n+1: "Saya cinta ide dan Saya sangat kuat melakukannya."
+0: "Kedengarannya OKE buat saya."
-0: "Saya tidak senang, tetapi Saya tidak berdiri di jalan."
-1: "Saya sangat tidak setuju dan akan sangat tidah bahagia untuk melihat ide berubah menjadi kenyataan."
Meskipun pilihan ini pada django-developers tidak resmi, mereka akan mengambil sangat serius. Setelah masa pemilihan cocok, jika pemufawakatan jelas muncul kami akan mengikuti pilihan.
\nBagaimanapun, pemufakatan tidak selalu mungkin. Jika pemufakatan tidak dapat diraih, atau jika obrolan menuju pemufakatan gagal tanpa keputusan nyata, keputusan mungkin ditangguhkan pada technical board.
\nDi bagian dalam, badan teknis akan menggunakan mekanisme pemilihan sama. Sebuah saran akan dipertimbangkan dibawa jika:
\nTerdapat setidaknya tiga pilihan "+1" dari anggota badan teknis.
Tidak ada pilihan "-1" untuk anggota badan teknis manapun.
Pemungutan suara harus diajukan dalam minggu ini.
\nSejak pengolahan ini mengizinkan anggota badan teknis manapun untuk mem veto pengajuan, sebuah pilihan "-1" harus ditemani oleh sebuah penjelasan dari apa yang akan diambil untuk merubah "-1" menjadi setidaknya "+0".
\nPilihan pada masalah teknis harus diumumkan dan diadakan secara umum pada daftar penyuratan django-developers.
\n