Terjemahan dari : How To Ask Questions The Smart Way

Daftar Isi
Terjemahan
Disclaimer
Pengenalan
Sebelum Bertanya
Ketika Kamu Bertanya
      Pilih Forumnya Dengan Hati-Hati
      Forum Web dan IRC khusus newbies terkadang memberi tanggapan cepat
      Langkah Berikutnya, Gunakan Mailing List Proyek
      Gunakan Kalimat Berarti, Subyek Yang Spesifik
      Buat Agar Mudah Di Reply
      Tulis Dengan Jelas, Grammatical, Ejaan Yang Benar
      Kirim Pesan Dalam Format yang Mudah Dibaca
      Tepat dan Jelas Tentang Masalahmu
      Besarnya Pesan Bukanlah Ukuran Ketelitian
      Jangan Berkata Kamu Menemukan Bug
      Bersikap Seperti Hamba Juga Tidak Menolong
      Gambarkan Gejala Masalahnya, Bukan Tebakanmu
      Gambarkan Urut-Urutan Masalah Secara Kronologis
      Gambarkan Tujuanmu bukan Langkahnya
      Jangan Meminta Dibalas Secara Pribadi
      Pertanyaanmu Harus Eksplisit
      Ketika bertanya tentang kode
      Jangan Mengirimkan Tugas PR
      Pangkas Kalimat Yang Tak Perlu
      Jangan Bilang “Mendesak” Walaupun Memang
      Sopan Santun Tidak Pernah Menyakiti Malah Terkadang Membantu
      Tindak Lanjuti Solusi Dengan Catatan Singkat
Bagaimana Menafsirkan Jawaban
      RTFM Dan STFW: Begini Caranya Bilang Kamu Benar-Benar ‘Ngaco
      Kalau Kamu Tidak Mengerti…
      Berhadapan Dengan Sikap Kasar
Agar Tidak Bereaksi Seperti Pecundang
Jangan Ditanyakan
Pertanyaan Bagus Dan Jelek
Jika Kamu Tidak Mendapat Jawaban
Bagaimana Menjawab Pertanyaan Dengan Cara Yang Menolong
Sumber Yang Berhubungan
Acknowledgements

TERJEMAHAN

Terjemahan: Bahasa Indonesia Brazilo-Portuguese Chinese Czech Danish Estonian Finnish French German Hebrew Hungarian Italian Japanese Polish Portuguese Romanian Russian Serbian Spanish Swedish Turkish. Jika anda ingin mengkopi, mirror, menterjemahkan, atau mengutip dari dokumen ini, harap baca terlebih dahulu copying policy.

DISCLAIMER

Banyak proyek situs web merujuk ke document ini pada bagian pertolongan mereka. Itu bagus, itu memang tujuan kami —tapi kalau kamu seorang webmaster yang membuat link ke dokumen ini dihalaman web proyekmu, harap tampilkan dengan jelas dan mencolok di dekat link tersebut yang menyatakan bahwa "kami bukan meja informasi untuk proyek anda".

Belajar dari pengalaman, dengan tidak adanya peringatan seperti itu, kami akan terus menerus diganggu oleh orang-orang idiot yang berpikir bahwa dengan menerbitkan dokumen ini maka tugas kamilah untuk menyelesaikan segala persoalan teknik di dunia ini.

Kalau kamu membaca dokumen ini dengan tujuan mencari bantuan, dan kamu memiliki kesan akan memperolehnya dari pengarang dokumen ini, maka KAMU adalah salah seorang idiot itu. Jangan bertanya kepada kami. Kami akan mengabaikanmu. Disini kami menunjukkan bagaimana cara mendapatkan bantuan dari orang-orang yang benar-benar memahami soal hardware dan software yang kamu pakai, dan seringkali (hampir 99%) itu bukan kami. Kecuali kamu tahu pasti salah seorang pengarang ahli dalam masalah yang kamu hadapi, jangan ganggu kami dan semua orang akan senang

PENGENALAN

Di dunia hacker jenis jawaban yang kamu terima atas pertanyaan teknik yang kamu ajukan sangat tergantung kepada kesulitan proses pembuatan jawaban yang berdasar kepada bagaimana cara kamu bertanya. Panduan ini akan mengajarkan kepada anda bagaimana cara mengajukan pertanyaan yang kira-kira akan menghasilkan jawaban yang memuaskan.

Hal pertama yang harus dipahami adalah hacker senang akan masalah yang sulit dan bagus, pertanyaan yang menantang daya pikir mereka. Kalau tidak begitu kami tidak akan berada disini. Kalau kamu memberikan pertanyaan yang menantang kepada kami untuk dicerna, maka kami akan berterimakasih; pertanyaan yang bagus adalah pujian yang tulus.

Walaupun demikian, hacker terkenal akan reputasinya yang sombong dan tampak tidak ramah dengan pertanyaan yang sederhana. Terkadang kami menampakkan sikap kasar kepada para pemula dan orang yang bodoh. Tapi ini tidak sepenuhnya benar.

Kami, tidak bermaksud meminta maaf, tidak ramah kepada orang yang tampaknya tidak mau berpikir atau mengerjakan 'pekerjaan rumahnya' sebelum mengajukan pertanyaan. Orang seperti itu membuang-buang waktu —mereka mengambil tanpa memberikan kembali, mereka membuang waktu kami yang dapat digunakan untuk orang lain dan pertanyaan yang lain yang lebih menarik dan patut diberikan jawaban. Kami sebut orang seperti ini "losers" (dan untuk alasan tertentu yang bersifat sejarah, kami mengejanya dengan "lusers").

Kami sadar banyak orang yang hanya ingin menggunakan program yang kami tulis dan tidak berminat untuk mempelajari secara detail hal-hal yang bersifat teknis. Bagi kebanyakan orang komputer hanyalah sebuah alat, tidak lebih; mereka memiliki pekerjaan lain yang lebih penting dan kehidupan yang harus dijalani. Kami sadar akan hal itu, dan kami tidak mengharapkan orang lain untuk tertarik kepada masalah- masalah teknis yang mempesona kami. Meskipun begitu gaya kami menjawab pertanyaan dikhususkan untuk orang-orang yang memiliki minat yang sama dan bersedia berpartisipasi aktif dalam pemecahan masalah. Itu tidak akan berubah, meskipun harus, karena jika dilakukan kami akan menjadi tidak efektif pada pekerjaan kami yang kami lakukan dengan baik.

