Pods: Label GitHub

~"Memerlukan Changelog" sebagai label mungkin bisa digunakan. Saya telah membuat pembaruan changelog sebagai bagian dari proses penggabungan dan belum menggunakan label berumur pendek itu.~
Selesai

Saya tidak punya waktu untuk menyisir dengan sisir bergigi halus, tetapi saya tidak melihat sesuatu yang langsung mencolok dalam pandangan sekilas. Saya mungkin menemukan beberapa penyesuaian, penghilangan, penghapusan pada umpan yang solid, tetapi insting saya adalah ini akan menjadi peningkatan besar atas sistem label saat ini seperti yang diusulkan.

"Patch" adalah salah satu yang tidak pernah saya gunakan dalam alur kerja saya, karena tampaknya berlebihan bagi saya. Jika itu PR, maka itu adalah tambalan. Tapi @sc0ttkclark secara tradisional menggunakan label itu, jadi mungkin ada beberapa nilai alur kerja untuknya.

~ Component: Multi-site akan menjadi tambahan yang bagus, itu adalah area lain seperti REST API, dan Template yang akan membantu untuk memulai penandaan untuk tujuan penyaringan.~

Selesai

Fokus: Kompatibilitas Mundur
Fokus: Kompatibilitas/Penghentian
Fokus: Kompatibilitas

Untuk ketiga ini, mungkin disempurnakan:

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

Sunting: Ini selesai

Selain hal-hal kecil sejauh ini, saya semua GO dalam hal ini. Klasifikasinya jauh lebih baik dan saya ingin menggunakannya 2.7.7.

Saya ingin mendapatkan acungan jempol eksplisit dari @jimtrue dan @sc0ttkclark juga, pertama.

Apa perbedaan antara Discussion dan Team Discussion ? Bisakah mereka diganti dengan Needs: Developer Feedback ?

Apa itu Integration ?

Ini umpan kedua saya. Beberapa tambahan/perubahan baru. Mereka yang memiliki tanda tanya utama dapat dijatuhkan jika tidak digunakan:

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

Apa perbedaan antara Diskusi dan Diskusi Tim? Bisakah mereka diganti dengan Kebutuhan: Umpan Balik Pengembang?

Tidak banyak, Diskusi akan terbuka untuk dunia dan Diskusi Tim akan bersifat internal. Saya tidak berpikir kita membutuhkan yang begitu halus dan satu label diskusi generik baik-baik saja (duplikasi itu mungkin tidak disengaja). Umpan Balik Dev umumnya digunakan sebagai status, biasanya tiket yang ditahan untuk umpan balik pengguna dan mendapat umpan balik tersebut.

Apa itu Integrasi?

Terutama permintaan fitur yang melibatkan integrasi dengan plugin lain, perpustakaan, tema, dll. Saya kira bug pada integrasi yang ada mungkin berada di bawah payung ini tetapi seringkali itu lebih tepat sebagai "kompatibilitas" setelah kami memiliki integrasi. (jadi Integrasi mungkin Tipe meskipun mungkin lebih masuk akal dalam Fokus seperti yang telah Anda lakukan)

Saya tidak yakin bagian 'Kebutuhan:" lebih baik... Saya menyukai gagasan itu sebagai bagian dari "Status:" karena saya pikir itu sering digunakan.

Sunting: ini semua telah ditangani

~Saya pikir Kata Kunci berikut mungkin sebenarnya Jenis: Rilis, Dukungan, dan Alat.~

~Itu tampak seperti jenis tiket yang tidak dijelaskan dengan baik oleh yang lain.~

Selesai

Juga, demi menggulir, saya bertanya-tanya apakah kita harus tetap memperbarui daftar di pesan awal daripada memposting versi baru saat kita pergi?

Selesai.

Saya suka ide ini:

Kebutuhan: Umpan Balik Pengembang
Kebutuhan: Riset
Kebutuhan: Daftar Tugas
Kebutuhan: Tes
Kebutuhan: Umpan Balik Pengguna
Kebutuhan: Verifikasi/Reproduksi
Kebutuhan: Suara

