Basis Pengetahuan Mozilla tetap terbuka bagi siapa saja yang ingin berkontribusi. Siapa pun dapat mengirimkan revisi minor untuk memperbaiki atau memperbarui artikel dukungan kami tanpa memerlukan izin khusus.

Dokumen ini menjelaskan alur kerja untuk permintaan konten baru dan pembaruan mayor yang dikoordinasikan melalui Bugzilla. Permintaan ini mengikuti proses yang berbeda karena sering kali memerlukan kolaborasi dengan tim produk dan pemangku kepentingan lainnya.

Jika Anda tidak yakin alur kerja mana yang berlaku untuk perubahan Anda, silakan lihat bagian Aturan praktis di bawah ini atau periksa Perubahan kecil vs besar untuk memahami kategori perubahan yang Anda usulkan.

Mengapa Bugzilla?

Kami menggunakan Bugzilla untuk mengoordinasikan diskusi seputar permintaan konten baru dan pembaruan mayor karena proses ini sering kali melibatkan banyak pemangku kepentingan.

Menggunakan satu ruang kolaborasi membantu memastikan bahwa percakapan tetap transparan dan dapat diakses oleh semua orang yang terlibat. Kami sengaja menggunakan Bugzilla alih-alih diskusi artikel Basis Pengetahuan karena banyak pemangku kepentingan produk kami sudah bekerja di Bugzilla sebagai bagian dari alur kerja normal mereka, sementara relatif sedikit yang terbiasa dengan sistem diskusi Basis Pengetahuan.

Bugzilla juga menyediakan kepemilikan tugas yang jelas dan pelacakan kemajuan. Karena pembuatan konten adalah upaya kolaboratif antara staf Mozilla dan kontributor komunitas, penting bagi semua orang untuk dapat dengan mudah melihat siapa yang bertanggung jawab atas suatu permintaan, keputusan apa yang telah dibuat, dan pekerjaan apa yang masih tersisa. Ini membantu menghindari duplikasi upaya, mengurangi kebingungan, dan mempermudah menjaga dokumentasi terkait rilis tetap sesuai jadwal.

Aturan praktis

Sebagai aturan umum, Anda dapat bertanya pada diri sendiri pertanyaan berikut:

Apakah perubahan ini memerlukan masukan atau validasi dari tim produk?

• Jika ya, buat atau kerjakan melalui tiket Bugzilla agar pemangku kepentingan yang sesuai dapat berpartisipasi dalam diskusi.
• Jika tidak, Anda umumnya bebas untuk mengirimkan perubahan secara langsung sebagai pembaruan minor Basis Pengetahuan.

Dengan kata lain, jika perubahan yang Anda usulkan tidak memerlukan keterlibatan pemangku kepentingan produk dan termasuk dalam lingkup revisi minor, tidak perlu melalui Bugzilla.

Mengapa proses ini ada

Proses ini dimaksudkan untuk mendukung kontribusi komunitas. Ini membantu kami:

• Melindungi linimasa rilis
• Memperjelas kepemilikan dan akuntabilitas
• Menjaga kolaborasi yang sehat
• Menghindari gesekan yang disebabkan oleh ekspektasi yang tidak jelas

Kami sangat menghargai keahlian kontributor. Pengetahuan produk yang sudah lama ada di dalam komunitas sangatlah berharga. Pada saat yang sama, pekerjaan konten yang terkait dengan rilis produk dan kolaborasi lintas fungsi memerlukan kepemilikan yang jelas, linimasa yang dapat diprediksi, dan koordinasi yang terstruktur agar kami dapat memastikan pengiriman konten yang akurat dan bermanfaat secara tepat waktu untuk mendukung basis pengguna global Mozilla.

Alur kerja untuk permintaan konten melalui Bugzilla

Proses berikut berlaku untuk permintaan konten baru dan pembaruan mayor yang dikirimkan melalui Bugzilla.

Permintaan konten umumnya terbagi dalam dua kategori:

• Permintaan on-train: Konten yang terkait dengan rilis Firefox yang dijadwalkan. Permintaan ini sensitif terhadap waktu dan harus mengikuti jadwal rilis.
• Permintaan off-train: Konten yang tidak terkait dengan rilis Firefox yang dijadwalkan. Permintaan ini mungkin masih memiliki tenggat waktu target, tetapi umumnya memungkinkan lebih banyak fleksibilitas.

Untuk pratinjau lengkap, silakan buka gambar di tab baru.

1. Pengajuan