Kami (sebagian besar) sukarelawan. Kami keluar sebentar dari kehidupan kami yang sibuk untuk menjawab pertanyaan, dan saat itu kami diliputi oleh pertanyaan itu. Jadi kami sangat selektif, dengan memilih secara khusus, kami membuang pertanyaan dari orang yang kelihatannya adalah 'losers' dalam rangka efisiensi waktu yang kami gunakan untuk menjawab pertanyaan.

Kalau kamu pikir sikap ini menjengkelkan, bersifat merendahkan, atau angkuh, tolong periksa kembali asumsi anda. Kami tidak memintamu untuk menyembah-nyembah kami —sebenarnya, sebagian besar dari kami lebih senang berpikiran bahwa kita sederajat dan menerimamu dalam budaya kami, jika kamu berusaha untuk itu. Tapi sangat tidak efisien bagi kami untuk mencoba membantu orang yang tidak berusaha membantu diri mereka sendiri. Nggak apa-apa jadi orang bodoh; tapi nggak bagus berpura-pura bodoh.

Jadi selama belum perlu untuk benar-benar kompeten untuk memperoleh perhatian dari kami, SANGATlah perlu untuk bersikap yang mengarah ke kompetensi - waspada, penuh pertimbangan, suka memperhatikan, bersedia menjadi rekan yang aktif dalam pengembangan pemecahan masalah. Jika kamu tidak dapat hidup dengan diskriminasi semacam ini, kami sarankan supaya kamu mempekerjakan saja orang untuk membantu kamu di bidang teknis daripada meminta hacker secara pribadi untuk menyumbangkan waktu mereka untuk menolong kamu.

Jika kamu memutuskan untuk datang kepada kami meminta bantuan, jangan seperti seorang 'losers', atau kelihatan seperti itu. Cara terbaik untuk mendapatkan jawaban yang cepat dan responsif adalah dengan bertanya seperti orang yang pintar, percaya diri, yang menunjukkan bahwa ia sedang membutuhkan bantuan pada satu hal tertentu yang bermasalah.

(Perbaikan untuk panduan ini akan diterima. Kamu dapat mengirimkan e-mail berisi saran ke esr@thyrsus.com, versi Bahasa Indonesia ke alamat e-mail bul54r4atyahoodotcomdotsg). Harap dicatat bahwa panduan ini tidak dimaksudkan agar menjadi panduan umum dalam netiket, dan saya akan menolak saran yang tidak berhubungan dengan usaha untuk mendatangkan jawaban yang berguna di forum teknis)

SEBELUM BERTANYA

Sebelum bertanya masalah teknis melalui e-mail, atau newsgroup atau ruang chatting, lakukan hal-hal sebagai berikut :

  • Cobalah menemukan jawaban dengan mencari di arsip forum yang ingin kamu tanya.

  • Cobalah menemukan jawaban dengan mencari di Web.

  • Cobalah menemukan jawaban dengan membaca manualnya.

  • Cobalah menemukan jawaban dengan membaca FAQ-nya.

  • Cobalah menemukan jawaban dengan penelitian dan percobaan.

  • Cobalah menemukan jawaban dengan bertanya kepada teman yang lebih ahli.

  • Jika kamu seorang programmer, cobalah menemukan jawaban dengan membaca source code-nya.

Saat kamu bertanya tunjukkan bahwa kamu sudah melakukan hal-hal diatas, ini akan menegaskan bahwa kamu bukan sekedar benalu pemalas dan pembuang waktu orang lain. Lebih baik lagi jika kamu juga menunjukkan apa yang sudah kamu pelajari setelah melakukan hal-hal diatas. Kami suka menjawab pertanyaan dari orang yang dapat menunjukkan bahwa mereka dapat belajar dari jawaban itu.

Gunakan siasat seperti mencari menggunakan search engine Google atas kalimat atau pesan kesalahan apapun yang kamu dapat (dan juga cari di group Google selain di halaman web). Hal ini mungkin akan membawa kamu langsung ke halaman dokumentasi yang baku atau ke arsip mailing list yang akan menjawab pertanyaanmu. Bahkan jika tidak menghasilkan, bilang "saya sudah google frase berikut tapi tidak menemukan sesuatu yang tampaknya berguna" dalam e-mail atau pesan permintaan bantuan yang kamu posting, tetapi hanya jika hasil pencariannya tidak membantu.

Pelan-pelan saja, jangan terburu-buru. Jangan berharap dapat menyelesaikan sebuah masalah yang rumit hanya dengan 'googling' beberapa menit. Baca dan pahamilah FAQ yang ada, duduk yang tenang dan pikirkan masalahnya dengan lebih mendalam sebelum meminta pertolongan yang lebih ahli. Percayalah, mereka dapat dengan mudah mengetahui seberapa banyak kamu sudah membaca dan memikirkan masalah itu secara mendalam hanya dari pertanyaan yang kamu ajukan, dan mereka semakin akan membantu jika kamu memang sudah melakukan hal tersebut. Jangan sekonyong-konyong menghujani dengan semua pertanyaan yang kamu miliki hanya karena pencarian pertama kamu tidak menghasilkan jawaban (atau malah terlalu banyak).

Persiapkan pertanyaanmu, pikirkan baik-baik. Pertanyaan yang terdengar tergesa-gesa akan mendapat jawaban yang tergesa-gesa pula, atau bahkan tidak sama sekali. Semakin kau menunjukkan bahwa kamu telah berusaha keras dan berpikir untuk menyelesaikan masalahmu ini sebelum bertanya, semakin besar kemungkinannya kamu akan memperoleh bantuan.

Berhati-hatilah jangan sampai mengajukan pertanyaan yang salah. Jika kamu bertanya sesuatu hal yang dilandasi oleh asumsi yang salah, J Random Hacker biasanya akan menjawab asal-asalan sambil berpikir "Pertanyaan bodoh …", dan berharap dengan pengalaman mendapatkan apa yang kamu minta dan bukannya apa yang kamu butuhkan akan memberimu pelajaran.

Jangan pernah berasumsi bahwa kamu berhak untuk menerima jawaban. Kamu tidak berhak; lagipula kamukan tidak membayar untuk pelayanan ini. Kamu akan memperoleh jawaban, jika kamu memang pantas, dengan cara mengajukan pertanyaan yang substansial, menarik dan menantang daya pikir —yang secara implisit memberikan kontribusi ke pengalaman komunitas daripada yang hanya secara pasif meminta pengetahuan dari yang lain.