Tetapi 'Umpan Balik Pengguna' dan 'Verifikasi/Reproduksi' benar-benar 'status/alur kerja' seperti yang disebutkan @pglewis di atas atau kita dapat menempatkannya sebagai Status: Pemblokir dengan Kebutuhan menjadi 'alasan' Pemblokir.

Alur kerja status idealnya harus menipis ke swimlanes dalam proyek. Melihat daftar label ini, saya TIDAK tahu kami memiliki begitu banyak, tapi saya kira kalian membuat beberapa lagi.

support.pods.io dan docs.pods.io seharusnya tidak ada di sini sama sekali (kami memiliki repo untuk kedua situs web tersebut), kecuali jika kami berencana menggunakan GitHub untuk pembaruan Dukungan dan Dokumentasi. Jika kita akan melakukan itu (yang saya SEMUA untuknya) maka kita menambahkan awalan untuk Docs: dan Support: dan membuat dua proyek di GitHub dalam repositori ini untuk Support dan Documentation. Karena terkadang masalah dukungan dapat berubah menjadi peningkatan/fitur kode atau perbaikan bug yang sebenarnya, masuk akal bagi kami untuk menggunakan antarmuka yang sama. Tentu kami akan memiliki lebih banyak, tetapi kami juga akan memastikan kami mendapatkan apa yang kami butuhkan untuk masalah dukungan dan pembaruan dokumentasi.

Saya melihat ini, dan saya ingin melihat perubahan berikut:

• Ketik : Tambahkan Support & Docs Update (menghapus Support dari Keyword )
• Komponen : kita tidak membutuhkan support.pods.i o atau doc.pods.io di Component . Kedua repo itu memiliki proyek mereka sendiri. Komponen harus sepenuhnya untuk area fokus Pods Core.
• Prioritas : Pindahkan Focus dari Kata Kunci ke Priority . Blocker baik-baik saja selama kita tahu alasannya, yang seharusnya berasal dari Needs .

Jadi jika saya mengikuti ini dengan benar, semuanya harus memiliki:
Type : Mendefinisikan jenis tiketnya.
Status : Mendefinisikan dimana ia berada dalam Workflow. Sedikit diskusi tentang apa Status harus 'Diblokir' atau 'Yang Harus Dilakukan' atau 'Tahan' jika kami Membutuhkan Umpan Balik Pengguna atau Verifikasi/Reproduksi. Tidak yakin apa Statusnya untuk Permintaan Fitur/Peningkatan di mana Kebutuhannya adalah Suara. Mungkin mereka mengikuti format yang sama untuk papan Kanban biasa dan statusnya adalah BackLog hingga aktif bekerja. Blocker menunjukkan itu Tidak dapat bekerja sampai Kebutuhan ditangani.
Component : Menentukan area Pods Core untuk Feature/Enhance/Bug
Kata Kunci dan Fokus hanya untuk klarifikasi tambahan?

Saya menghapus WaffleBot sehingga status itu tidak lagi ditambahkan secara otomatis.

Blocker menunjukkan itu Tidak dapat bekerja sampai Kebutuhan ditangani.

Berikut adalah kasus di mana kami tidak menggunakan label dengan maksud yang sama. Saya selalu menggunakan Blocker (dan saya pikir Scott juga) untuk masalah yang memblokir rilis (atau mungkin tiket lain) dan harus dilakukan; tidak bisa ditekuk.

Tidak ada alasan dalam alur kerja saya untuk menandai sesuatu sebagai memegang sesuatu melalui 'Blocker'... label status saat ini harus menyiratkan hal itu. Saya tidak membutuhkan "Perlu Umpan Balik Pengguna" plus "Pemblokir" karena yang pertama sudah memberi tahu saya bahwa itu memblokir dan mengapa.

Suara saya adalah kami menggunakannya seperti itu dan menyimpannya di bawah "Prioritas: *" karena itu adalah deskripsi yang sempurna untuk saya.

~Saya pikir "Fokus" juga harus berpindah dari Kata Kunci ke Prioritas.~ Meninggalkan kata kunci