Semua pembaruan konten mayor harus diajukan melalui tiket Bugzilla.

2. Triase dan penugasan

Triase: Semua permintaan konten baru melalui proses triase untuk menentukan prioritas dan penugasan. Triase terjadi setiap minggu pada hari Kamis.

Permintaan konten yang terbuka untuk kontributor akan ditandai dengan kata kunci sumo-contributors di Bugzilla. Jika Anda tertarik untuk membantu salah satu permintaan ini, jangan ragu untuk menyatakan minat Anda dengan berkomentar langsung di tiket Bugzilla.

Penugasan: Anggota staf CX akan menugaskan bug tersebut kepada kontributor atau Penulis Teknis. Setelah ditugaskan, Manajer Komunitas atau anggota tim CX lainnya akan memandu Anda melalui proses tersebut. Harap jangan mulai membuat draf sampai anggota staf CX mengonfirmasi penugasan Anda.

Ekspektasi waktu: Triase dilakukan setiap minggu, dan kontributor dapat mengharapkan tanggapan atas permintaan penugasan mereka dalam lima hari kerja.

• Permintaan on-train: Penugasan untuk permintaan on-train sensitif terhadap waktu. Jika permintaan terkait rilis terbuka untuk kontributor tetapi tetap tidak ditugaskan setelah siklus triase berikutnya (5 hari kerja), tim CX dapat menugaskannya ke Penulis Teknis untuk memastikan jadwal rilis tidak tertunda.

• Permintaan off-train: Permintaan off-train umumnya memungkinkan lebih banyak fleksibilitas dan mungkin tetap tersedia untuk penugasan kontributor lebih lama, tergantung pada tenggat waktu yang diminta.

3. Pembuatan konten

Draf konten: Tinjau tiket dengan saksama untuk memahami permintaan, ruang lingkup, rilis target atau tenggat waktu, dan hasil yang diharapkan sebelum memulai pekerjaan Anda.

Setelah bug ditugaskan kepada Anda, Anda dapat mulai membuat konten. Jika draf disediakan oleh tim produk, gunakan sebagai titik awal. Jika tidak, Anda dapat mulai membuat draf konten di Google Docs. Jika Google Docs bukan pilihan, Anda dapat melampirkan draf Anda langsung ke tiket Bugzilla untuk ditinjau.

Pastikan untuk memposting tautan ke draf Anda di tiket Bugzilla dan atur izin dokumen untuk memungkinkan para pemangku kepentingan berkomentar.

Persetujuan konten: Berkolaborasi erat dengan pemohon atau pemangku kepentingan produk untuk memastikan bahwa artikel tersebut lengkap dan akurat. Jika ada informasi yang Anda perlukan untuk menyelesaikan pekerjaan yang hilang, gunakan opsi “Request information from…” di Bugzilla untuk mengumpulkan detail tambahan.

Anda dapat memeriksa baris terakhir dari deskripsi formulir Bugzilla untuk melihat apakah pemberi persetujuan formal telah diidentifikasi untuk draf tersebut.

Ekspektasi waktu:

• Permintaan on-train: Harus diperlakukan sebagai prioritas tinggi. Kecuali jika kemajuan terhambat oleh ketergantungan pada pemangku kepentingan lain, tim CX dapat menugaskan kembali permintaan on-train jika draf yang berarti belum siap untuk ditinjau dalam waktu seminggu setelah penugasan atau seminggu sebelum hari rilis target. Ini membantu memastikan konten siap tepat waktu untuk rilis.

• Permintaan off-train: Draf umumnya harus siap untuk tinjauan pemangku kepentingan setidaknya satu minggu sebelum tenggat waktu yang diminta.

Eskalasi:

• Jika Anda merasa tidak akan dapat memenuhi linimasa yang diharapkan, harap beri tahu tim CX sesegera mungkin dengan memperbarui tiket Bugzilla atau menghubungi anggota staf CX secara langsung. Komunikasi awal memberi kami waktu untuk menyesuaikan rencana atau mencari dukungan tambahan tanpa menunda publikasi.
• Jika Anda tidak dapat memperoleh informasi yang diperlukan dari pemohon, hubungi anggota staf CX yang menugaskan bug untuk membantu mendapatkan informasi yang Anda butuhkan.

4. Penerbitan konten

Publikasikan konten: Setelah draf diselesaikan dan disetujui oleh para pemangku kepentingan, Anda dapat mengirimkan konten sebagai revisi baru pada artikel Basis Pengetahuan yang sebenarnya.