Sebaliknya, dengan menjelaskan bahwa kamu bersedia dan mau membantu proses pembuatan jawaban merupakan awal yang sangat baik, "Apakah ada yang mau memberikan petunjuk?", "Apakah ada yang kurang?" dan "Situs mana yang harus saya periksa?" kemungkinan akan memberikan jawaban dibanding "Tolong tuliskan langkah-langkahnya dengan jelas!". Karena kamu menjelaskan bahwa kamu bersedia untuk menyelesaikan prosesnya jika seseorang dapat menunjukkan arah yang benar.

KETIKA KAMU BERTANYA

Pilih Forumnya Dengan Hati-Hati

Kamu harus sensitif memilih tempat untuk mengajukan pertanyaan. Kamu akan diabaikan atau akan di cap LOSER, jika :

  • Mengirimkan pertanyaan ke sebuah forum dimana pertanyaanmu itu OOT (Out Of Topic).

  • Mengirimkan pertanyaan yang terlalu mendasar ke sebuah forum dimana pertanyaan yang diharapkan muncul adalah pertanyaan teknis tingkat lanjut.

  • Mengirim CC ke terlalu banyak newsgroup yang berbeda.

  • Mengirimkan e-mail pribadi ke seseorang yang bukan kenalanmu dan juga bukan seseorang yang bertanggung jawab utuk menyelesaikan masalahmu.

Hacker akan membuang pertanyaan yang salah target seperti ini untuk melindungi saluran komunikasinya tersumbat oleh penyimpangan ini. Jangan sampai ini terjadi denganmu.

Oleh sebab itu, langkah pertama adalah menemukan forum yang tepat. Sekali lagi Google dan metode pencarian web yang lain adalah sahabatmu. Gunakan mereka untuk menemukan halaman web yang isinya kira-kira berhubungan dengan hardware/software-mu yang bermasalah. Biasanya di dalam halaman itu ada link yang akan membawamu ke daftar FAQ (Frequently Asked Question/Pertanyaan yang Sering Ditanyakan) dan ke mailing list serta arsipnya. Mailing list ini adalah tempat terakhir untuk meminta bantuan, jika usahamu sendiri (termasuk membaca FAQ yang kamu temukan) tidak menghasilkan solusi. Halaman web proyek yang bersangkutan biasanya menyediakan prosedur pelaporan untuk 'bug' yang ditemukan, atau menyediakan link untuk itu, jika memang ada cobalah ikuti.

Mengirimkan e-mail ke seseorang atau forum yang belum kamu kenal sangat beresiko. Sebagai contoh, jangan berasumsi bahwa pengarang situs web yang informatif mau menjadi konsultan gratis untuk kamu. Jangan membuat perkiraan yang terlalu optimis bahwa pertanyaanmu akan disambut baik —jika kamu tidak yakin, kirimkan ke tempat lain atau batalkan saja sekalian.

Ketika memilih newsgroup atau mailing list jangan terlalu berpatokan ke namanya; cari FAQ-nya atau sejenis teks perjanjiannya untuk melakukan verifikasi apakah pertanyaanmu termasuk On Topic. Sebelum mengirimkan pertanyaan cobalah untuk membaca beberapa surat terdahulu yang berlalu-lalang jadi kamu bisa dapatkan gambaran kira-kira bagaimana sesuatu itu dikerjakan disana. Bahkan sebenarnya ide yang bagus untuk melakukan pencarian berdasarkan kata kunci dari frase yang terkait dengan masalahmu di arsip newsgroup atau mailing list sebelum mengirimkan pertanyaan. Kamu mungkin akan menemukan jawabannya dan jika tidak itu akan membantumu memformulasikan pertanyaan dengan lebih baik.

Jangan menghujani sekaligus keseluruhan jalur bantuan yang ada, hal ini sangat mengganggu orang lain. Cobalah satu per satu.

Pahami topik pertanyaanmu! Kesalahan klasik yang sering dilakukan adalah bertanya tentang pemrograman interface Windows atau UNIX dalam forum yang dikhususkan kepada bahasa atau tool atau library yang lintas platform. Jika kamu tidak mengerti kenapa ini bisa menjadi masalah yang besar, kamu sebaiknya tidak bertanya apa-apa dahulu sampai kamu paham.

Secara umum pertanyaan yang diajukan ke forum publik yang sudah dipilih dengan baik kemungkinan akan memperoleh jawaban yang berguna dibandingkan jika kita bertanya secara privat. Ada banyak sekali alasannya. Yang paling gampang adalah besarnya responden yang potensial. Yang lain adalah ukuran audiens-nya; hacker lebih senang menjawab pertanyaan yang dapat mendidik banyak orang dibandingkan dengan hanya beberapa orang.

Dapat dimaklumi bahwa hacker yang ahli dan pembuat software yang populer sudah menerima begitu banyak pesan yang salah sasaran. Dengan ikut mengirimkan pesan seperti ini anda bisa saja menjadi seperti, perumpamaannya; sebatang sedotan yang membocorkan punggung unta (kecil namun merusak) —sudah sering terjadi, kontributor suatu program yang populer menarik dukungan mereka karena mereka tidak tahan lagi oleh jaminan kerusakan dalam bentuk lalu lintas e-mail tak berguna yang masuk kedalam account e-mail pribadinya.

Forum Web dan IRC khusus newbies terkadang memberi tanggapan cepat

Kelompok pengguna Linux lokal yang ada di tempatmu, atau distribusi Linux yang anda gunakan, mungkin memberitahukan Forum Web atau kanal IRC bagi newbies untuk mendapatkan bantuan. (Bagi negara yang bukan berbahasa Inggris, forum bagi newbie mungkin lebih banyak dalam bentuk mailing list atau milis). Mereka adalah tempat pertama yang baik, untuk bertanya, terutama apabila kau pikir masalah yang kau hadapi adalah masalah yang sederhana dan sering dihadapi. Kanal IRC yang disediakan ini adalah sebuah undangan bebas untuk mengajukan pertanyaan dan terkadang mendapatkan jawabannya saat itu juga.

Bahkan, jika anda mempunyai program yang bermasalah pada distribusi Linux yang anda gunakan (yang sering timbul sekarang ini), akan lebih baik jika kamu bertanya pada forum atau mailing list dari distribusi Linux tersebut sebelum bertanya langsung pada forum atau mailing list dari proyek atau program itu. Hacker dari proyek tersebut mungkin akan berkata "Makanya, gunakan distrubusi yang kami buat".