Saya suka ide ini:

Kebutuhan: Umpan Balik Pengembang
Kebutuhan: Riset
Kebutuhan: Daftar Tugas
Kebutuhan: Tes
Kebutuhan: Umpan Balik Pengguna
Kebutuhan: Verifikasi/Reproduksi
Kebutuhan: Suara

Ini terutama status tiket bagi saya, jadi saya mengusulkan untuk menyimpannya di sana untuk saat ini. Jika panjangnya menjadi perhatian, kami mungkin menyingkat beberapa ("Status: Need Dev FB", "Status: Need Verification/Repro").

Saya pikir "Perlu Daftar Tugas" bisa pergi. Saya tidak berpikir itu terjadi cukup untuk menjamin label. Saya tidak yakin saya pernah menggunakannya, jarang jika demikian. Mungkin juga untuk "Membutuhkan Tes". Yang tersisa semuanya cocok untuk saya di bawah "Status: *".

Juga, daftarnya terbentuk dengan baik bagi saya, kita mungkin harus mendiskusikan skema warna.

Beberapa lagi yang mungkin dapat dipangkas dari Status bersama dengan "Memerlukan Daftar Tugas":

• ~"Ditarik untuk Ditinjau" mungkin hanya duplikasi yang tidak disengaja dari "Siap untuk Ditinjau"~ Meninggalkannya
• "Unit Diuji" bukan status (belum setidaknya), lebih lain-lain... jadi mungkin pindah ke Kata Kunci?

Itu membuat daftar status terlihat bagus bagi saya.

"Ditarik untuk Ditinjau" mungkin hanya duplikasi yang tidak disengaja dari "Siap untuk Ditinjau"

Tidak setuju. Jika saya membuat PR, maka ketika sudah siap, saya akan menambahkan Ready for Review. Tetapi Anda mungkin tidak punya waktu untuk melakukan peninjauan itu sampai nanti - tetapi saat itu, Scott tidak yakin apakah Anda sudah memulai peninjauan atau belum. Singkatnya, ini adalah dua kelompok orang yang berbeda yang menambahkan Siap untuk Ditinjau dan Ditarik untuk Ditinjau.

Mungkin juga untuk "Membutuhkan Tes".

Demi menginginkan lebih banyak cakupan kode (walaupun saya belum banyak melihat area ini secara pribadi), label ini bisa untuk mengatakan bahwa "perbaikannya bagus, tetapi kami ingin melihat unit test menutupi tepi/verifikasi perbaikan bug tertentu sehingga tidak ada regresi yang diperkenalkan".

Saya pikir "Fokus" juga harus berpindah dari Kata Kunci ke Prioritas.

Prioritas umumnya - rendah, sedang, tinggi, kritis, pemblokir - mereka memiliki semantik yang berbeda (setidaknya dalam pikiran saya) untuk Fokus. Label Keyword: Focus tidak memiliki relevansi tersendiri kecuali ada Tonggak untuk mengatakan rilis mana yang menjadi fokus _for_. Sedangkan prioritas adalah tanpa konteks, sebanyak itu berlaku untuk proyek secara keseluruhan. Saya tidak selalu berpikir menambahkan prioritas lain adalah ide yang baik, tetapi sama, jangan berpikir Fokus adalah prioritas. Mungkin yang ingin kami katakan adalah bahwa "tiket ini adalah Sorotan Tonggak Sejarah - hal yang patut dibanggakan pada rilis berikutnya", dan jika demikian, kata lain untuk Focus mungkin lebih baik untuk menandakan niat.

Blocker menunjukkan itu Tidak dapat bekerja sampai Kebutuhan ditangani.

Saya setuju dengan Phil di sini - saya memahaminya berarti bahwa Masalah yang memiliki label ini adalah pemblokir _release_. Mungkin penjelasan Jim akan lebih cocok untuk label Status: Is Blocked atau yang serupa, meskipun Needs: * akan menunjukkan hal yang sama.

BTW, apakah boleh menghapus daftar sementara di sini: #5016 (komentar) ?