Harap diingat bahwa KB kami menggunakan sintaksis wiki kustom, jadi pastikan konten Anda diformat dengan benar saat mentransfernya dari Google Docs atau alat lain yang Anda gunakan untuk membuat draf konten.

Tinjauan konten: Kontributor harus menunggu revisi KB mereka ditinjau oleh anggota staf atau peninjau KB selain penulis. Pada tahap ini, tinjauan terutama berfokus pada jaminan kualitas dan markup yang tepat, daripada memvalidasi keakuratan informasi produk yang mendasarinya.

Ekspektasi waktu:

• Permintaan on-train: Tiket Bugzilla dapat menentukan tanggal publikasi yang direncanakan yang selaras dengan jadwal rilis Firefox. Harap kirimkan revisi KB untuk ditinjau setidaknya dua hari sebelum tanggal publikasi target, kecuali jika kemajuan terhambat oleh ketergantungan pada pemangku kepentingan lain. Ini memberi peninjau cukup waktu untuk menyelesaikan tinjauan kualitas dan markup akhir tanpa membahayakan tenggat waktu rilis.

• Permintaan off-train: Publikasi harus mengikuti tenggat waktu yang disepakati dalam tiket Bugzilla.

Eskalasi: Jika Anda memerlukan bantuan untuk meninjau revisi Basis Pengetahuan, Anda dapat menghubungi peninjau KB dengan mengirimkan email ke kb-reviewers@mozilla.com.

Penutupan tiket: Setelah artikel KB diterbitkan, tiket Bugzilla dapat ditutup dengan menandainya sebagai Resolved — Fixed.

Memahami persetujuan konten vs. tinjauan konten

Secara historis, kontributor Basis Pengetahuan hanya terbiasa dengan proses tinjauan KB, di mana siapa pun dengan izin peninjau KB dapat meninjau dan menyetujui atau menolak revisi artikel.

Namun, saat bekerja melalui Bugzilla, ada dua pos pemeriksaan yang berbeda:

1. Persetujuan konten: Diselesaikan oleh pemangku kepentingan produk yang sesuai selama proses pembuatan konten di Bugzilla.
2. Tinjauan konten: Diselesaikan oleh peninjau Basis Pengetahuan sebelum artikel diterbitkan.

Meskipun keduanya penting, mereka memiliki tujuan yang berbeda.

Persetujuan konten oleh pemangku kepentingan

Tujuan utama dari persetujuan konten adalah memvalidasi substansi dan maksud konten dengan para pemangku kepentingan produk. Ini termasuk memastikan bahwa draf konten:

• Akurat secara teknis dan mencerminkan perilaku produk yang dimaksud
• Selaras dengan terminologi produk dan konvensi penamaan yang disetujui
• Konsisten dengan suara merek dan pesan Mozilla

Tinjauan konten oleh peninjau KB

Tinjauan konten melengkapi persetujuan dengan berfokus pada kualitas dan presentasi artikel. Selama tahap ini, peninjau Basis Pengetahuan memverifikasi bahwa artikel:

• Menggunakan sintaksis dan pemformatan yang benar, termasuk markup wiki
• Jelas, terstruktur dengan baik, dan mudah diikuti
• Mengikuti editorial Mozilla dan panduan konten

Bersama-sama, kedua langkah ini membantu memastikan bahwa setiap artikel akurat secara teknis dan mudah dipahami oleh pengguna sebelum diterbitkan.

Panduan tambahan untuk kontributor

• Keadilan penugasan

Kontributor yang memiliki hubungan langsung dengan tim produk mungkin mengetahui permintaan yang akan datang sebelum diajukan secara resmi. Namun, harap jangan memulai pekerjaan atau meminta penugasan sebelum permintaan konten dibuat dan ditriase. Ini memastikan bahwa peluang untuk berkontribusi tetap terbuka dan adil bagi semua kontributor.

• Hormati proses triase

Harap berikan waktu 5 hari kerja penuh kepada tim CX untuk meninjau dan menugaskan tiket Bugzilla. Hindari meminta atau menekan untuk keputusan penugasan sebelum periode ini berlalu.

• Komunikasikan perubahan ketersediaan

Kami memahami bahwa situasi tak terduga dapat muncul. Jika Anda tidak dapat memenuhi tenggat waktu yang telah Anda janjikan, harap beri tahu tim CX sesegera mungkin agar kami dapat menyesuaikannya.

• Kebijakan pembukaan kembali tiket Bugzilla