Sebelum melakukan posting pada sebuah forum Web, periksa apakah forum tersebut memiliki fasilitas Pencarian. Jika memang ada, coba gunakan dengan beberapa kata kunci yang berkaitan dengan masalahmu; mungkin bisa membantu. Jika sebelumnya anda sudah melakukan pencarian pada Web secara umum (sudah seharusnya anda lakukan), tetaplah lakukan pencarian pada forum itu, mungkin saja search engine yang anda gunakan belum meng-indeks kembali forum ini.

Pada saat ini ada kecenderungan yang meningkat dari sebuah project untuk memberikan dukungan teknis kepada penggunanya lewat forum Web atau kanal IRC, dengan alamat e-mail yang disediakan untuk lalu-lintas pengembang. Jadi, carilah kanal tersebut dahulu ketika mencari bantuan pada proyek yang spesifik.

Langkah Berikutnya, Gunakan Mailing List Proyek

Kalau proyek itu memiliki milis, tuliskan pesannya ke milis itu, jangan ke individu pengembangnya, bahkan jika kamu tahu benar siapa yang dapat menjawab pertanyaanmu dengan baik. Periksa dokumentasi proyek dan homepage-nya untuk mendapatkan alamat milis proyek itu, bila ada gunakanlah. Ada beberapa alasan yang bagus untuk kebijakan ini:

  • Setiap pertanyaan yang cukup bagus untuk ditanyakan ke seorang pengembang akan menjadi nilai tambah bagi keseluruhan group. Sebaliknya, jika kamu pikir pertanyaanmu itu terlalu bodoh untuk ditanyakan di mailing list, jangan dijadikan alasan untuk mengganggu individual developer dengan pertanyaanmu.

  • Bertanya ke alamat yang disebarkan khusus dikalangan developer. Pengembang individu (apalagi jika ia seorang kepala proyek) mungkin terlalu sibuk untuk dapat menjawab pertanyaanmu.

  • Kebanyakan mailing list diarsipkan dan arsipnya di indeks oleh search engine. Seseorang dapat menemukan pertanyaanmu beserta jawabannya di web sehingga tak perlu menanyakannya kembali di milis.

  • Bila pertanyaan tertentu sering ditanyakan, developer dapat menggunakan informasi ini untuk memperbaiki dokumentasinya atau bahkan software-nya. Tetapi jika pertanyaan diajukan secara pribadi, tak seorangpun memiliki gambaran tentang pertanyaan apa yang paling sering ditanyakan.

Jika sebuah proyek memiliki sekaligus mailing list atau forum web untuk pengguna biasa ("user") dan pengembang (developer/hacker) sekaligus, dan pertanyaa anda tidak berkaitan dengan modifikasi pada kode, maka bertanyalah di mailing list/forum untuk pengguna biasa. Jangan beranggapan kamu akan mendapat sambutan di mailing list pengembang, mereka akan menganggap pertanyaan yang kamu ajukan mengganggu aktivitas pengembangan program.

Namun, jika kamu yakin bahwa pertanyaan yang kamu ajukan bukanlah pertanyaan sepele, dan setelah beberapa hari kamu tidak memperoleh jawaban di mailing list/forum pengguna biasa, barulah coba untuk bertanya di mailing list/forum untuk pengembang. Akan lebih bijak buat anda untuk sementara waktu 'bersembunyi' disana sebelum melakukan posting agar dapat mempelajari adat-istiadat setempat (ini adalah saran yang benar-benar bagus untuk mailing list yang bersifat privat atau semi privat).

Jika kamu tak menemukan alamat milis proyek itu tetapi hanya alamat pengurus proyeknya, silahkan tulis pesanmu ke pengurus itu. Bahkan jika kasusnya seperti ini, jangan berasumsi dulu bahwa milisnya tidak ada. Cantumkan dalam pesanmu bahwa kamu sudah berusaha untuk mencari namun tidak menemukan milis yang sesuai. Tulis juga bahwa kamu tidak berkeberatan kalau pesanmu di forward ke milis itu bila memang ada. (Banyak orang percaya bahwa pesan pribadi harus tetap bersifat pribadi, bahkan jika tidak ada rahasia apapun didalamnya. Dengan mengijinkan pesanmu di forward kamu memberikan pilihan ke rekan korespondensimu bagaimana harus menangani pesanmu).

Gunakan Kalimat Berarti, Subyek Yang Spesifik

Didalam milis atau newsgroup, header subyek adalah kesempatan emasmu untuk menarik perhatian ahli yang qualify lewat 50 karakter atau kurang. Jangan sia-siakan dengan ocehan seperti "Please Help Me", "Tolong" (Tinggalkan kata-kata seperti itu, pesan dengan subyek seperti ini secara otomatis akan dibuang). Jangan coba membuat kami terkesan dengan besarnya penderitaan yang kamu alami; sebaliknya gunakan ruang yang tersedia untuk mendeskripsikan masalah dengan singkat.

Konvensi yang bagus untuk header subyek —digunakan oleh banyak organisasi dukungan teknis, adalah "Obyek-Penyimpangan". Bagian "Obyek" menggambarkan apa atau bagian apa yang memiliki masalah dan bagian "Penyimpangan" menggambarkan anomali yang terjadi dari hasil yang diharapkan.

Bodoh : HELP! Video tidak bekerja dengan benar di laptop saya
Cerdas
: X.org 6.8.1 Kursor mouse tidak bekerja, chipset Fooware MV1005
Lebih Cerdas : X.org 6.8.1 kursor mouse di chipset Fooware MV1005 tidak bekerja

Proses penulisan deskripsi “Obyek–Penyimpangan” ini akan membantumu berpikir teratur tentang masalah yang kamu hadapi dengan lebih terperinci. Apa yang terpengaruh? Apakah hanya kursor mouse atau grafik yang lain juga? Apakah spesifik di X.org versi X? Di versi 6.8.1? Apakah spesifik di chipset video Fooware? Dengan model MV1005? Dengan hanya membacanya secara sekilas hacker yang melihat hasilnya akan langsung mengerti masalah apa yang kamu hadapi dan apa yang menyebabkan masalahmu itu.

Secara umum, bayangkan jika kamu melihat indeks dari arsip pertanyaan, yang hanya menampilkan baris subyeknya saja. Buatlah baris subyek pesan mencerminkan pertanyaanmu sehingga jika ada orang lain yang memiliki pertanyaan serupa dengan pertanyaan kamu dapat dengan mudah menemukan jawabannya dengan mengikuti 'thread' yang sudah ada, ketimbang mengirimkan kembali pesan dengan pertanyaan yang sama.

