Mengajukan bantuan¶

Perbaikan kesalahan ketik dan perubahan dokumentasi sepele.¶

Jika anda sedang memperbaiki masalah sepele, sebagai contoh merubah sebuah kata di dokumentasi, cara dipilih untuk menyediakan tambalan adalah menggunakan menarik permintaan GitHub tanpa tiket Trac.

Lihat Bekerja dengan Git dan GitHub untuk rincian lebih bagaimana menggunakan pull request.

Tiket "Meminta"¶

Dalam sebuah proyek sumber-terbuka dengan ratusan penyumbang diseluruh dunia, adalah sangat penting untuk mengelola komunikasi secara efektif sehingga pekerjaan tidak ganda dan penyumbang dapat menjadi seefektif mungkin.

Oleh sebab itu, kebijakan kami untuk penyumbang dalam "menagih" tiket agar membiarkan pengembang lain mengetahui bahwa kesalahan atau fitur tertentu sedang dikerjakan.

Jika anda telah mencirikan bantuan anda ingin membuat dan anda mampu memperbaikinya (yang diukur dengan kemampuan pengkodean anda, pengetahuan dari internal Django dan ketersediaan waktu), tagih dia dengan mengikuti langkah-langkah berikut:

• Login using your GitHub account atau create an account di sistem tiket kami. Jika anda mempunyai sebuah akun tetapi lupa sandi anda, anda dapat mengatur kembali menggunakan password reset page.

• Jika sebuah tiket untuk masalah ini belum ada, buat satu di ticket tracker kami.

• Jika tiket untuk masalah ini sudah ada, pastikan tidak seorangpun telah menagihnya. Untuk melakukan ini, lihat bagian "Owned by" dari tiket. Jika dia ditentukan ke "nobody", kemudian itu tersedia untuk ditagih. Jika tidak, seseorang lain mungkin bekerja pada tiket untuk menawarkan bantuan anda. Jika tiket diberikan selama mingguan atau bulanan tanpa aktivitas apapun, itu mungkin aman untuk ditetapkan untuk diri anda sendiri.

• Log into your account, if you haven't already, by clicking "GitHub Login" or "DjangoProject Login" in the upper left of the ticket page. Once logged in, you can then click the "Modify Ticket" button near the bottom of the page.

• Claim the ticket by clicking the "assign to" radio button in the "Action" section. Your username will be filled in the text box by default.

• Finally click the "Submit changes" button at the bottom to save.

Contribution style¶

Pastikan bahwa tiap sumbangan anda lakukan memenuhi setidaknya persyaratan berikut:

• The code required to fix a problem or add a feature is an essential part of a solution, but it is not the only part. A good fix should also include a regression test to validate the behavior that has been fixed and to prevent the problem from arising again. Also, if some tickets are relevant to the code that you've written, mention the ticket numbers in some comments in the test so that one can easily trace back the relevant discussions after your patch gets committed, and the tickets get closed.

• If the code adds a new feature, or modifies the behavior of an existing feature, the change should also contain documentation.

When you think your work is ready to be reviewed, send a GitHub pull request. If you can't send a pull request for some reason, you can also use patches in Trac. When using this style, follow these guidelines.

• Ajukan tambalan-tambalan dalam bentuk dikembalikan oleh perintah git diff.

• Lampirkan tambalan ke sebuah tiket dalam ticket tracker, menggunakan tombol "attach file". Tolong jangan taruh tambalan dalam gambaran tiket atau komentar meskipun dia hanya sebuah tambalan baris tunggal.

• Nama berkas tambalan dengan perpanjangan .diff; ini akan membuat pelacak tiket memberlakukan penyorotan sintaksis benar, yang tentunya sangat membantu.

Tanpa memperhatikan cara anda mengajukan pekerjaan anda, ikuti langkah-langkah ini.

• Make sure your code fulfills the requirements in our contribution checklist.

• Centang kotak "Has patch" pada tiket dan pastikan kotak-kotak "Butuh dokumentasi", "Butuh percobaan", and "Tambalan butuh perbaikan" tidak dicentang. Ini membuat tiket muncul di antrian "Tambahan butuh ditinjau" pada Development dashboard.

Contributions which require community feedback¶

A wider community discussion is required when a patch introduces new Django functionality and makes some sort of design decision. This is especially important if the approach involves a deprecation or introduces breaking changes.

The following are different approaches for gaining feedback from the community.

Mengusangkan fitur¶

Ada sepasang alasan dimana dalam Django mungkin diusangkan:

• Jika sebuah fitur telah ditingkatkan atau dirubah di cara ketidaksesuaian-kebelakang, fitur atau kebiasaan lama akan diusangkan.

• Terkadang Django akan menyertakan backport dari pustaka Python yang tidak disertakan dalam versi dari Python yang Django saat ini dukung. Ketika Django tidak lagi butuh mendukung versi lama dari Python yang tidak menyertakan pustaka, pustakan akan diusangkan di Django.