@pglewis Silakan dan hapus (atau sembunyikan di <details>...</details> untuk referensi historis) apa pun yang Anda inginkan.

support.pods.io dan docs.pods.io seharusnya tidak ada di sini sama sekali

Itu saya menambahkannya karena ketidakpastian tentang tag "Peningkatan Dokumen" yang ada (vs Dokumen: sebaris) - mereka dapat dihapus jika ditangani di tempat lain.

Peningkatan Dokumen mungkin lebih baik ditulis sebagai 'Docs: Inline' 'Docs: Example' 'Docs: Tooltips' dan semacamnya. Kecuali kami menangani alur kerja Dokumentasi (yaitu dokumentasi tertulis di situs web docs.pods.io) di GitHub, tidak ada alasan untuk itu di sini. Setiap perbaikan dokumen di dalam kode kami berarti dokumen _in_ kode kami atau dikelola dalam kode kami atau seperti readme yang diurai dan didorong ke repo plugin WordPress.org.

Saya suka Status: Is Blocked karena itu sangat informatif, tetapi jika Anda melakukan sesuatu seperti itu, itu memang membutuhkan Kebutuhan:* juga

Seperti yang saya katakan, semuanya mendapat Type dan Status . Sampai kami melakukan Manajemen Proyek Agile penuh dengan GitHub, prioritas tidak perlu didefinisikan di sana dan sebenarnya lebih baik diwakili oleh unit kerja yang diperlukan untuk menyelesaikan 'cerita'. Kami selalu menggunakan Fokus untuk membedakan item dalam 100-an masalah yang perlu difokuskan pada rilis pemeliharaan berikutnya.

Satu-satunya pemikiran saya adalah berkaitan dengan label UI/CSS, karena itulah yang paling sering saya tangani ... sepertinya mungkin hanya menghapus CSS sebagai komponen dan hanya mengandalkan UI yang paling masuk akal bagi saya. Tidak yakin apakah kalian memiliki pemikiran di sana, tetapi CSS adalah hasilnya, bukan hal nyata yang perlu diperbaiki ... jika itu masuk akal. UI akan menjadi hal yang nyata untuk dikerjakan atau ditingkatkan, css akan menjadi hasil atau bagaimana diperbaiki. Kalau tidak saya suka 👍

Satu-satunya pemikiran saya adalah berkaitan dengan label UI/CSS, karena itulah yang paling sering saya tangani ... sepertinya mungkin hanya menghapus CSS sebagai komponen dan hanya mengandalkan UI yang paling masuk akal bagi saya. Tidak yakin apakah kalian memiliki pemikiran di sana, tetapi CSS adalah hasilnya, bukan hal nyata yang perlu diperbaiki ... jika itu masuk akal. UI akan menjadi hal yang nyata untuk dikerjakan atau ditingkatkan, css akan menjadi hasil atau bagaimana diperbaiki.

Ya, ada penyempurnaan yang harus dilakukan di sana. Saya sebagian besar menggunakan label CSS sebagai sinyal Kelelawar untuk Anda dan/atau Jory untuk memfilter karena Anda telah menjadi orang yang masuk ke arah itu.

Saya akan memilih untuk meninggalkan CSS dan UI seperti yang diusulkan untuk saat ini, tetapi kami pasti dapat terus menyempurnakannya setelah Tahap I.

RE: Perlu Tes

Demi menginginkan lebih banyak cakupan kode (walaupun saya belum banyak melihat area ini secara pribadi), label ini bisa untuk mengatakan bahwa "perbaikannya bagus, tetapi kami ingin melihat unit test menutupi tepi/verifikasi perbaikan bug tertentu sehingga tidak ada regresi yang diperkenalkan".

Kenyataannya adalah kita perlu mengikuti perbaikan pemeliharaan, mengerjakan cabang rilis, dan hambatan untuk menulis tes baru cukup tinggi bahkan untuk hal-hal sederhana. Kami dapat meninggalkan label di sana tetapi sepertinya tidak akan banyak digunakan sampai lebih banyak refactoring telah dilakukan, kami memperkenalkan unit test yang sebenarnya, dan/atau memiliki lebih banyak sumber daya untuk dicurahkan.