Jika kamu mengajukan pertanyaan dalam pesan reply pastikan untuk merubah baris subyeknya agar mengindikasikan bahwa kamu mengajukan pertanyaan. Baris subyek yang kelihatannya seperti “Re: test” atau “Re: New bug” akan kurang menarik perhatian yang cukup. Hapus juga sebagian pesan yang terdahulu tetapi sisakan frase yang penting agar pembaca yang baru dapat mengerti jalan ceritanya.

Jangan menggunakan tombol reply untuk memulai 'thread' yang baru. Hal ini akan membatasi pembaca pesanmu. Beberapa program pembaca e-mail (e-mail client), seperti mutt, mengijinkan penggunanya untuk melakukan sortir pesan berdasarkan thread-nya. Akibatnya pesan kamu tidak akan terbaca.

Biasakan untuk membuat pesan baru dengan mengklik “new message” atau sejenisnya dan jangan menggunakan pesan lama yang di reply dan di hapus semua isinya dan subyeknya, karena hal ini tidak cukup. Kebanyakan program pembaca e-mail melihat informasi lain yang terkandung didalam header untuk melakukan penggolongannya. Jika kamu melakukan hal ini maka pesan kamu yang sama sekali baru akan dimasukkan kedalam golongan yang sama dengan pesan sebelumnya, akibatnya pesan pertanyaan kamu tidak akan terbaca.

Didalam forum web, petunjuk praktis penggunaan yang baik agak sedikit berbeda, karena pesan-pesannya biasanya lebih terikat kepada jalur diskusi tertentu dan tidak terlihat di luar jalur itu sendiri. Merubah baris subyek ketika me-reply untuk mengajukan pertanyaan tidaklah terlalu penting. Bahkan tidak semua forum mengijinkan reply dengan baris subyek yang terpisah, dan hampir tidak ada yang membaca pesan yang dikirim bila hal tersebut dilakukan. Bagaimanapun, mengajukan pertanyaan dengan reply adalah suatu praktek yang meragukan, karena hanya akan dilihat oleh orang-orang yang membaca 'thread' ini. Jadi lebih baik memulai thread yang baru, kecuali kamu yakin akan mengajukan pertanyaan hanya kepada orang-orang yang aktif pada thread itu.

Buat Agar Mudah Di Reply

Mengakhiri permintaanmu dengan “Tolong reply ke alamat …” membuatnya kecil kemungkinan mendapatkan balasan. Jika kamu tidak mau repot sebentar untuk mengatur header Reply-To di mail agent yang kamu pakai, jangan harap kami mau repot-repot memikirkan masalahmu. Jika program e-mail mu tidak mengijinkan ini, cari program e-mail yang lebih baik. Jika OS kamu tidak mendukung program e-mail yang dapat melakukan itu, cari OS yang lebih baik.

Di forum Web, meminta untuk dibalas lewat e-mail ini adalah sikap yang benar-benar tidak sopan, kecuali kamu percaya informasi itu bersifat sensitif (dan seseorang akan hanya memberitahu anda tetapi tidak ke seluruh anggota forum, gak tahu kenapa). Jika kamu ingin mendapatkan kopinya dalam bentuk e-mail setiap kali seseorang membalas pada thread yang bersangkutan, minta kepada forum Web agar mengirimkannya; fasilitas ini biasanya didukung oleh hampir semua web forum dengan nama opsi seperti "watch this thread" atau "send e-mail on answers" atau yang lain.

Tulis Dengan Jelas, Grammatical, Ejaan Yang Benar

Berdasarkan pengalaman kami temukan bahwa orang yang menulis tidak rapi dan sembrono biasanya juga tidak rapi dan sembrono dalam berpikir dan membuat kode (bisa dijadikan taruhan kalau ‘gak percaya). Menjawab pertanyaan dari orang yang berpikir tidak rapi dan sembrono tidak akan mendapat penghargaan; lebih baik menghabiskan waktu kami untuk hal lain.

Jadi mengekspresikan pertanyaanmu dengan baik dan jelas adalah penting. Jika kamu tidak mau repot melakukannya kami juga tidak mau repot-repot membacanya. Berusahalah sedikit ekstra untuk memoles bahasamu. Tidak harus bersifat formal dan kaku–– sebenarnya, budaya hacker itu bersifat informal, bahasanya penuh humor dan slang yang digunakan dengan penuh ketelitian. Tapi harus tepat; harus menunjukkan bahwa kamu berpikir dan menaruh perhatian.

Ejaan, pemberian tanda baca dan penggunaan huruf kapital yang benar. Jangan mencampuradukkan; “itu” dengan “itunya”, “bit” dengan “byte” atau “nabi” dengan “babi”. Jangan MENGETIK DENGAN HURUF BESAR SEMUA, ini akan dibaca sebagai teriakan dan dianggap kasar (huruf kecil semua sebenarnya menjengkelkan juga, pesan akan sulit dibaca, tidak tahu mana yang awal kalimat).

Lebih ‘parah’ lagi jika kamu menulis seperti orang yang baru ‘melek huruf’ kamu pasti akan diabaikan. Menu1is 5eper7i k4lim4t 1n1 atau a 133t script kiddie h4x0r benar-benar bencana dijamin kamu hanya akan menerima keheningan yang membisu (atau kalau beruntung, tumpukan caci maki dan sindiran tajam) sebagai balasannya.

Jika kamu bertanya di dalam forum yang tidak menggunakan bahasa ibumu kamu akan diberi sedikit kelonggaran bila melakukan kesalahan eja atau tata bahasa–– tetapi tidak ada toleransi bila kamu memang malas (dan ya, biasanya kami dapat mengenali perbedaannya). Selalu menulis dengan bahasa Inggris, kecuali kamu tahu pasti bahasa apa yang digunakan rekan korespondensimu itu. Hacker yang sibuk akan langsung menghapus pesan yang ditulis dalam bahasa yang tidak mereka kenal dan bahasa Inggris adalah bahasa pengantar di Internet, jadi dengan menggunakan bahasa itu kamu dapat meminimalisir kemungkinan pesanmu dibuang tanpa dibaca.

Kirim Pesan Dalam Format yang Mudah Dibaca