Harap jangan membuka kembali tiket permintaan konten Bugzilla yang sudah diselesaikan untuk meminta peninjauan revisi yang tidak terkait langsung dengan permintaan asli. Untuk pembaruan terkait, tambahkan komentar baru ke tiket yang ada alih-alih membukanya kembali. Jika Anda tidak memiliki izin untuk berkomentar, harap eskalasikan permintaan Anda ke milis kb-reviewers (lihat di bawah).

Membuka kembali tiket tanpa memenuhi standar ini dapat mengakibatkan permintaan ditolak. Harap ikuti Etiket Bugzilla untuk menjaga kolaborasi yang produktif dan saling menghormati.

• Permintaan tinjauan yang dipercepat

Jika artikel baru atau revisi memerlukan penyelesaian yang lebih cepat, seperti perubahan produk yang mendesak, insiden yang sedang berlangsung, atau ketidakakuratan kritis, Anda dapat mengirim email ke kb-reviewers@mozilla.com untuk meminta tinjauan yang dipercepat.

Menemukan permintaan konten untuk dikerjakan

Kontributor didorong untuk terlibat dalam permintaan konten melalui Bugzilla selama permintaan tersebut selaras dengan kriteria yang dijelaskan di bagian berikutnya. Berikut cara Anda dapat mencari permintaan konten yang masuk:

• Pemantauan manual

Anda dapat mengawasi permintaan konten baru dengan memeriksa daftar permintaan konten yang belum ditugaskan. Jika Anda menemukan permintaan yang ingin Anda kerjakan, cukup tinggalkan komentar pada bug tersebut untuk memberi tahu tim CX bahwa Anda tertarik.

Setelah triase, permintaan konten yang terbuka untuk kontribusi komunitas akan ditandai dengan kata kunci sumo-contributors di Bugzilla. Anda dapat menggunakan kata kunci ini untuk melacak permintaan yang sedang berlangsung yang tersedia untuk kontributor.

• Tetap terinformasi

Jika Anda ingin mendapatkan notifikasi tentang permintaan konten baru, pertimbangkan untuk mengawasi komponen Knowledge Base Content di Bugzilla. Untuk melakukannya, buka profil Bugzilla Anda → Edit Profile & Preferences → Component Watching. Pilih support.mozilla.org dalam pemilihan produk, pilih Knowledge Base Content di bidang Component, dan klik tombol Add untuk menyimpan perubahan Anda.

Kriteria penugasan

Permintaan konten dapat ditugaskan kepada kontributor ketika memenuhi kondisi berikut:

• Tidak menyertakan informasi rahasia

Permintaan konten yang melibatkan informasi yang diembargo atau konten sensitif akan tetap menjadi milik staf.

• Tidak melibatkan ketergantungan internal yang ketat

Permintaan yang melibatkan sensitivitas pesan, tinjauan kepatuhan, atau spesifikasi yang berkembang dan memerlukan koordinasi aktif dengan bagian hukum, pemasaran dan komunikasi, keamanan, atau mitra eksternal juga akan tetap ditangani oleh anggota staf.

• Tidak terkait dengan produk berbayar

Permintaan konten yang terkait dengan produk langganan dan fitur berbayar harus tetap menjadi milik staf karena persyaratan hukum, kepatuhan, pengujian, dan koordinasi lintas fungsi. Permintaan ini sering kali melibatkan informasi kontraktual, penagihan, atau informasi sensitif rilis yang memerlukan akuntabilitas terpusat.

• Tidak sensitif terhadap waktu

Permintaan konten dengan waktu penyelesaian kurang dari 5 hari akan tetap ditangani oleh staf untuk memastikan pengiriman tepat waktu dan keselarasan dengan jadwal rilis.

• Kapasitas kontributor

Kontributor dibatasi maksimal 3 tugas aktif pada satu waktu. Ini membantu memastikan eksekusi yang terfokus dan mencegah ketidakseimbangan beban kerja. Kami menyadari bahwa beberapa permintaan mungkin tertunda karena ketergantungan teknis. Jika permintaan tetap terhambat oleh ketergantungan dari sisi produk selama lebih dari dua minggu, tiket tersebut dapat dianggap tidak aktif (basi) dan dikecualikan dari ekspektasi beban kerja kontributor.

Klarifikasi tambahan:

• Ini hanya berlaku untuk permintaan melalui Bugzilla dan tidak berlaku untuk revisi KB minor.
• Ini tidak berlaku untuk pembuatan tanggapan umum forum.
• Staf memegang akuntabilitas akhir untuk konten yang diterbitkan.