Seperti deprecation policy gambarkan, terbitan pertama dari Django yang mengusangkan sebuah fitur (A.B) harus memunculkan RemovedInDjangoXXWarning (dimana XX adalah versi Django dimana fitur akan dipindahkan) ketika fitur diusangkan dipanggil. Menganggp kami mempunyai cakupan percobaan baik, peringatan ini dirubah ke kesalahan ketika running the test suite dengan peringatan diadakan: python -Wa runtests.py. Dengan demikian, ketika menambahkan RemovedInDjangoXXWarning anda butuh mengurangi atau mensenyapkan tiap peringatan yang dibangkitkan ketika menjalankan percobaan.

Langkah pertama adalah memindahkan tiap penggunaan dari kebiasaan diusangkan oleh Django itu sendiri. Selanjutnya anda dapat peringatan senyap di percobaan yang sebenarnya mencoba kebiasaan diusangkan dengan menggunakan penghias ignore_warnings, antara pada tingkatan percobaan atau kelas:

1. Di percobaan khusus:

   from django.test import ignore_warnings
   from django.utils.deprecation import RemovedInDjangoXXWarning
   
   
   @ignore_warnings(category=RemovedInDjangoXXWarning)
   def test_foo(self): ...
   

2. Untuk kasus percobaan keseluruhan:

   from django.test import ignore_warnings
   from django.utils.deprecation import RemovedInDjangoXXWarning
   
   
   @ignore_warnings(category=RemovedInDjangoXXWarning)
   class MyDeprecatedTests(unittest.TestCase): ...
   

You should also add a test for the deprecation warning:

from django.utils.deprecation import RemovedInDjangoXXWarning


def test_foo_deprecation_warning(self):
    msg = "Expected deprecation message"
    with self.assertWarnsMessage(RemovedInDjangoXXWarning, msg) as ctx:
        # invoke deprecated behavior
        ...
    self.assertEqual(ctx.filename, __file__)

Sangat penting untuk menyertakan komentar RemovedInDjangoXXWarning diatas kode yang tidak mempunyai acuan peringatan, tetapi akan butuh dirubah atau dihapus ketika pengusangan berakhir. Ini dapat menyertakan kaitan yang telah ditambahkan untuk menjaga perilaku sebelumnya, atau barang berdiri sendiri yang tidak butuh atau tidak digunakan ketika pengusangan berakhir. Sebagai contoh:

import warnings
from django.utils.deprecation import RemovedInDjangoXXWarning


# RemovedInDjangoXXWarning.
def old_private_helper():
    # Helper function that is only used in foo().
    pass


def foo():
    warnings.warn(
        "foo() is deprecated.",
        category=RemovedInDjangoXXWarning,
        stacklevel=2,
    )
    old_private_helper()
    ...

Akhirnya, ada sepasang pembaharuan ke dokumentasi Django untuk dibuat:

1. Jika fitur yang ada didokumentasikan, tandai dia diusangkan di dokumentasi menggunakan keterangan .. deprecated:: A.B. Termasuk gambaran pendek dan catatan tentang jalur peningkatan jika berlaku.

2. Tambah gambaran dari kebiasaan pengusangan, dan tingkatkan jalur jika dapat diterapkan, pada catatan terbitaan saat ini (docs/releases/A.B.txt) dibawah kepala "Fitur-fitur diusangkan dalam A.B".

3. Tambah sebuah masukan dalam linimasa pengusangan (docs/internals/deprecation.txt) dibawah versi yang sesuai menggambarkan kode apa akan dipindahkan.

Once you have completed these steps, you are finished with the deprecation. In each feature release, all RemovedInDjangoXXWarnings matching the new version are removed.

JavaScript contributions¶

For information on JavaScript contributions, see the Tambalan JavaScript documentation.

Optimization patches¶

Patches aiming to deliver a performance improvement should provide benchmarks showing the before and after impact of the patch and sharing the commands for reviewers to reproduce.

Contribution checklist¶

Use this checklist to review a pull request. If you are reviewing a pull request that is not your own and it passes all the criteria below, please set the "Triage Stage" on the corresponding Trac ticket to "Ready for checkin". If you've left comments for improvement on the pull request, please tick the appropriate flags on the Trac ticket based on the results of your review: "Patch needs improvement", "Needs documentation", and/or "Needs tests". As time and interest permits, mergers do final reviews of "Ready for checkin" tickets and will either commit the changes or bump it back to "Accepted" if further work needs to be done. If you're looking to become a merger, doing thorough reviews of contributions is a great way to earn trust.

Looking for a patch to review? Check out the "Patches needing review" section of the Django Development Dashboard.

Looking to get your pull request reviewed? Ensure the Trac flags on the ticket are set so that the ticket appears in that queue.