Jangan mengirim pesan dalam format yang sulit dibaca kalau tak mau pesanmu dilewati begitu saja, jadi:

  • Kirim dengan format plain text bukan HTML (tidak susah koq untuk mematikan HTML).

  • Lampiran MIME biasanya oke, tetapi jika hanya mereka isinya benar-benar(seperti lampiran kode file atau patch) dan bukannya sekedar teks tambahan yang berisi format tampilan pesanmu yang dibuat oleh e-mail client.

  • Jangan mengirim pesan yang keseluruhan paragrafnya dalam bentuk satu baris panjang yang dilipat (ini akan sulit untuk di reply bila hanya akan diambil sebagian pesannya saja). Kamu harus mempertimbangkan bahwa pembaca pesanmu mungkin hanya membaca e-mailmu dengan tampilan layar selebar 80 karakter, ikuti pola ini dan atur agar teks paragrafmu melipat sebelum karakter ke 80.

  • Tetapi jangan melipat data (seperti data file log atau transkrip sesi) kedalam ukuran kolom tertentu. Data harus disertakan sebagaimana adanya, jadi pembaca pesanmu yakin bahwa mereka melihat bentuk yang sama seperti yang kamu lihat.

  • Jangan melampirkan Penyandi Cetak MIME Quoted ke dalam forum yang menggunakan bahasa Inggris. Penyandi ini berguna jika kamu mengirimkan pesan kedalam bentuk bahasa yang bentuk hurufnya tidak terdapat dalam tabel ASCII, tetapi banyak e-mail agen yang tidak mendukungnya. Ketika program e-mailmu tidak dapat mengartikan bentuk karakternya maka kamu akan melihat simbol seperti =20 bertebaran di teks pesan tersebut, menyebalkan dan tidak menarik.

  • Jangan pernah sekalipun mengharapkan hacker untuk dapat membaca format dokumen proprietary seperti Microsoft Word. Kebanyakan hacker akan bereaksi sama seperti kamu jika menemukan gundukan kotoran babi didepan pintu rumahmu begitu mereka menemukan pesan seperti ini.

  • Jika kamu mengirim pesan dari komputer dengan OS Windows, matikan fitur ‘smart quotes’nya. Dengan ini kau menghindari penyebaran karakter yang tak perlu dalam pesanmu. Jika kamu menggunakan e-mail client berbasis GUI (seperti Microsoft Outlook, Netscape Mesangger, Eudora atau sejenisnya) pengaturan secara default yang dilakukan program ini mungkin akan melanggar peraturan diatas. Kebanyakan program mail tadi memiliki pilihan menu “view source” atau sejenisnya. Gunakan perintah ini untuk memeriksa pesan yang kamu kirim apakah sudah dalam bentuk yang diinginkan tanpa ikut melampirkan sampah karakter yang tak perlu.

  • Pada forum Web, jangan menyalahgunakan penggunaan karakter 'smiley' atau fasilitas 'HTML' (jika memang ada). Satu atau dua buah karakter smiley biasanya tidak masalah, tetapi sebuah teks yang penuh gaya dan warna hanya akan membuat orang berpikir bahwa anda adalah seorang yang payah. Penggunaan karakter smiley, jenis huruf dan warna yang benar-benar berlebihan hanya akan membuat anda seperti seorang cewek abg yang genit, benar-benar ide yang buruk kecuali anda lebih tertarik akan seks daripada jawaban.

Jika anda menggunakan e-mail client berbasis GUI seperti Netscape Messenger, MS Outlook atau yang sejenisnya, berhati-hatilah mungkin saja program itu melanggar semua aturan diatas, jika digunakan dengan pengaturan standarnya (default). E-mail client seperti itu biasanya memiliki sebuah menu seperti "View Source". Gunakan menu ini pada folder surat terkirim anda untuk memastikan anda tidak mengirimkan hal-hal yang tidak berguna.

Tepat dan Jelas Tentang Masalahmu

  • Gambarkan dengan jelas dan hati-hati gejala masalah atau bug yang kau alami.

  • Gambarkan lingkungan dimana masalah itu timbul (mesinnya, OS, aplikasi dan yang lain). Tulis nama vendor distribusi yang kamu gunakan beserta versinya (contoh : “Fedora Core 4”, “Slackware 9.1”, dll).

  • Jelaskan hal-hal apa saja yang telah kamu lakukan untuk mencoba memahami masalah ini sebelum kamu mengajukan pertanyaan ini.

  • Jelaskan langkah-langkah diagnosa apa yang telah kamu lakukan untuk menyelesaikan masalah ini sebelum akhirnya kamu bertanya.

  • Sebutkan dan jelaskan perubahan apa saja yang telah kamu lakukan pada komputer atau konfigurasi softwarenya yang mungkin ada hubungannya.

Persiapkan dirimu untuk pertanyaan yang mungkin akan diajukan hacker untuk menindaklanjuti pertanyaan yang kamu ajukan.

Simon Tatham menulis esai yang bagus berjudul How To Report Bugs Effectively kami sarankan kamu untuk membacanya.

Besarnya Pesan Bukanlah Ukuran Ketelitian

Kamu harus tepat dan jelas. Hal ini tidak diperoleh dengan cara meng-kopi kode atau data dari file log yang besar kedalam pesanmu. Cobalah untuk memotong dan merampingkannya sekecil mungkin kode atau data file log yang besar ini.

Hal ini berguna setidaknya untuk tiga alasan. Pertama : menunjukkan usahamu untuk menyederhanakan pesan; kemungkinan besar kamu akan memperoleh jawaban. Kedua : menyederhanakan pesan akan membuat kemungkinanmu untuk mendapatkan jawaban yang berguna semakin besar. Ketiga : saat proses penyederhanaan mungkin saja kamu menemukan solusi untuk masalahmu itu.

Jangan Berkata Kamu Menemukan Bug

Jangan berkata kalau kamu menemukan bug ketika kamu memiliki masalah dengan software, kecuali kau sangat, sangat yakin akan keadaannya. Saran : Kamu mungkin tidak sepenuhnya yakin kecuali kamu dapat menyediakan source code patch untuk mengatasi masalah itu atau hasil tes perbandingan dengan versi terdahulu yang menunjukkan tingkah laku yang menyimpang.

Ingat, banyak pengguna lain yang tidak mengalami masalah seperti yang kamu hadapi. Kalau tidak kamu sudah mempelajarinya saat membaca dokumentasi atau mencarinya di Internet (kamu melakukan kedua hal itu kan?). Hal ini berarti kemungkinan kamulah yang salah bukan softwarenya.