"Jenis: Tes" akan menjadi tambahan yang bagus karena saat ini tes yang ditambahkan mungkin yang terbaik sebagai pasangan masalah/PR mereka sendiri.

Saya suka Status: Diblokir karena itu sangat informatif, tetapi jika Anda melakukan sesuatu seperti itu, itu membutuhkan Kebutuhan:* juga

Saya baik-baik saja meninggalkannya, tetapi saya yang terutama melacak status dan saya tidak pernah perlu menandai apa pun "diblokir" sebagai status. Apa pun yang samar-samar arah yang saya temui lebih baik ditutupi oleh "Memegang".

Dan jika itu membantu memperjelas apa pun, ini adalah alur kerja tipikal yang saya gunakan pada bug rata-rata:

• Triase: menyaring tidak valid, dukungan, fitur/peningkatan; setel jenis ke bug
• Biasanya status segera berubah menjadi "perlu verifikasi/repro"
• Dapat bolak-balik antara "membutuhkan umpan balik pengguna" dan "membutuhkan umpan balik pengembang" selama masa pakai
• Terverifikasi/Direproduksi
• Perlu Penelitian: sekarang kita tahu bagaimana mewujudkannya, cari tahu dan pahami alasannya
• Meneliti: Saya mungkin satu-satunya yang menggunakan ini. Sinyal penyelaman dalam telah dilakukan di beberapa titik dan saya mungkin memiliki detail internal yang tersimpan di kepala saya
• Tetap / Perlu Pengujian

Tidak setuju. Jika saya membuat PR, maka ketika sudah siap, saya akan menambahkan Ready for Review. Tetapi Anda mungkin tidak punya waktu untuk melakukan peninjauan itu sampai nanti - tetapi saat itu, Scott tidak yakin apakah Anda sudah memulai peninjauan atau belum. Singkatnya, ini adalah dua kelompok orang yang berbeda yang menambahkan Siap untuk Ditinjau dan Ditarik untuk Ditinjau.

Saya pikir label Tahan secara historis lebih baik daripada Ditarik untuk Ditinjau dalam kasus tersebut.

FYI, di masa lalu, saya telah menggunakan Blocker untuk menunjukkan masalah yang memblokir rilis.

Kami dapat menghapus 'Patch', saya mulai menggunakannya ketika GitHub memiliki UX yang lebih membingungkan antara PR dan Masalah, lebih mudah untuk melihat tampilan 'Rilis' dengan Patch terutama untuk memeriksa kembali hal-hal untuk hal-hal changelog. Kami tidak membutuhkannya.

Apakah daftar dalam deskripsi masalah asli mutakhir dengan perubahan yang telah kita diskusikan?

Apakah daftar dalam deskripsi masalah asli mutakhir dengan perubahan yang telah kita diskusikan?

Mungkin tidak sepenuhnya, silakan perbaiki beberapa jika Anda mau. Saya akan membahasnya setelah kami memiliki jempol penuh dan menyisir apa pun yang kami putuskan yang belum diperbarui.

Apa pun yang kami putuskan di sini, kami perlu menerapkan ke semua repo Pod kami yang lain menggunakan alat seperti https://github.com/dwyl/labels untuk menyinkronkannya.

Memindahkan "Regresi" dari Jenis ke Kata Kunci. Bug masih merupakan tipe untuk masalah regresi.

Ini cukup banyak diterapkan sekarang. Beberapa hal lain yang saya baru saja terjebak di bawah "Kata Kunci" untuk saat ini.

Warna adalah hal utama yang harus diperhatikan saat ini.

?Tutup: Tidak Valid

Saya sarankan menyimpan setidaknya yang ini, mungkin juga Tidak Akan Perbaiki. Mereka adalah resolusi yang cukup standar pada pelacak bug lainnya.

Warna adalah hal utama yang harus diperhatikan saat ini.

Warna adalah yang kedua pada saat ini - terapkan label, dan putuskan skema warna nanti.

