{"title":"Mengajukan bantuan","version":"6.0","locale":"id","docname":"internals/contributing/writing-code/submitting-patches","url":"/id/6.0/internals/contributing/writing-code/submitting-patches/","canonical":"https://djangodocs.dev/id/6.0/internals/contributing/writing-code/submitting-patches/","summary":"We're always grateful for contributions to Django's code. Indeed, bug reports with associated contributions will get fixed far more quickly than those without a…","html":"

Mengajukan bantuanLink to this heading#

\n

We're always grateful for contributions to Django's code. Indeed, bug reports\nwith associated contributions will get fixed far more quickly than those\nwithout a solution.

\n
\n

Perbaikan kesalahan ketik dan perubahan dokumentasi sepele.Link to this heading#

\n

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.

\n

See Bekerja dengan Git dan GitHub for more\ndetails on how to use pull requests.

\n
\n
\n

Tiket "Meminta"Link to this heading#

\n

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.

\n

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

\n

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:

\n\n\n
\n

Tanggung jawab pengaku tiketLink to this heading#

\n

Sekali anda mengakui sebuah tiket, anda mempunyai tanggung jawab untuk bekerja pada tiket tepat waktu. Jika anda tidak mempunyai waktu untuk bekerja padanya, salah satu batalkan pengakuannya atau jangan mengakuinya di tempat pertama!

\n

Jika tidak ada tanda kemajuan pada tiket tertentu yang diakui selama seminggu atau dua minggu, pengembang lain mungkin meminta anda melepaskan pengakuan tiket sehingga itu tidak lagi dikuasai dan seseorang lain dapat mengakuinya.

\n

Jika anda telah mengakui tiket dan itu memakan waktu lama (harian atau mingguan) untuk membuat kode, jaga semua orang terperbaharui dengan menempatkan komentar pada tiket. Jika anda tidak menyediakan pembaharuan reguler, dan anda tidak menjawab pada permintaan untuk laporan kemajuan, pengakuan anda pada tiket mungkin ditarik.

\n

Seperti biasa, komunikasi lebih lebih baik daripada komunikasi kurang!

\n
\n
\n

Tiket mana harus diminta?Link to this heading#

\n

Going through the steps of claiming tickets is overkill in some cases.

\n

In the case of small changes, such as typos in the documentation or small bugs\nthat will only take a few minutes to fix, you don't need to jump through the\nhoops of claiming tickets. Submit your changes directly and you're done!

\n

It is always acceptable, regardless of whether someone has claimed it or not,\nto link proposals to a ticket if you happen to have the changes ready.

\n
\n
\n
\n

Contribution styleLink to this heading#

\n

Pastikan bahwa tiap sumbangan anda lakukan memenuhi setidaknya persyaratan berikut:

\n\n

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

\n\n

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

\n\n
\n
\n

Contributions which require community feedbackLink to this heading#

\n

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

\n

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

\n
\n

The new feature ideas trackerLink to this heading#

\n

If you have an idea for a new feature, please create a new proposal (or join an\nexisting discussion) following the process for suggesting new features. You should explain the need for the change, go into\ndetails of the approach and discuss alternatives.

\n
\n
\n

The Django ForumLink to this heading#

\n

You can propose a change (that is not a new feature idea) on the\nDjango Forum. You should explain the need for the change, go into details of\nthe approach and discuss alternatives.

\n

Please include a link to such discussions in your contributions.

\n
\n
\n

Third party packageLink to this heading#

\n

Django does not accept experimental features. All features must follow our\ndeprecation policy. Hence, it can\ntake months or years for Django to iterate on an API design.

\n

If you need user feedback on a public interface, it is better to create a\nthird-party package first. You can iterate on the public API much faster, while\nalso validating the need for the feature.

\n

Once this package becomes stable and there are clear benefits of incorporating\naspects into Django core, the next step is to propose its inclusion by\nfollowing the process for suggesting new features.

\n
\n
\n

Django Enhancement Proposal (DEP)Link to this heading#

\n

Similar to Python’s PEPs, Django has Django Enhancement Proposals or DEPs. A\nDEP is a design document which provides information to the Django community, or\ndescribes a new feature or process for Django. They provide concise technical\nspecifications of features, along with rationales. DEPs are also the primary\nmechanism for proposing and collecting community input on major new features.

\n

Before considering writing a DEP, it is recommended to first open a discussion\nfollowing the process for suggesting new features.\nThis allows the community to provide feedback and helps refine the proposal.\nOnce the DEP is ready, the Steering Council votes on\nwhether to accept it.

\n

Some examples of DEPs that have been approved and fully implemented:

\n\n
\n
\n
\n

Mengusangkan fiturLink to this heading#

\n

Ada sepasang alasan dimana dalam Django mungkin diusangkan:

\n\n

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.

\n

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:

\n
    \n

  1. Di percobaan khusus:

    \n
    Code
    from django.test import ignore_warnings\nfrom django.utils.deprecation import RemovedInDjangoXXWarning\n\n\n@ignore_warnings(category=RemovedInDjangoXXWarning)\ndef test_foo(self): ...\n
    \n
    2. \n

  2. Untuk kasus percobaan keseluruhan:

    \n
    Code
    from django.test import ignore_warnings\nfrom django.utils.deprecation import RemovedInDjangoXXWarning\n\n\n@ignore_warnings(category=RemovedInDjangoXXWarning)\nclass MyDeprecatedTests(unittest.TestCase): ...\n
    \n
    3. \n
\n

Anda juga harus menambahkan pengujian untuk peringatan pengusangan:

\n
Code
from django.utils.deprecation import RemovedInDjangoXXWarning\n\n\ndef test_foo_deprecation_warning(self):\n    msg = "Expected deprecation message"\n    with self.assertWarnsMessage(RemovedInDjangoXXWarning, msg) as ctx:\n        # invoke deprecated behavior\n        ...\n    self.assertEqual(ctx.filename, __file__)\n
\n

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:

\n
Code
import warnings\nfrom django.utils.deprecation import RemovedInDjangoXXWarning, django_file_prefixes\n\n\n# RemovedInDjangoXXWarning.\ndef old_private_helper():\n    # Helper function that is only used in foo().\n    pass\n\n\ndef foo():\n    warnings.warn(\n        "foo() is deprecated.",\n        category=RemovedInDjangoXXWarning,\n        skip_file_prefixes=django_file_prefixes(),\n    )\n    old_private_helper()\n    ...\n
\n

Akhirnya, ada sepasang pembaharuan ke dokumentasi Django untuk dibuat:

\n
    \n

  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. \n

  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. \n

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

    4. \n
\n

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

\n

The django.utils.deprecation module provides some helpful deprecation\nutilities, such as a @deprecate_posargs decorator to assist with converting\npositional-or-keyword arguments to keyword-only. See the inline documentation\nin the module source.

\n
\n
\n

Testing with a Django projectLink to this heading#

\n

It's important to test local changes using a Django project. This allows\nensuring that the changes behave as expected in a real environment, especially\nfor user-facing features such as templates, forms, or the admin.

\n

To do this:

\n
    \n

  1. Create a virtual environment and install the cloned copy of Django in\neditable mode.

    2. \n

  2. Set up a Django project outside the source tree (you can use the first\npart of the tutorial for guidance).

    3. \n
\n

With this setup, any changes made to the Django checkout will take effect\nimmediately in the test project, allowing manual testing of contributions\nagainst a new or existing app.

\n
\n
\n

Bantuan JavaScriptLink to this heading#

\n

For information on JavaScript contributions, see the Tambalan JavaScript\ndocumentation.

\n
\n
\n

Optimalisasi tambahanLink to this heading#

\n

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

\n
\n

Tolok ukur django-asvLink to this heading#

\n

django-asv monitors the performance of Django code over time. These\nbenchmarks can be run on a pull request by labeling the pull request with\nbenchmark. Adding to these benchmarks is highly encouraged.

\n
\n
\n
\n

Daftar centang bantuanLink to this heading#

\n

Use this checklist to review a pull request. If this contribution would not be\nconsidered trivial, first ensure it has an accepted\nticket before proceeding with the review.

\n

If the pull request passes all the criteria below and is not your own, please\nset the "Triage Stage" on the corresponding Trac ticket to "Ready for checkin".\nIf you've left comments for improvement on the pull request, please tick the\nappropriate flags on the Trac ticket based on the results of your review:\n"Patch needs improvement", "Needs documentation", and/or "Needs tests". As time\nand interest permit, mergers do final reviews of "Ready for checkin" tickets\nand will either commit the changes or bump it back to "Accepted" if further\nwork needs to be done.

\n

If you're looking to become a member of the triage & review team, doing\nthorough reviews of contributions is a great way to earn trust.

\n

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

\n

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

\n
\n

Semua tiketLink to this heading#

\n\n
\n
\n

Semua kode perubahanLink to this heading#

\n\n
\n
\n

DokumentasiLink to this heading#

\n\n
\n
\n

KesalahanLink to this heading#

\n\n
\n
\n

Fitur BaruLink to this heading#

\n\n
\n
\n

Mengusangkan fiturLink to this heading#

\n

Lihat panduan Mengusangkan fitur.

\n
\n
","rootId":"submitting-contributions","toc":[{"title":"Perbaikan kesalahan ketik dan perubahan dokumentasi sepele.","anchor":"typo-fixes-and-trivial-documentation-changes","children":[]},{"title":"Tiket \"Meminta\"","anchor":"claiming-tickets","children":[{"title":"Tanggung jawab pengaku tiket","anchor":"ticket-claimers-responsibility","children":[]},{"title":"Tiket mana harus diminta?","anchor":"which-tickets-should-be-claimed","children":[]}]},{"title":"Contribution style","anchor":"contribution-style","children":[]},{"title":"Contributions which require community feedback","anchor":"contributions-which-require-community-feedback","children":[{"title":"The new feature ideas tracker","anchor":"the-new-feature-ideas-tracker","children":[]},{"title":"The Django Forum","anchor":"the-django-forum","children":[]},{"title":"Third party package","anchor":"third-party-package","children":[]},{"title":"Django Enhancement Proposal (DEP)","anchor":"django-enhancement-proposal-dep","children":[]}]},{"title":"Mengusangkan fitur","anchor":"deprecating-a-feature","children":[]},{"title":"Testing with a Django project","anchor":"testing-with-a-django-project","children":[]},{"title":"Bantuan JavaScript","anchor":"javascript-contributions","children":[]},{"title":"Optimalisasi tambahan","anchor":"optimization-patches","children":[{"title":"Tolok ukur django-asv","anchor":"django-asv-benchmarks","children":[]}]},{"title":"Daftar centang bantuan","anchor":"contribution-checklist","children":[{"title":"Semua tiket","anchor":"all-tickets","children":[]},{"title":"Semua kode perubahan","anchor":"all-code-changes","children":[]},{"title":"Dokumentasi","anchor":"documentation","children":[]},{"title":"Kesalahan","anchor":"bugs","children":[]},{"title":"Fitur Baru","anchor":"new-features","children":[]},{"title":"Mengusangkan fitur","anchor":"id4","children":[]}]}],"breadcrumbs":[{"docname":"internals/index","title":"Dalam Django","url":"/id/6.0/internals/"},{"docname":"internals/contributing/index","title":"Membantu untuk Django","url":"/id/6.0/internals/contributing/"},{"docname":"internals/contributing/writing-code/index","title":"Kode bantuan","url":"/id/6.0/internals/contributing/writing-code/"}],"prev":{"docname":"internals/contributing/writing-code/index","title":"Kode bantuan","url":"/id/6.0/internals/contributing/writing-code/"},"next":{"docname":"internals/contributing/writing-code/unit-tests","title":"Satuan percobaan","url":"/id/6.0/internals/contributing/writing-code/unit-tests/"},"formats":{"html":"/id/6.0/internals/contributing/writing-code/submitting-patches/","markdown":"/id/6.0/internals/contributing/writing-code/submitting-patches.md","json":"/id/6.0/internals/contributing/writing-code/submitting-patches.json"},"source":"https://github.com/django/django/blob/stable/6.0.x/docs/internals/contributing/writing-code/submitting-patches.txt","official":"https://docs.djangoproject.com/id/6.0/internals/contributing/writing-code/submitting-patches/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}