Orang yang menulis program sudah bekerja keras agar programnya dapat bekerja sebaik mungkin. Jika kamu berkata kamu menemukan bug ini sama saja mengatakan kalau mereka tidak bekerja dengan benar dan kamu sudah menghina mereka –– walaupun kamu benar. Sangatlah tidak bijak untuk berseru “bug” di baris Subyek.

Saat mengajukan pertanyaanmu, ada baiknya jika kamu menulis bahwa kemungkinan kamu melakukan kesalahan, walaupun kamu pribadi yakin kalau kamu benar-benar sudah menemukan bug. Jika itu memang bug maka kamu akan mendengarnya dari jawaban yang diberikan. Mainkan seperti ini, jadi si pengelola proyeklah yang akan meminta maaf kepadamu kalau itu memang bug. Daripada kamu berhutang maaf kepada mereka karena ternyata kamu ‘ngaco.

Bersikap Seperti Hamba Juga Tidak Menolong

Ada orang-orang yang sadar bahwa mereka tidak seharusnya bersikap kasar dan sombong kalau meminta bantuan tetapi mereka malah bersikap kebalikannya bersikap seperti hamba yang meminta belas kasihan. “Saya tahu saya memang hanyalah newbie malang…”, ini menyebalkan dan tidak menolong. Terlebih mengganggu lagi bila penjelasan masalahnya samar-samar.

Jangan membuang waktumu atau kami dengan politik basa-basi semacam ini. Lebih baik kamu menghadirkan fakta dan menjelaskan masalahmu sejelas mungkin. Cara ini lebih baik untuk menjelaskan posisimu dibandingkan memasang sikap seperti hamba sahaya.

Terkadang forum web memiliki tempat yang terpisah khusus untuk pertanyaan bagi newbie. Jika kamu rasa pertanyaan kamu termasuk newbie, bertanyalah disana. Tetapi disana juga jangan bersikap seperti hamba juga.

Gambarkan Gejala Masalahnya, Bukan Tebakanmu

Tidak ada gunanya untuk memberitahu hacker apau yang kamu pikir merupakan sumber masalahmu (kalau memang diagnosamu itu penting, lalu buat apa bertanya ke orang lain?). Jadi pastikan kalau kamu memberitahu mereka gejala masalahmu apa adanya dan bukannya anggapanmu atau teorimu. Biarkan mereka yang mengartikan dan mendiagnosanya.

Bodoh : Saat kompilasi kernel saya terus menerus mengalami error SIG 11, dan saya curiga ada retakan kecil di salah satu jalur motherboard. Bagaimana cara memeriksanya?
Cerdas : PC rakitan saya K6/233 dengan MB FIC-PA2007 (chipsetnya VIA Apollo VP 2), memori 256 Mb Corsair PC 133 SDRAM, mulai sering dapat error SIG 11 20 menit setelah power hidup saat kompilasi kernel, tetapi tidak pernah di 20 menit pertama. Proses reboot tidak merestart clock-nya, tetapi kalau dimatikan semalaman baru bisa. Mengosongkan RAM juga tidak menolong. Berikut ini adalah potongan dari file log sesi kompilasi yang berhubungan.

Karena point-point diatas tampaknya susah ditangkap bagi sebagian orang, ada frase yang dapat mengingatkan anda: "Kaum diagnosis berasal dari Missouri". "Semboyan resmi dari US adalah "Tunjukkan pada saya" (diperoleh pada 1899, ketika anggota Kongres Willard D. Vandiver berkata "Saya datang dari sebuah daerah yang menghasilkan jagung dan kapas dan cockleburs dan kaum Demokrat, dan omongan bercuap-cuap tidak meyakinkan atau memuaskanku. Saya dari Missouri. Tunjukkan kepada saya.") Dalam kasus diagnosis, bukan masalah keragu-raguan tetapi lebih kepada kebutuhan untuk melihat sesuatu sejelas mungkin kepada bukti mentah yang sama yang kamu lihat, bukannya ringkasan atau dugaanmu. Tunjukkan pada kami.

Gambarkan Urut-Urutan Masalah Secara Kronologis

Petunjuk paling berguna untuk mencari tahu apa yang salah biasanya terletak pada apa yang terjadi sebelumnya. Jadi pesanmu harus menggambarkan dengan jelas apa yang telah kamu lakukan terhadap komputermu, sampai akhirnya timbul masalah. Dalam kasus proses yang dijalankan dengan perintah dari konsol atau terminal sangatlah berguna jika dilampirkan juga log sesinya yang sudah ditandai sekitar 20 baris atau lebih.

Kalau program yang bermasalah ini memiliki pilihan diagnosa (seperti –v, untuk verbose ––opsi yang akan memberitahu pengguna pada konsole setiap proses yang dikerjakannya), berpikirlah hati-hati untuk memilih opsi yang akan menyertakan informasi debugging yang berguna.

Jika pesanmu akhirnya bertambah panjang (lebih dari 4 paragraf), ada baiknya kamu jelaskan dengan ringkas masalahmu diawal pesan baru dilanjutkan dengan pernyataan-pernyataan berikutnya secara kronologis. Dengan begini hacker akan paham apa yang harus diperhatikan ketika membaca pesanmu.

Gambarkan Tujuanmu bukan Langkahnya

Jika kamu bertanya karena ingin tahu bagaimana untuk melakukan sesuatu hal (kebalikannya melaporkan temuan bug) mulailah dengan menyatakan tujuanmu. Lalu kemudian jelaskan langkah-langkah apa yang telah kamu lakukan dan sampai dimana.

Seringkali orang yang membutuhkan bantuan teknis terhenti di sebuah jalur prosedur yang mereka pikir itu adalah satu-satunya jalan untuk mencapai tujuan akhir mereka. Mereka meminta bantuan dan menjelaskan langkah apa yang mereka telah lakukan sampai akhirnya terhenti, tetapi mereka tidak sadar telah mengambil jalan yang salah. Bukan langkahnya yang salah tetapi jalannya yang salah. Butuh usaha besar untuk membereskan masalah seperti ini.

Dungu : Bagaimana caranya supaya tool color picker di program Foodraw dapat menerima nilai RGB heksadesimal?
Cerdas : Saya berusaha untuk mengganti tabel warna sebuah gambar dengan nilai yang saya inginkan. Saat ini satu-satunya cara untuk melakukannya adalah dengan cara meng-edit masing-masing kolom tabel, saya tidak bisa membuat tool color picker menerima nilai RGB heksadesimal.

Pertanyaan versi kedualah yang cerdas, pertanyaan ini memberikan kemungkinan jawaban dengan cara yang berbeda namun memiliki hasil yang sama.