Saya sarankan menyimpan setidaknya yang ini [Tidak Valid], mungkin juga Tidak Akan Perbaiki. Mereka adalah resolusi yang cukup standar pada pelacak bug lainnya.

Saya akan menambahkan Tidak Valid, saya hanya menandainya sebagai pengingat karena kami belum memilikinya.

"Won't Fix" adalah salah satu nada yang saya benci. Ditambah sikap saya adalah kita harus memiliki label dengan alasan spesifik yang lebih baik untuk tidak memperbaiki sesuatu daripada "Tidak Akan Memperbaiki".

Warna adalah yang kedua pada saat ini - terapkan label, dan putuskan skema warna nanti.

Label cukup banyak diterapkan.

Apakah kita memerlukan "Jenis: GitHub" atau yang serupa? Masalah ini tidak memiliki jenis.

Type: Project ?

Bagaimana jika alih-alih "Tidak Akan Memperbaiki" kami menggunakan "Biarkan apa adanya" atau semacamnya?

Bagaimana jika alih-alih "Tidak Akan Memperbaiki" kami menggunakan "Biarkan apa adanya" atau semacamnya?

Ini adalah situasi yang tidak biasa jadi kami telah membuatnya selama ini tanpa membutuhkan sesuatu seperti itu. Saya memilih untuk menunggu menambahkan apa pun di sana sampai contoh spesifik muncul.

Juga, saya telah membuat beberapa keputusan warna sewenang-wenang untuk beberapa grup. Tidak ada yang diatur di sana.

Saya pikir kita mungkin dapat menutup masalah ini pada saat ini dan mendiskusikan penyempurnaan lebih lanjut melalui Slack.

What if instead of "Won't Fix" we used "Leave as is" or something like that?

Ini adalah situasi yang tidak biasa jadi kami telah membuatnya selama ini tanpa membutuhkan sesuatu seperti itu. Saya memilih untuk menunggu menambahkan apa pun di sana sampai contoh spesifik muncul.

Saya setuju. Tidak semua yang dilakukan inti WordPress perlu diduplikasi

Saya setuju. Tidak semua yang dilakukan inti WordPress perlu diduplikasi

Ini juga merupakan salah satu label default saat menyiapkan repo baru di GH - lihat https://github.com/GaryJones/daterange/labels yang memiliki label default.

I agree. Not everything that WordPress core does needs to be duplicated

Ini juga merupakan salah satu label default saat menyiapkan repo baru di GH - lihat https://github.com/GaryJones/daterange/labels yang memiliki label default.

Saya tidak ingat kapan itu menjadi default untuk GitHub, tetapi selalu menjadi tag yang buruk untuk dilampirkan ke tiket dari kontributor sukarelawan. Saya telah melihat sangat sedikit masalah di GitHub dengan tag itu tetapi di dunia WordPress sebagian besar tiket yang tidak diperbaiki ditutupi oleh masalah lain, membutuhkan lebih banyak informasi untuk membenarkan perbaikan, atau hanya berharap tidak ada yang kembali mengeluh (sering terjadi) .

Aku akan bertahan dengan ketidaksukaanku. Pertanyaan langsung saya tentang "Tidak Akan Memperbaiki" adalah "Mengapa kita menolak untuk memperbaiki sesuatu?" Dan jika seseorang memberi saya jawaban singkat yang bagus untuk itu pada tiket, saya akan mengatakan _that_ adalah apa yang harus dibaca label daripada 'Tidak Akan Memperbaiki".

Saya pikir Out of Scope adalah jawaban yang lebih baik di sana. Tidak akan Memperbaiki hanya menyiratkan dan memberikan 'tidak ada' kepada orang yang membuka masalah.

mungkin itu bisa mengarah - jangan ragu untuk mengirimkan "solusi" tetapi tim tidak memiliki sumber daya yang cukup untuk melakukannya :D mungkin seseorang memiliki ide untuk singkatan singkatnya ^^

Kasus penggunaan mungkin berupa bug atau pelanggaran CS di beberapa fitur, yang secara grosir ditulis ulang dan dirilis di versi berikutnya.

Jangan ragu untuk meninggalkannya.