Jangan Meminta Dibalas Secara Pribadi

Hacker memiliki keyakinan bahwa penyelesaian masalah haruslah menjadi milik umum, prosesnya harus transparan yang mana usaha pertama sebuah jawaban dapat dan harus dikoreksi bila ternyata terdapat kesalahan atau kurang lengkap oleh orang yang lebih berpengalaman. Juga mereka akan mendapat nilai tambah dari rekan-rekan kelompok mereka atas pengetahuan dan kompetensi mereka.

Kalau kamu meminta dibalas secara pribadi (japri = jalur pribadi) kamu sudah mengacaukan kedua proses diatas. Jangan lakukan ini. Respondenmulah yang berhak memilih jika ia ingin membaasnya secara pribadi ––dan jika ia memang ingin, biasanya karena ia pikir pertanyaannya kurang berbentuk atau kurang jelas sehingga tidak menarik untuk yang lain.

Ada satu pengecualian yang terbatas untuk peraturan ini. Jika kamu pikir pertanyaan seperti itu kira-kira akan mendapatkan jawaban yang hampir-hampir mirip, maka kamu bisa saja berkata seperti ini “E-mail ke saya dan saya akan merangkumnya untuk group”. Tindakan yang terpuji untuk menyimpan dan merangkum banjir pesan yang secara substansial mirip ––kamu harus menepati janji untuk merangkumnya.

Pertanyaanmu Harus Eksplisit

Pertanyaan yang berakhir terbuka akan dirasakan sebagai hal-hal yang membuang waktu. Orang yang kemungkinan besar akan memberimu jawaban yang berguna biasanya adalah orang yang sibuk (karena mereka hanya mengerjakannya sendiri). Orang seperti mereka tidak suka membuang waktu jadi mereka alergi dengan pertanyaan yang tidak terfokus.

Kamu akan memperoleh respon yang berguna jika kamu menjelaskan secara eksplisit apa yang kamu ingin orang lakukan (sediakan petunjuk, kirim kode, periksa patch dan yang lainnya). Ini akan membuat mereka lebih fokus dan secara mutlak menyediakan waktu dan tenaga mereka untuk membantumu. Ini bagus.

Untuk memahami dunia dimana para ahli ini tinggal bayangkanlah keahlian sebagai sumberdaya yang melimpah dan waktu untuk menjawab pertanyaan itu sangat langka. Semakin sedikit waktu mereka yang kamu minta untuk dicurahkan ke masalahmu maka semakin besar kamu akan mendapatkan jawaban dari seseorang yang benar-benar ahli dan sibuk.

Jadi sangatlah berguna untuk membingkai pertanyaanmu agar tidak menyita banyak waktu orang yang ahli untuk menjawabnya ––tetapi seringkali ini berbenturan dengan masalah penyederhanaan pertanyaan. Jadi, contoh ; “Bisakah kamu menunjukkan tempat yang menyediakan penjelasan tentang x?”, akan lebih baik daripada “Bisakah kamu jelaskan tentang x?”. Jika kamu punya kode yang tidak bekerja, akan lebih cerdas untuk bertanya kepada seseorang untuk memberitahu apa yang salah dengan kodemu dibandingkan meminta seseorang untuk memperbaikinya.

Ketika Bertanya Tentang Kode

Jangan meminta orang untuk men-debug kodemu yang bermasalah tanpa memberikan petunjuk masalah apa yang timbul dan apa yang mereka harus perhatikan. Mengirim beberapa ratus baris kode, lalu mengatakan "kodenya tidak bekerja", hanya akan membuat anda diabaikan. Mengirim beberapa lusin baris kode, lalu mengatakan "setelah baris ke 7 saya mengharapkan muncul <x>, tetapi yang muncul malah <y>" akan lebih banyak memperoleh tanggapan.

Jika yang kamu inginkan hanya sekedar review kode, lakukan seperti yang pertama, dan jangan lupa menyebutkan bagian mana yang menurut kamu perlu ditelaah lebih lanjut dan kenapa.

Jangan Mengirimkan Tugas PR

Hacker akan tahu apakah pertanyaanmu itu tugas PR atau bukan; kebanyakan dari kami sudah pernah mengerjakannya sendiri. Pertanyaan itu adalah tugas yang harus kamu kerjakan sendiri, jadi kamu bisa belajar dari pengalamanmu sendiri. Kalau bertanya untuk sekedar petunjuk boleh saja, tetapi tidak untuk penyelesaian keseluruhan.

Jika kamu pikir kamu sudah melontarkan pertanyaan yang mirip pekerjaan rumah, karena kamu tidak bisa menyelesaikannya, cobalah bertanya di forum kelompok pengguna (sebagai persinggahan terakhir) pada mailing list/forum pengguna sebuah proyek. Ketika hacker melihatnya, mungkin akhirnya beberapa pengguna yang lebih ahli akan memberimu petunjuk.

Pangkas Kalimat Yang Tak Perlu

Jangan tergoda untuk mengakhiri pesanmu dengan kalimat tak berarti seperti “Ada yang bisa membantu ?” atau “Ada tidak yang tahu jawabannya?”. Pertama : Jika kamu sudah menulis penjelasan masalahmu dengan benar maka penambahan kalimat seperti itu sangatlah berlebihan. Kedua : Karena berlebihan itu maka hacker akan menganggapnya gangguan belaka ––mereka akan menjawab dengan jawaban yang secara logika tidak salah namun bukannya penyelesaian masalahmu, seperti : “Ya, ada yang bisa membantu !” atau “Tidak ada yang tahu jawabannya !”.

Secara umum mengajukan pertanyaan Ya atau Tidak harus dihindari kecuali kamu ingin jawaban Ya atau Tidak

Jangan Bilang “Mendesak” Walaupun Memang

Itu masalahmu bukan masalah kami. Sangat kontra produktif kalau pesanmu kamu klaim “mendesak”; kebanyakan hacker akan langsung menghapus pesan seperti ini karena pesan ini dianggap kasar dan mementingkan diri sendiri dan berusaha untuk mendapatkan perhatian dengan cepat.

Ada sebuah pengecualian. Cukup berharga untuk menyebutkan kalau kamu menggunakan programnya di tempat dengan profil tinggi, hacker suka yang seperti ini; dalam kasus seperti ini, jika kamu dikejar-kejar waktu dan kamu memintanya dengan sopan sekali, orang mungkin akan cukup tertarik untuk menjawab dengan ce