Penafian
Banyak situs proyek yang menghubungkan dokumen ini dalam bagian mereka tentang cara mendapatkan bantuan. Itu baik-baik saja, itu adalah penggunaan yang kami maksudkan - tetapi jika Anda adalah seorang webmaster yang membuat tautan seperti itu untuk halaman proyek Anda, tolong tampilkan dengan jelas di dekat tautan peringatan bahwa kami bukan meja bantuan untuk proyek Anda!
Kami telah belajar dengan susah payah bahwa tanpa pemberitahuan tersebut, kami akan terus-menerus diganggu oleh orang-orang bodoh yang berpikir bahwa karena telah menerbitkan dokumen ini, tugas kami adalah menyelesaikan semua masalah teknis di dunia.
Jika Anda membaca dokumen ini karena Anda membutuhkan bantuan, dan Anda beranggapan bahwa Anda dapat mendapatkannya langsung dari penulis dokumen ini, maka Anda termasuk dalam kategori orang-orang bodoh yang kami bicarakan. Jangan ajukan pertanyaan kepada kami. Kami akan mengabaikan Anda. Kami di sini untuk menunjukkan kepada Anda bagaimana mendapatkan bantuan dari orang-orang yang benar-benar mengerti tentang perangkat lunak atau perangkat keras yang Anda hadapi, tetapi 99,9% waktu itu bukan kami. Kecuali jika Anda yakin bahwa salah satu penulis adalah ahli dalam hal yang Anda hadapi, biarkan kami sendiri dan semua orang akan lebih bahagia.
Pendahuluan
Di dunia hacker, jenis jawaban yang Anda dapatkan untuk pertanyaan teknis Anda tergantung sebanyak pada cara Anda mengajukan pertanyaan seperti pada kesulitan mengembangkan jawaban. Panduan ini akan mengajarkan Anda cara mengajukan pertanyaan dengan cara yang lebih mungkin memberikan Anda jawaban yang memuaskan.
Sekarang penggunaan open source telah menjadi umum, Anda seringkali dapat mendapatkan jawaban yang baik dari pengguna lain yang lebih berpengalaman seperti dari para hacker. Ini adalah Hal yang Baik; pengguna cenderung sedikit lebih toleran terhadap jenis kegagalan yang sering dialami oleh pemula. Namun, memperlakukan pengguna berpengalaman seperti hacker dengan cara yang kami rekomendasikan di sini pada umumnya akan menjadi cara yang paling efektif untuk mendapatkan jawaban yang berguna dari mereka juga.
Hal pertama yang perlu dipahami adalah bahwa hacker sebenarnya menyukai masalah-masalah sulit dan pertanyaan-pertanyaan yang menantang tentang masalah tersebut. Jika tidak, kami tidak akan berada di sini. Jika Anda memberikan pertanyaan menarik kepada kami, kami akan berterima kasih kepada Anda; pertanyaan yang baik adalah rangsangan dan hadiah bagi kami. Pertanyaan yang baik membantu kami mengembangkan pemahaman kami, dan seringkali mengungkapkan masalah-masalah yang mungkin tidak kami perhatikan atau tidak kami pikirkan sebelumnya. Di antara para hacker, "Pertanyaan yang Bagus!" adalah pujian yang kuat dan tulus.
Meskipun demikian, hacker memiliki reputasi bertemu dengan pertanyaan-pertanyaan sederhana dengan apa yang terlihat seperti sikap permusuhan atau arogansi. Terkadang terlihat seperti kami secara refleks kasar terhadap pemula dan orang-orang yang tidak tahu. Tetapi ini sebenarnya tidak benar.
Apa yang kami lakukan, tanpa permintaan maaf, adalah bersikap tidak ramah terhadap orang-orang yang tampak enggan berpikir atau melakukan pekerjaan rumah mereka sebelum bertanya. Orang-orang seperti itu adalah pemboros waktu - mereka mengambil tanpa memberi balik, dan mereka membuang waktu yang seharusnya kami habiskan untuk pertanyaan lain yang lebih menarik dan orang lain yang lebih pantas mendapatkan jawaban. Kami menyebut orang-orang seperti ini "pecundang" (dan karena alasan sejarah kami kadang-kadang mengejanya "lusers").
Kami menyadari bahwa ada banyak orang yang hanya ingin menggunakan perangkat lunak yang kami tulis, dan yang tidak tertarik untuk mempelajari detail teknis. Bagi sebagian besar orang, komputer hanyalah alat, sarana untuk mencapai tujuan; mereka memiliki hal-hal yang lebih penting untuk dilakukan dan kehidupan yang harus dijalani. Kami mengakui hal itu, dan tidak mengharapkan semua orang untuk tertarik pada masalah teknis yang memikat kami. Namun demikian, gaya kami dalam menjawab pertanyaan disesuaikan untuk orang-orang yang memiliki minat seperti itu dan bersedia menjadi peserta aktif dalam pemecahan masalah. Itu tidak akan berubah. Dan seharusnya tidak; jika berubah, kami akan menjadi kurang efektif dalam hal-hal yang kami lakukan dengan baik.
Kami (sebagian besar) adalah relawan. Kami meluangkan waktu dari kehidupan yang sibuk untuk menjawab pertanyaan, dan terkadang kami kewalahan dengan pertanyaan tersebut. Jadi kami menyaring dengan tegas. Khususnya, kami menolak pertanyaan dari orang-orang yang tampak seperti pecundang untuk menghabiskan waktu menjawab pertanyaan kami dengan lebih efisien, pada orang-orang yang pantas mendapatkan jawaban.
Jika Anda merasa sikap ini menjengkelkan, merendahkan, atau arogan, periksa asumsi Anda. Kami tidak meminta Anda untuk tunduk kepada kami - sebenarnya, sebagian besar dari kami akan sangat senang untuk berurusan dengan Anda sebagai rekan sejajar dan menyambut Anda ke dalam budaya kami, jika Anda melakukan usaha yang diperlukan untuk membuat itu menjadi mungkin. Tetapi bagi kami, tidak efisien untuk mencoba membantu orang-orang yang tidak bersedia membantu diri mereka sendiri. Tidak apa-apa untuk tidak tahu; tetapi tidak baik untuk berpura-pura bodoh.
Jadi, meskipun tidak perlu sudah memiliki kompetensi teknis untuk mendapatkan perhatian dari kami, diperlukan untuk menunjukkan jenis sikap yang mengarah pada kompetensi - waspada, berpikir, perhatian, bersedia menjadi mitra aktif dalam mengembangkan solusi. Jika Anda tidak dapat menerima diskriminasi semacam ini, kami sarankan Anda membayar seseorang untuk kontrak dukungan komersial daripada meminta para hacker untuk secara pribadi memberikan bantuan kepada Anda.
Jika Anda memutuskan untuk datang kepada kami untuk mendapatkan bantuan, Anda tidak ingin menjadi salah satu pecundang. Anda juga tidak ingin terlihat seperti salah satunya. Cara terbaik untuk mendapatkan jawaban yang cepat dan responsif adalah dengan mengajukannya seperti orang yang cerdas, percaya diri, dan memiliki petunjuk yang hanya membutuhkan bantuan dalam satu masalah tertentu.
(Perbaikan untuk panduan ini sangat diterima. Anda dapat mengirimkan saran ke esr@thyrsus.com atau respond-auto@linuxmafia.com. Namun perlu diperhatikan bahwa dokumen ini tidak dimaksudkan sebagai panduan umum untuk etiket, dan kami pada umumnya akan menolak saran yang tidak terkait secara khusus dengan menghasilkan jawaban yang berguna dalam forum teknis.)
Sebelum Anda Bertanya
Sebelum mengajukan pertanyaan teknis melalui surel, atau di forum diskusi, atau di papan obrolan situs web, lakukan hal berikut:
Cobalah mencari jawaban dengan mencari arsip forum atau milis yang akan Anda posting.
Cobalah mencari jawaban dengan mencari di Web.
Cobalah mencari jawaban dengan membaca panduan.
Cobalah mencari jawaban dengan membaca FAQ.
Cobalah mencari jawaban dengan inspeksi atau percobaan.
Cobalah mencari jawaban dengan bertanya kepada teman yang terampil.
Jika Anda seorang programmer, cobalah mencari jawaban dengan membaca kode sumber.
Ketika Anda mengajukan pertanyaan, tunjukkan bahwa Anda telah melakukan hal-hal ini terlebih dahulu; ini akan membantu menyatakan bahwa Anda tidak menjadi orang yang malas dan membuang-buang waktu orang lain. Lebih baik lagi, tunjukkan apa yang telah Anda pelajari dari melakukan hal-hal ini. Kami senang menjawab pertanyaan bagi orang yang telah membuktikan bahwa mereka dapat belajar dari jawaban.
Gunakan taktik seperti melakukan pencarian di Google dengan teks pesan kesalahan apa pun yang Anda dapatkan (mencari di Google Groups serta halaman web). Ini mungkin akan langsung membawa Anda ke dokumentasi perbaikan atau benang milis yang menjawab pertanyaan Anda. Bahkan jika tidak, mengatakan "Saya mencari di Google dengan frasa berikut tetapi tidak menemukan sesuatu yang menjanjikan" adalah hal yang baik untuk dilakukan dalam surel atau posting di forum yang meminta bantuan, jika hanya karena itu mencatat apa yang tidak membantu dalam pencarian. Ini juga akan membantu mengarahkan orang lain dengan masalah serupa ke benang diskusi Anda dengan menghubungkan istilah pencarian ke apa yang semoga menjadi benang masalah dan solusi Anda.
Luangkan waktu Anda. Jangan berharap dapat memecahkan masalah yang rumit dengan beberapa detik pencarian di Google. Baca dan pahami FAQ, duduk, bersantai, dan berikan sedikit pemikiran pada masalah tersebut sebelum mendekati para ahli. Percayalah, mereka akan dapat mengetahui dari pertanyaan Anda seberapa banyak bacaan dan pemikiran yang Anda lakukan, dan akan lebih bersedia membantu jika Anda datang dengan persiapan. Jangan langsung melepaskan semua pertanyaan Anda hanya karena pencarian pertama Anda tidak menemukan jawaban (atau terlalu banyak jawaban).
Siapkan pertanyaan Anda. Pikirkan dengan matang. Pertanyaan yang terdengar tergesa-gesa akan mendapatkan jawaban yang tergesa-gesa, atau sama sekali tidak ada jawaban. Semakin banyak yang Anda lakukan untuk menunjukkan bahwa Anda telah memikirkan dan berusaha memecahkan masalah Anda sebelum mencari bantuan, semakin besar kemungkinan Anda untuk benar-benar mendapatkan bantuan.
Berhati-hatilah terhadap pertanyaan yang salah. Jika Anda mengajukan pertanyaan berdasarkan asumsi yang salah, J. Random Hacker sangat mungkin akan menjawab dengan jawaban yang tidak berguna secara harfiah sambil berpikir "Pertanyaan bodoh..." dan berharap pengalaman mendapatkan apa yang Anda minta daripada apa yang Anda butuhkan akan mengajarkan Anda pelajaran.
Jangan pernah menganggap Anda berhak mendapatkan jawaban. Anda tidak; pada akhirnya, Anda tidak membayar untuk layanan tersebut. Anda akan mendapatkan jawaban, jika Anda memperolehnya, dengan mengajukan pertanyaan yang substansial, menarik, dan memprovokasi pemikiran - pertanyaan yang secara implisit berkontribusi pada pengalaman komunitas daripada hanya pasif meminta pengetahuan dari orang lain.
Di sisi lain, dengan jelas menunjukkan bahwa Anda mampu dan bersedia membantu dalam proses pengembangan solusi adalah awal yang sangat baik. "Bisakah seseorang memberikan petunjuk?", "Apa yang kurang dalam contoh saya?", dan "Situs apa yang seharusnya saya periksa?" lebih mungkin mendapatkan jawaban daripada "Tolong postingkan prosedur yang tepat yang harus saya gunakan." karena Anda membuatnya jelas bahwa Anda benar-benar bersedia menyelesaikan prosesnya jika seseorang dapat mengarahkan Anda ke arah yang tepat.
Ketika Anda Bertanya
Pilih forum dengan hati-hati
Bersikaplah sensitif dalam memilih di mana Anda akan mengajukan pertanyaan. Anda kemungkinan akan diabaikan, atau dianggap sebagai pecundang, jika Anda:
mengirimkan pertanyaan Anda ke forum yang tidak sesuai topik
mengirimkan pertanyaan yang sangat dasar ke forum di mana pertanyaan teknis tingkat lanjut diharapkan, atau sebaliknya
mengirimkan pertanyaan yang sama ke terlalu banyak grup diskusi
mengirimkan surel pribadi kepada seseorang yang bukan kenalan Anda dan bukan yang bertanggung jawab secara pribadi untuk memecahkan masalah Anda
Hacker akan mengabaikan pertanyaan yang ditujukan dengan tidak tepat untuk mencoba melindungi saluran komunikasi mereka dari kebanjiran informasi yang tidak relevan. Anda tidak ingin hal ini terjadi pada Anda.
Langkah pertama, oleh karena itu, adalah menemukan forum yang tepat. Sekali lagi, Google dan metode pencarian Web lainnya adalah teman Anda. Gunakan mereka untuk menemukan halaman proyek yang paling erat terkait dengan perangkat keras atau perangkat lunak yang menyebabkan masalah bagi Anda. Biasanya halaman tersebut akan memiliki tautan ke daftar FAQ (Frequently Asked Questions), dan ke milis proyek dan arsip mereka. Milis ini adalah tempat terakhir yang harus Anda kunjungi untuk mendapatkan bantuan, jika upaya Anda sendiri (termasuk membaca FAQ yang Anda temukan) tidak menemukan solusi. Halaman proyek juga mungkin menjelaskan prosedur pelaporan bug, atau memiliki tautan ke salah satu; jika demikian, ikuti tautan tersebut.
Mengirim surel kepada orang atau forum yang tidak Anda kenal adalah risiko yang paling baik dihindari. Misalnya, jangan menganggap bahwa penulis halaman web informatif ingin menjadi konsultan gratis Anda. Jangan membuat perkiraan optimis tentang apakah pertanyaan Anda akan disambut dengan baik - jika Anda ragu, kirimkan ke tempat lain, atau jangan kirimkan sama sekali.
Ketika memilih forum Web, grup diskusi, atau milis, jangan terlalu mengandalkan nama itu sendiri; cari FAQ atau piagam untuk memverifikasi bahwa pertanyaan Anda sesuai topik. Baca beberapa arsip sebelum posting sehingga Anda mendapatkan gambaran tentang bagaimana hal-hal dilakukan di sana. Sebenarnya, sangat ide bagus untuk melakukan pencarian kata kunci untuk kata-kata yang berhubungan dengan masalah Anda di arsip grup diskusi atau milis sebelum Anda posting. Ini mungkin akan menemukan jawaban bagi Anda, dan jika tidak, itu akan membantu Anda merumuskan pertanyaan yang lebih baik.
Jangan menembakkan semua saluran bantuan yang tersedia sekaligus, itu seperti berteriak dan mengganggu orang. Melakukannya dengan hati-hati.
Pahami topik Anda! Salah satu kesalahan klasik adalah mengajukan pertanyaan tentang antarmuka pemrograman Unix atau Windows di forum yang didedikasikan untuk bahasa atau perpustakaan atau alat yang dapat digunakan di kedua sistem tersebut. Jika Anda tidak memahami mengapa ini adalah kesalahan, lebih baik tidak mengajukan pertanyaan sama sekali sampai Anda mengerti.
Secara umum, pertanyaan yang diajukan ke forum publik yang dipilih dengan baik lebih mungkin mendapatkan jawaban yang berguna daripada pertanyaan yang setara yang diajukan ke forum pribadi. Ada beberapa alasan untuk ini. Salah satunya adalah ukuran kelompok responden potensial. Alasan lain adalah ukuran audiens; hacker lebih suka menjawab pertanyaan yang mendidik banyak orang daripada pertanyaan yang hanya melayani beberapa orang.
Dapat dimaklumi bahwa hacker terampil dan penulis perangkat lunak populer sudah menerima lebih dari bagian adil mereka dalam pesan yang tidak ditujukan dengan tepat. Dengan menambahkan kebanjiran tersebut, dalam kasus ekstrem Anda bahkan bisa menjadi tetesan yang membuat keranjang penuh - cukup banyak kali, kontributor proyek populer telah menarik dukungan mereka karena kerusakan kolateral berupa surel yang tidak berguna ke akun pribadi mereka menjadi tidak tertahankan.
Stack Overflow
Cari, kemudian tanyakan di Stack Exchange
Dalam beberapa tahun terakhir, komunitas situs Stack Exchange telah menjadi sumber daya utama untuk menjawab pertanyaan teknis dan pertanyaan lainnya, dan bahkan menjadi forum pilihan bagi banyak proyek open-source.
Mulailah dengan mencari di Google sebelum melihat Stack Exchange; Google mengindeksnya secara real-time. Ada kemungkinan besar seseorang telah mengajukan pertanyaan serupa sebelumnya, dan situs Stack Exchange seringkali berada di puncak hasil pencarian. Jika Anda tidak menemukan apa pun melalui Google, cari lagi di situs khusus yang paling relevan dengan pertanyaan Anda (lihat di bawah). Pencarian dengan menggunakan tags dapat membantu menyempitkan hasil pencarian.
Jika Anda masih belum menemukan apa pun, postingkan pertanyaan Anda di satu situs di mana pertanyaan tersebut paling sesuai. Gunakan alat pemformatan, terutama untuk kode, dan tambahkan tags yang terkait dengan substansi pertanyaan Anda (terutama nama bahasa pemrograman, sistem operasi, atau perpustakaan yang membuat Anda mengalami kesulitan). Jika seseorang meminta Anda untuk memberikan informasi lebih lanjut, sunting posting utama Anda untuk memasukkannya. Jika ada jawaban yang membantu, klik panah ke atas untuk memberikan suara suka; jika ada jawaban yang memberikan solusi untuk masalah Anda, klik tanda centang di bawah panah suara untuk menerima jawaban tersebut sebagai benar.
Stack Exchange telah berkembang menjadi lebih dari 100 situs, tetapi berikut adalah calon yang paling mungkin:
Super User adalah untuk pertanyaan tentang komputasi umum. Jika pertanyaan Anda tidak tentang kode atau program yang Anda gunakan hanya melalui koneksi jaringan, kemungkinan pertanyaan tersebut masuk ke sini.
Stack Overflow adalah untuk pertanyaan tentang pemrograman.
Server Fault adalah untuk pertanyaan tentang administrasi server dan jaringan.
Beberapa proyek memiliki situs khusus mereka sendiri, termasuk Android, Ubuntu, TeX/LaTeX, dan SharePoint. Periksa situs Stack Exchange untuk daftar terbaru.
Forum Web dan IRC
Kelompok pengguna lokal Anda, atau distribusi Linux Anda, mungkin mengiklankan forum Web atau saluran IRC di mana pemula dapat mendapatkan bantuan. (Di negara-negara yang tidak berbahasa Inggris, forum pemula masih lebih mungkin berupa milis.) Ini adalah tempat pertama yang baik untuk bertanya, terutama jika Anda berpikir Anda mungkin mengalami masalah yang relatif sederhana atau umum. Saluran IRC yang diiklankan adalah undangan terbuka untuk bertanya di sana dan seringkali mendapatkan jawaban secara real-time.
Sebenarnya, jika Anda mendapatkan program yang menyebabkan masalah bagi Anda dari distribusi Linux (seperti yang umum saat ini), mungkin lebih baik untuk bertanya di forum/list milis distribusi sebelum mencoba forum/list proyek program tersebut. Hacker proyek tersebut mungkin hanya akan mengatakan, "gunakan build kami".
Sebelum posting ke forum Web mana pun, periksa apakah ada fitur Pencarian. Jika ada, coba beberapa pencarian kata kunci untuk sesuatu yang mirip dengan masalah Anda; mungkin saja membantu. Jika Anda telah melakukan pencarian Web umum sebelumnya (seperti yang seharusnya Anda lakukan), tetaplah mencari di forum; mesin pencari Web Anda yang meliputi seluruh Web mungkin belum mengindeks semua halaman forum tersebut secara terbaru.
Terdapat kecenderungan yang semakin meningkat bagi proyek-proyek untuk memberikan dukungan pengguna melalui forum Web atau saluran IRC, dengan surel lebih diperuntukkan untuk lalu lintas pengembangan. Jadi carilah saluran-saluran tersebut terlebih dahulu ketika mencari bantuan yang spesifik untuk proyek tersebut.
Di IRC, mungkin lebih baik tidak mengungkapkan deskripsi masalah yang panjang di saluran saat pertama kali. Beberapa orang menganggap ini sebagai membanjiri saluran. Lebih baik mengungkapkan deskripsi masalah dalam satu baris dengan cara yang ditujukan untuk memulai percakapan di saluran.
Sebagai langkah kedua, gunakan milis proyek
Jika sebuah proyek memiliki milis pengembangan, tulislah ke milis tersebut, bukan kepada pengembang individu, bahkan jika Anda yakin tahu siapa yang dapat menjawab pertanyaan Anda dengan baik. Periksa dokumentasi proyek dan halaman utamanya untuk menemukan alamat milis proyek, dan gunakanlah. Ada beberapa alasan bagus untuk kebijakan ini:
Setiap pertanyaan yang cukup baik untuk diajukan kepada satu pengembang juga akan bernilai bagi seluruh kelompok. Sebaliknya, jika Anda curiga pertanyaan Anda terlalu bodoh untuk dikirimkan ke milis, itu bukan alasan untuk mengganggu pengembang individu.
Mengajukan pertanyaan di milis membagi beban di antara para pengembang. Pengembang individu (terutama jika dia adalah pemimpin proyek) mungkin terlalu sibuk untuk menjawab pertanyaan Anda.
Sebagian besar milis diarsipkan dan arsip tersebut diindeks oleh mesin pencari. Jika Anda mengajukan pertanyaan di milis dan pertanyaan tersebut dijawab, orang lain yang mencari di masa depan dapat menemukan pertanyaan Anda dan jawabannya di Web daripada mengajukannya lagi.
Jika pertanyaan tertentu terlihat sering ditanyakan, pengembang dapat menggunakan informasi tersebut untuk meningkatkan dokumentasi atau perangkat lunak itu sendiri agar menjadi lebih jelas. Tetapi jika pertanyaan-pertanyaan tersebut diajukan secara pribadi, tidak ada yang memiliki gambaran lengkap tentang pertanyaan mana yang paling sering diajukan.
Jika sebuah proyek memiliki milis “pengguna” dan milis “pengembang” (atau “hacker”), serta Anda tidak sedang melakukan pengembangan pada kode, ajukan pertanyaan di milis/grup “pengguna”. Jangan menganggap bahwa Anda akan disambut dengan baik di milis/grup pengembang, di mana mereka mungkin menganggap pertanyaan Anda sebagai gangguan yang mengganggu lalu lintas pengembangan mereka.
Namun, jika Anda yakin pertanyaan Anda tidak sepele, dan Anda tidak mendapatkan jawaban di milis/grup “pengguna” selama beberapa hari, coba ajukan di milis/grup “pengembang”. Disarankan agar Anda berada di sana selama beberapa hari atau setidaknya melihat beberapa hari arsip pesan sebelum posting (sebenarnya ini adalah saran yang baik untuk setiap milis pribadi atau semi-pribadi).
Jika Anda tidak dapat menemukan alamat milis proyek, tetapi hanya melihat alamat pemelihara proyek, silakan tulis kepada pemelihara tersebut. Tetapi bahkan dalam kasus itu, jangan menganggap bahwa milis tidak ada. Sebutkan dalam surel Anda bahwa Anda telah mencoba dan tidak dapat menemukan milis yang tepat. Juga sebutkan bahwa Anda tidak keberatan jika pesan Anda diteruskan kepada orang lain. (Banyak orang percaya bahwa surel pribadi harus tetap pribadi, meskipun tidak ada yang rahasia di dalamnya. Dengan memperbolehkan pesan Anda diteruskan, Anda memberikan pilihan kepada koresponden Anda tentang cara menangani surel Anda.)
Gunakan judul subjek yang bermakna dan spesifik
Pada milis, grup diskusi, atau forum Web, judul subjek adalah kesempatan emas Anda untuk menarik perhatian para ahli yang berkualifikasi dalam sekitar 50 karakter atau kurang. Jangan sia-siakan dengan hal-hal seperti "Tolong bantu saya" (apalagi "TOLONG BANTU SAYA!!!!"; pesan dengan subjek seperti itu akan langsung dibuang). Jangan mencoba mengesankan kami dengan kedalaman penderitaan Anda; gunakan ruang tersebut untuk memberikan deskripsi masalah yang super ringkas.
Satu konvensi bagus untuk judul subjek, yang digunakan oleh banyak organisasi dukungan teknis, adalah "objek - penyimpangan". Bagian "objek" menentukan hal atau kelompok hal yang mengalami masalah, dan bagian "penyimpangan" menggambarkan penyimpangan dari perilaku yang diharapkan.
Bodoh:
TOLONG! Video tidak berfungsi dengan baik di laptop saya!
Cerdas:
X.org 6.8.1 kursor mouse yang terdistorsi, chipset vid. Fooware MV1005
Lebih cerdas:
X.org 6.8.1 kursor mouse pada chipset vid. Fooware MV1005 - terdistorsi
Proses menulis deskripsi "objek-penyimpangan" akan membantu Anda mengorganisir pemikiran tentang masalah dengan lebih rinci. Apa yang terpengaruh? Hanya kursor mouse atau grafik lainnya juga? Apakah ini khusus untuk versi X.org dari X? Untuk versi 6.8.1? Apakah ini spesifik untuk chipset video Fooware? Untuk model MV1005? Seorang hacker yang melihat hasilnya dapat segera memahami masalah yang Anda hadapi dan masalah yang Anda alami, hanya dengan sekilas.
Secara umum, bayangkan melihat indeks arsip pertanyaan, dengan hanya menampilkan judul subjek. Buatlah judul subjek Anda mencerminkan pertanyaan Anda dengan baik sehingga orang lain yang mencari di arsip dengan pertanyaan serupa dapat mengikuti benang kusutnya menuju jawaban daripada mengajukan pertanyaan yang sama.
Jika Anda mengajukan pertanyaan dalam sebuah balasan, pastikan untuk mengubah judul subjek untuk menunjukkan bahwa Anda mengajukan pertanyaan. Subjek yang terlihat seperti "Re: test" atau "Re: bug baru" kurang mungkin menarik perhatian yang cukup. Juga, kurangi kutipan pesan sebelumnya seefisien mungkin agar pembaca baru mendapatkan petunjuk.
Jangan hanya membalas pesan di milis dengan tujuan memulai benang percakapan yang sepenuhnya baru. Ini akan membatasi audiens Anda. Beberapa pembaca surel, seperti mutt, memungkinkan pengguna untuk mengurutkan berdasarkan benang dan kemudian menyembunyikan pesan dalam benang dengan melipat benang tersebut. Orang-orang yang melakukannya tidak akan pernah melihat pesan Anda.
Mengubah subjek tidak cukup. Mutt, dan mungkin pembaca surel lainnya, melihat informasi lain dalam header surel untuk menetapkannya ke dalam benang, bukan judul subjeknya. Sebaliknya, mulailah surel yang benar-benar baru.
Pada forum Web, aturan praktik yang baik sedikit berbeda, karena pesan biasanya jauh lebih terikat pada benang percakapan tertentu dan seringkali tidak terlihat di luar benang tersebut. Mengubah subjek saat menjawab pertanyaan tidak penting. Tidak semua forum bahkan memungkinkan subjek terpisah pada balasan, dan hampir tidak ada yang membacanya saat memungkinkan. Namun, mengajukan pertanyaan dalam sebuah balasan sendiri adalah praktik yang meragukan, karena hanya akan terlihat oleh mereka yang sedang mengikuti benang tersebut. Jadi, kecuali Anda yakin Anda ingin bertanya hanya kepada orang-orang yang saat ini aktif dalam benang tersebut, mulailah benang baru.
Mudahkan untuk membalas
Mengakhiri pertanyaan Anda dengan "Harap kirimkan balasan Anda ke ... " membuat kemungkinan Anda mendapatkan jawaban sangat kecil. Jika Anda tidak mau repot menghabiskan beberapa detik untuk mengatur header Balas-Ke yang benar di agen surel Anda, kami juga tidak mau repot menghabiskan beberapa detik untuk memikirkan masalah Anda. Jika program surel Anda tidak memperbolehkan ini, dapatkan program surel yang lebih baik. Jika sistem operasi Anda tidak mendukung program surel yang memperbolehkan ini, dapatkan sistem operasi yang lebih baik.
Pada forum Web, meminta balasan melalui surel adalah tindakan yang kasar, kecuali jika Anda percaya bahwa informasi tersebut mungkin bersifat rahasia (dan seseorang akan, dengan alasan yang tidak diketahui, memberitahu Anda tetapi tidak memberitahu seluruh forum). Jika Anda ingin salinan surel ketika seseorang membalas di benang tersebut, mintalah agar forum Web mengirimkannya; fitur ini didukung hampir di semua tempat dengan opsi seperti "ikuti benang ini", "kirim surel tentang jawaban", dll.
Tulis dengan bahasa yang jelas, tata bahasa yang benar, dan ejaan yang tepat
Melalui pengalaman, kami menemukan bahwa orang yang ceroboh dan tidak rapi dalam menulis juga cenderung ceroboh dan tidak rapi dalam berpikir dan menulis kode (cukup banyak untuk bertaruh, bagaimanapun). Menjawab pertanyaan untuk pemikir yang ceroboh dan tidak rapi tidaklah memuaskan; kami lebih suka menghabiskan waktu kami di tempat lain.
Oleh karena itu, mengekspresikan pertanyaan Anda dengan jelas dan baik sangat penting. Jika Anda tidak mau repot melakukannya, kami juga tidak mau repot memperhatikan. Luangkan usaha ekstra untuk merapikan bahasa Anda. Tidak perlu kaku atau formal — sebenarnya, budaya hacker menghargai bahasa informal, slang, dan humor yang digunakan dengan tepat. Tetapi harus tepat; harus ada indikasi bahwa Anda sedang berpikir dan memperhatikan.
Eja, tanda baca, dan kapitalisasi dengan benar. Jangan bingungkan antara "its" dengan "it's", "loose" dengan "lose", atau "discrete" dengan "discreet". Jangan mengetik SEMUA HURUF KAPITAL; ini dianggap sebagai berteriak dan dianggap kasar. (Menulis semua huruf kecil hanya sedikit lebih mengganggu, karena sulit untuk dibaca. Alan Cox mungkin bisa melakukannya, tetapi Anda tidak bisa.)
Secara umum, jika Anda menulis seperti orang bodoh yang setengah melek huruf, kemungkinan besar Anda akan diabaikan. Jadi jangan menggunakan singkatan pesan instan. Menyebut "you" sebagai "u" membuat Anda terlihat seperti orang bodoh yang setengah melek huruf hanya untuk menghemat dua kali ketik. Lebih buruk lagi: menulis seperti script kiddie l33t hax0r adalah tanda kematian mutlak dan menjamin Anda hanya akan mendapatkan keheningan yang membisu (atau, setidaknya, sejumlah ejekan dan sindiran) sebagai balasannya.
Jika Anda mengajukan pertanyaan dalam sebuah forum yang tidak menggunakan bahasa ibu Anda, Anda akan mendapatkan toleransi terbatas untuk kesalahan ejaan dan tata bahasa — tetapi tidak ada toleransi tambahan untuk kemalasan (dan ya, kami biasanya dapat membedakan perbedaan itu). Juga, kecuali Anda tahu bahasa apa yang dipahami oleh responden Anda, tulislah dalam bahasa Inggris. Hacker sibuk cenderung langsung menghapus pertanyaan dalam bahasa yang tidak mereka pahami, dan bahasa Inggris adalah bahasa kerja Internet. Dengan menulis dalam bahasa Inggris, Anda meminimalkan kemungkinan pertanyaan Anda akan dibuang tanpa dibaca.
Jika Anda menulis dalam bahasa Inggris tetapi bahasa tersebut bukan bahasa ibu Anda, adalah sopan untuk memberi tahu responden potensial tentang kemungkinan kesulitan bahasa dan opsi untuk mengatasinya. Contoh:
Bahasa Inggris bukan bahasa ibu saya; harap maaf jika ada kesalahan pengetikan.
Jika Anda berbicara dalam bahasa $BAHASA, harap kirimkan surel/PM kepada saya; saya mungkin membutuhkan bantuan dalam menerjemahkan pertanyaan saya.
Saya mengenal istilah teknis, tetapi beberapa ekspresi slang dan idiom sulit bagi saya.
Saya telah memposting pertanyaan saya dalam bahasa $BAHASA dan bahasa Inggris. Saya akan senang menerjemahkan tanggapan, jika Anda hanya menggunakan salah satu bahasa tersebut.
Jika Anda membuat pertanyaan Anda sulit dibaca secara buatan, kemungkinan besar pertanyaan tersebut akan diabaikan. Jadi:
Kirim surel dalam format teks biasa, bukan HTML. (Tidak sulit untuk mematikan HTML.)
Lampiran MIME biasanya diperbolehkan, tetapi hanya jika itu adalah konten nyata (seperti berkas sumber terlampir atau patch), dan bukan hanya teks umum yang dihasilkan oleh klien surel Anda (seperti salinan pesan Anda yang lain).
Jangan mengirim surel di mana seluruh paragraf adalah baris yang dilipat berulang kali. (Ini membuatnya terlalu sulit untuk membalas hanya sebagian dari pesan.) Anggaplah bahwa responden Anda akan membaca surel pada tampilan teks berlebar 80 karakter dan atur pembungkus baris Anda sesuai, dengan angka kurang dari 80.
Namun, jangan melipat data (seperti dump berkas log atau transkrip sesi) pada lebar kolom tetap apa pun. Data harus disertakan apa adanya, sehingga responden dapat yakin bahwa mereka melihat apa yang Anda lihat.
Jangan mengirimkan kode Quoted-Printable MIME ke forum berbahasa Inggris. Encoding ini mungkin diperlukan ketika Anda memposting dalam bahasa yang tidak tercakup oleh ASCII, tetapi banyak agen surel tidak mendukungnya. Ketika mereka rusak, semua simbol =20 yang tersebar di teks akan terlihat jelek dan mengganggu — atau bahkan dapat merusak makna teks Anda.
Jangan pernah mengharapkan hacker dapat membaca format dokumen tertutup yang propietari seperti Microsoft Word atau Excel. Kebanyakan hacker bereaksi terhadap ini sama seperti Anda bereaksi ketika memiliki tumpukan kotoran babi yang mengeluarkan uap panas di depan pintu rumah Anda. Bahkan ketika mereka dapat mengatasi, mereka merasa tidak senang harus melakukannya.
Jika Anda mengirim surel dari mesin Windows, matikan fitur "Tanda Kutip Cerdas" yang bermasalah dari Microsoft (Dari menu Alat > Opsi Koreksi Otomatis, hapus centang pada kotak tanda kutip cerdas di bawah Pemformatan Otomatis Saat Anda Mengetik.). Hal ini untuk menghindari penyebaran karakter sampah dalam surel Anda.
Pada forum Web, jangan menyalahgunakan fitur "senyum" dan "HTML" (ketika ada). Satu atau dua senyum biasanya baik-baik saja, tetapi teks berwarna dan fancy cenderung membuat orang berpikir Anda lemah. Menggunakan senyum dan warna serta font secara berlebihan akan membuat Anda terlihat seperti gadis remaja yang girly, yang pada umumnya bukan ide yang baik kecuali jika Anda lebih tertarik pada seks daripada jawaban.
Jika Anda menggunakan klien surel berbasis antarmuka pengguna grafis seperti Netscape Messenger, MS Outlook, atau sejenisnya, berhati-hatilah bahwa klien tersebut mungkin melanggar aturan ini ketika digunakan dengan pengaturan defaultnya. Kebanyakan klien seperti itu memiliki perintah "Lihat Sumber" berbasis menu. Gunakan perintah ini pada sesuatu di folder surel terkirim Anda, dan pastikan bahwa surel dikirim dalam format teks biasa tanpa tambahan yang tidak diperlukan.
Gambarkan gejala masalah atau bug Anda dengan hati-hati dan jelas.
Gambarkan lingkungan di mana masalah terjadi (mesin, sistem operasi, aplikasi, apa pun). Berikan distribusi dan tingkat rilis vendor Anda (misalnya: "Fedora Core 7", "Slackware 9.1", dll.).
Gambarkan penelitian yang Anda lakukan untuk mencoba memahami masalah sebelum Anda mengajukan pertanyaan.
Gambarkan langkah-langkah diagnostik yang Anda ambil untuk mencoba mempersempit masalah sendiri sebelum Anda mengajukan pertanyaan.
Gambarkan perubahan terkini yang mungkin relevan dalam konfigurasi komputer atau perangkat lunak Anda.
Jika memungkinkan, berikan cara untuk mereproduksi masalah dalam lingkungan terkendali.
Lakukan yang terbaik untuk memprediksi pertanyaan yang akan diajukan oleh hacker, dan jawablah di awal dalam permintaan bantuan Anda.
Memberikan kemampuan kepada hacker untuk mereproduksi masalah dalam lingkungan terkendali sangat penting jika Anda melaporkan sesuatu yang menurut Anda adalah bug dalam kode. Dengan melakukannya, peluang Anda untuk mendapatkan jawaban yang berguna dan kecepatan di mana Anda mungkin mendapatkan jawaban tersebut akan meningkat secara signifikan.
Simon Tatham telah menulis sebuah esai yang sangat baik berjudul How to Report Bugs Effectively. Saya sangat menyarankan Anda membacanya.
Volume bukanlah ketepatan
Anda perlu tepat dan informatif. Tujuan ini tidak terpenuhi dengan hanya membuang kode atau data dalam jumlah besar ke dalam permintaan bantuan. Jika Anda memiliki kasus uji yang besar dan rumit yang merusak program, cobalah memangkasnya dan membuatnya sesederhana mungkin.
Ini bermanfaat setidaknya karena tiga alasan. Pertama: dengan terlihat berusaha menyederhanakan pertanyaan, kemungkinan Anda mendapatkan jawaban akan meningkat, Kedua: dengan menyederhanakan pertanyaan, kemungkinan Anda mendapatkan jawaban yang berguna akan meningkat. Ketiga: Dalam proses merapikan laporan bug Anda, Anda mungkin mengembangkan perbaikan atau solusi sementara sendiri.
Jangan terburu-buru mengklaim bahwa Anda telah menemukan bug
Ketika Anda mengalami masalah dengan sebuah perangkat lunak, jangan mengklaim bahwa Anda telah menemukan bug kecuali jika Anda sangat, sangat yakin dengan dasar Anda. Petunjuk: kecuali Anda dapat memberikan patch kode sumber yang memperbaiki masalah, atau tes regresi terhadap versi sebelumnya yang menunjukkan perilaku yang salah, kemungkinan besar Anda tidak cukup yakin. Hal ini berlaku juga untuk halaman web dan dokumentasi; jika Anda menemukan "bug" dalam dokumentasi, Anda harus menyediakan teks pengganti dan halaman mana yang harus digunakan.
Ingat, banyak pengguna lain yang tidak mengalami masalah Anda. Jika tidak, Anda pasti akan mengetahuinya saat membaca dokumentasi dan mencari di Web (Anda sudah melakukannya sebelum mengeluh, bukan?). Ini berarti sangat mungkin bahwa Anda yang melakukan kesalahan, bukan perangkat lunaknya.
Orang-orang yang menulis perangkat lunak bekerja keras untuk membuatnya berfungsi sebaik mungkin. Jika Anda mengklaim telah menemukan bug, Anda akan meragukan kompetensi mereka, yang mungkin menyinggung beberapa dari mereka bahkan jika Anda benar. Terutama tidak diplomatis untuk berteriak "bug" dalam subjek surel.
Ketika mengajukan pertanyaan, sebaiknya tulis seolah Anda yang melakukan kesalahan, bahkan jika Anda secara pribadi cukup yakin telah menemukan bug yang sebenarnya. Jika memang ada bug, Anda akan mendengarnya dalam jawaban. Mainkan peran sehingga pemelihara akan ingin meminta maaf kepada Anda jika bug itu nyata, daripada Anda yang harus meminta maaf kepada mereka jika Anda membuat kesalahan.
Jangan mengharapkan bantuan jika Anda tidak mau melakukan pekerjaan rumah
Beberapa orang yang menyadari bahwa mereka tidak boleh bersikap kasar atau sombong, dan tidak boleh menuntut jawaban, sering kali melampiaskan diri ke ekstrem sebaliknya dengan merendahkan diri. "Saya tahu saya hanya seorang pemula yang kalah, tapi...". Ini mengganggu dan tidak membantu. Ini sangat menjengkelkan ketika dikombinasikan dengan ketidakjelasan tentang masalah yang sebenarnya.
Jangan membuang waktu Anda, atau waktu kami, dengan politik primitif yang kasar. Sebaliknya, sampaikan fakta latar belakang dan pertanyaan Anda sejelas mungkin. Itu adalah cara yang lebih baik untuk memposisikan diri Anda daripada merendahkan diri.
Terkadang forum web memiliki tempat terpisah untuk pertanyaan pemula. Jika Anda merasa memiliki pertanyaan pemula, cukup pergi ke sana. Tetapi jangan merendahkan diri di sana juga.
Gambarkan gejala masalah, bukan tebakan Anda
Tidak berguna memberi tahu hacker apa yang Anda pikir menyebabkan masalah Anda. (Jika teori diagnostik Anda begitu hebat, apakah Anda akan berkonsultasi dengan orang lain untuk mendapatkan bantuan?) Jadi, pastikan Anda memberi tahu mereka gejala mentah dari apa yang salah, bukan interpretasi dan teori Anda. Biarkan mereka melakukan interpretasi dan diagnosis. Jika Anda merasa penting untuk menyatakan tebakan Anda, tandai dengan jelas sebagai tebakan dan jelaskan mengapa jawaban itu tidak berhasil bagi Anda.
Bodoh:
Saya mendapatkan kesalahan SIG11 berturut-turut saat mengompilasi kernel, dan mencurigai adanya retakan halus pada salah satu jejak motherboard. Apa cara terbaik untuk memeriksa hal itu?
Cerdas:
Komputer buatan sendiri K6/233 pada motherboard FIC-PA2007 (chipset VIA Apollo VP2) dengan 256MB Corsair PC133 SDRAM mulai mendapatkan kesalahan SIG11 yang sering sekitar 20 menit setelah daya dihidupkan selama proses pengompilan kernel, tetapi tidak pernah dalam 20 menit pertama. Reboot tidak mengatur ulang waktu, tetapi mematikan daya semalam melakukannya. Menukar semua RAM tidak membantu. Bagian relevan dari log sesi pengompilan yang khas terlampir.
Karena poin sebelumnya tampak sulit dipahami oleh banyak orang, berikut adalah frase untuk mengingat Anda: "Semua ahli diagnostik berasal dari Missouri." Motto resmi negara bagian Amerika Serikat tersebut adalah "Tunjukkan padaku" (diperoleh pada tahun 1899, ketika Anggota Kongres Willard D. Vandiver berkata "Saya berasal dari negara yang menanam jagung, kapas, dan rumput liar serta Demokrat, dan kefasihan berbusa tidak meyakinkan atau memuaskan saya. Saya berasal dari Missouri. Anda harus menunjukkan padaku."). Dalam kasus ahli diagnostik, ini bukan masalah skeptisisme, tetapi kebutuhan yang sebenarnya untuk melihat apa pun yang mendekati bukti mentah yang sama dengan yang Anda lihat, daripada dugaan dan ringkasan Anda. Tunjukkan kepada kami.
Gambarkan gejala masalah Anda secara kronologis
Petunjuk yang paling berguna dalam memecahkan sesuatu yang salah seringkali terletak pada peristiwa yang terjadi segera sebelumnya. Oleh karena itu, cerita Anda harus menjelaskan dengan tepat apa yang Anda lakukan, dan apa yang dilakukan oleh mesin dan perangkat lunak, yang menyebabkan masalah tersebut. Dalam kasus proses baris perintah, memiliki log sesi (misalnya, menggunakan utilitas script) dan mengutip sekitar dua puluh baris yang relevan sangat berguna.
Jika program yang rusak memberikan opsi diagnostik (seperti -v untuk verbose), cobalah memilih opsi yang akan menambahkan informasi debug yang berguna ke transkrip. Ingat bahwa lebih tidak selalu lebih baik; cobalah memilih tingkat debug yang akan memberikan informasi daripada membanjiri pembaca dengan sampah.
Jika cerita Anda berakhir panjang (lebih dari sekitar empat paragraf), mungkin berguna untuk secara ringkas menyatakan masalahnya di awal, lalu ikuti dengan kisah kronologis. Dengan cara ini, hacker akan tahu apa yang harus diperhatikan saat membaca cerita Anda.
Gambarkan tujuan, bukan langkahnya
Jika Anda mencoba mencari tahu cara melakukan sesuatu (bukan melaporkan bug), mulailah dengan menjelaskan tujuannya. Baru kemudian jelaskan langkah khusus menuju tujuan yang menghambat Anda.
Seringkali, orang yang membutuhkan bantuan teknis memiliki tujuan tingkat tinggi dalam pikiran dan terjebak pada apa yang mereka pikir adalah satu jalur tertentu menuju tujuan tersebut. Mereka datang untuk meminta bantuan dengan langkah tersebut, tetapi tidak menyadari bahwa jalurnya salah. Dalam beberapa kasus, diperlukan usaha yang substansial untuk melampaui hal ini.
Bodoh:
Bagaimana cara mengatur pemilih warna pada program FooDraw untuk menerima nilai RGB heksadesimal?
Cerdas:
Saya mencoba mengganti tabel warna pada gambar dengan nilai yang saya pilih. Saat ini satu-satunya cara yang saya lihat untuk melakukannya adalah dengan mengedit setiap slot tabel, tetapi saya tidak bisa membuat pemilih warna FooDraw menerima nilai RGB heksadesimal.
Versi kedua pertanyaan adalah cerdas. Ini memungkinkan jawaban yang menyarankan alat yang lebih cocok untuk tugas tersebut.
Jangan meminta orang untuk membalas melalui surel pribadi
Para hacker percaya bahwa menyelesaikan masalah seharusnya menjadi proses yang transparan dan terbuka di mana upaya pertama untuk menjawab dapat dan harus diperbaiki jika seseorang yang lebih berpengetahuan menyadari bahwa jawabannya tidak lengkap atau tidak benar. Selain itu, para pembantu mendapatkan kepuasan dari menjadi responden yang kompeten dan berpengetahuan di mata rekan mereka.
Ketika Anda meminta balasan secara pribadi, Anda mengganggu baik proses maupun imbalan tersebut. Jangan lakukan ini. Itu adalah pilihan responden apakah akan membalas secara pribadi — dan jika dia melakukannya, biasanya karena dia berpikir pertanyaan tersebut terlalu buruk atau terlalu jelas untuk menarik minat orang lain.
Ada satu pengecualian terbatas dari aturan ini. Jika Anda menganggap pertanyaan tersebut mungkin akan mendapatkan banyak jawaban yang semuanya sangat mirip, maka kata-kata ajaibnya adalah "kirimkan surel kepada saya dan saya akan merangkum jawabannya untuk kelompok". Adalah sopan untuk mencoba menyimpan milis atau forum surel dari banjir posting yang substansial yang sama — tetapi Anda harus menjaga janji untuk merangkumnya.
Jelaskan dengan jelas pertanyaan Anda
Pertanyaan yang terbuka cenderung dianggap sebagai lubang waktu yang terbuka. Orang-orang yang paling mungkin dapat memberi Anda jawaban yang berguna juga adalah orang yang paling sibuk (setidaknya karena mereka mengambil banyak pekerjaan sendiri). Orang-orang seperti itu alergi terhadap lubang waktu yang terbuka, sehingga mereka cenderung alergi terhadap pertanyaan yang terbuka.
Anda lebih mungkin mendapatkan respons yang berguna jika Anda menjelaskan dengan jelas apa yang Anda inginkan responden lakukan (berikan petunjuk, kirimkan kode, periksa patch Anda, apa pun). Ini akan memfokuskan upaya mereka dan secara implisit menetapkan batas atas waktu dan energi yang harus dialokasikan oleh responden untuk membantu Anda. Ini baik.
Untuk memahami dunia tempat para ahli tinggal, pikirkan keahlian sebagai sumber daya yang melimpah dan waktu untuk merespons sebagai sumber daya yang langka. Semakin sedikit komitmen waktu yang Anda minta secara implisit, semakin mungkin Anda mendapatkan jawaban dari seseorang yang benar-benar hebat dan sibuk.
Jadi, berguna untuk merangkai pertanyaan Anda untuk meminimalkan komitmen waktu yang diperlukan untuk dijawab oleh seorang ahli — tetapi ini seringkali bukan hal yang sama dengan menyederhanakan pertanyaan. Oleh karena itu, misalnya, "Bisakah Anda memberi saya petunjuk ke penjelasan yang bagus tentang X?" biasanya adalah pertanyaan yang lebih cerdas daripada "Bisakah Anda menjelaskan X, tolong?". Jika Anda memiliki beberapa kode yang tidak berfungsi, biasanya lebih cerdas untuk meminta seseorang untuk menjelaskan apa yang salah daripada meminta seseorang untuk memperbaikinya.
Saat bertanya tentang kode
Jangan meminta orang lain untuk memperbaiki kode rusak Anda tanpa memberikan petunjuk tentang jenis masalah yang harus mereka cari. Mengirimkan beberapa ratus baris kode, dengan mengatakan "tidak berfungsi", akan membuat Anda diabaikan. Mengirimkan beberapa baris kode, dengan mengatakan "setelah baris 7 saya berharap melihat , tetapi yang terjadi adalah " jauh lebih mungkin mendapatkan respons.
Cara paling efektif untuk menjadi tepat tentang masalah kode adalah dengan menyediakan contoh tes kasus bug minimal. Apa itu contoh tes kasus minimal? Ini adalah ilustrasi dari masalah; cukup kode untuk menunjukkan perilaku yang tidak diinginkan dan tidak lebih dari itu. Bagaimana cara membuat contoh tes kasus minimal? Jika Anda tahu baris atau bagian kode yang menghasilkan perilaku yang bermasalah, buat salinannya dan tambahkan cukup kode pendukung untuk menghasilkan contoh yang lengkap (misalnya, cukup agar sumber dapat diterima oleh kompiler/penerjemah/aplikasi apa pun yang memprosesnya). Jika Anda tidak dapat mempersempitnya ke bagian tertentu, buat salinan sumber dan mulailah menghapus potongan yang tidak mempengaruhi perilaku yang bermasalah. Semakin kecil contoh tes kasus minimal Anda, semakin baik (lihat bagian yang disebut “Volume bukan ketepatan”).
Membuat contoh tes kasus minimal yang sangat kecil tidak selalu mungkin, tetapi mencobanya adalah disiplin yang baik. Ini dapat membantu Anda belajar apa yang perlu Anda lakukan untuk memecahkan masalah sendiri — dan bahkan ketika tidak, hacker senang melihat bahwa Anda telah mencoba. Ini akan membuat mereka lebih kooperatif.
Jika Anda hanya ingin melakukan peninjauan kode, katakan itu sejak awal, dan pastikan untuk menyebutkan area apa yang menurut Anda mungkin perlu ditinjau khusus dan mengapa.
Jangan memposting pertanyaan tugas sekolah
Para hacker pandai dalam mengenali pertanyaan tugas sekolah; kebanyakan dari kami juga pernah melakukannya. Pertanyaan tersebut adalah untuk Anda untuk diselesaikan, sehingga Anda akan belajar dari pengalaman tersebut. Meminta petunjuk adalah hal yang diperbolehkan, tetapi bukan solusi lengkap.
Jika Anda curiga bahwa Anda mendapatkan pertanyaan tugas sekolah, tetapi tetap tidak dapat memecahkannya, cobalah bertanya di forum grup pengguna atau (sebagai upaya terakhir) di milis/grup "pengguna" dari suatu proyek. Meskipun para hacker akan melihatnya, beberapa pengguna tingkat lanjut mungkin setidaknya memberi Anda petunjuk.
Potong pertanyaan yang tidak berguna
Tahanlah godaan untuk mengakhiri permintaan bantuan Anda dengan pertanyaan yang tidak memiliki arti semantik seperti "Bisakah seseorang membantu saya?" atau "Apakah ada jawabannya?" Pertama: jika Anda telah menulis deskripsi masalah Anda dengan cukup kompeten, pertanyaan semacam itu pada dasarnya tidak diperlukan. Kedua: karena pertanyaan semacam itu tidak diperlukan, para hacker menganggapnya mengganggu — dan kemungkinan besar akan memberikan jawaban yang logis tetapi merendahkan seperti "Ya, Anda bisa dibantu" dan "Tidak, tidak ada bantuan untuk Anda."
Secara umum, meminta pertanyaan yang hanya dapat dijawab dengan ya atau tidak adalah hal yang baik untuk dihindari kecuali jika Anda menginginkan jawaban ya atau tidak.
Jangan menandai pertanyaan Anda sebagai "Darurat", bahkan jika itu darurat bagi Anda
Itu adalah masalah Anda, bukan masalah kami. Mengklaim kegentingan sangat mungkin menjadi kontraproduktif: kebanyakan hacker akan langsung menghapus pesan-pesan semacam itu sebagai upaya kasar dan egois untuk meminta perhatian segera dan istimewa. Selain itu, kata "Darurat" (dan upaya lain yang serupa untuk menarik perhatian dalam subjek surel) sering memicu filter spam - penerima yang dituju mungkin sama sekali tidak melihatnya!
Ada satu pengecualian setengah. Mungkin layak menyebutkan jika Anda menggunakan program tersebut di tempat yang terkenal, yang akan membuat para hacker tertarik; dalam kasus seperti itu, jika Anda dalam tekanan waktu, dan Anda mengatakannya dengan sopan, orang-orang mungkin menjadi cukup tertarik untuk menjawab lebih cepat.
Namun, hal ini sangat berisiko, karena metrik para hacker untuk apa yang menarik mungkin berbeda dengan milik Anda. Mengirim dari Stasiun Luar Angkasa Internasional akan memenuhi syarat, misalnya, tetapi mengirim atas nama penyebab amal atau politik yang membuat orang merasa baik hampir pasti tidak. Bahkan, mengirim "Darurat: Bantu saya menyelamatkan anakan anjing lucu yang berbulu!" akan dapat diandalkan membuat Anda dihindari atau dicemooh oleh para hacker yang menganggap anakan anjing lucu yang berbulu penting.
Jika Anda merasa ini misterius, baca kembali bagian lain dari panduan ini berulang kali sampai Anda memahaminya sebelum memposting apa pun.
Kesopanan tidak pernah merugikan, dan terkadang membantu
Bersikaplah sopan. Gunakan "Tolong" dan "Terima kasih atas perhatian Anda" atau "Terima kasih atas pertimbangan Anda". Tunjukkan dengan jelas bahwa Anda menghargai waktu yang orang-orang habiskan untuk membantu Anda secara gratis.
Sejujurnya, ini tidak sepenting (dan tidak bisa menggantikan) tata bahasa yang benar, kejelasan, ketepatan, dan deskripsi yang jelas, menghindari format propietari, dll.; hacker pada umumnya lebih suka mendapatkan laporan bug yang agak kasar tetapi tajam secara teknis daripada kebaikan yang tidak jelas. (Jika ini membuat Anda bingung, ingatlah bahwa kami menghargai sebuah pertanyaan berdasarkan apa yang kami pelajari darinya.)
Namun, jika Anda telah menyusun pertanyaan teknis Anda dengan baik, kesopanan dapat meningkatkan kemungkinan Anda mendapatkan jawaban yang berguna.
(Kami harus mencatat bahwa satu-satunya keberatan serius yang kami terima dari hacker veteran terhadap HOWTO ini adalah dengan rekomendasi sebelumnya untuk menggunakan "Terima kasih sebelumnya". Beberapa hacker merasa bahwa ini menunjukkan niat untuk tidak mengucapkan terima kasih kepada siapa pun setelahnya. Rekomendasi kami adalah untuk entah mengatakan "Terima kasih sebelumnya" terlebih dahulu dan mengucapkan terima kasih kepada responden setelahnya, atau mengekspresikan kesopanan dengan cara yang berbeda, seperti mengatakan "Terima kasih atas perhatian Anda" atau "Terima kasih atas pertimbangan Anda".)
Berikan tanggapan singkat tentang solusi Kirimkan catatan setelah masalah terselesaikan kepada semua orang yang membantu Anda; beri tahu mereka bagaimana hasilnya dan berterima kasih lagi atas bantuan mereka. Jika masalah tersebut menarik minat umum dalam milis atau forum, pantas untuk memposting tanggapan di sana.
Secara optimal, balasan harus menjadi bagian dari rangkaian yang dimulai oleh posting pertanyaan asli, dan harus memiliki tag 'FIXED', 'RESOLVED', atau tag yang sama jelas dalam subjek surel. Pada milis dengan perputaran cepat, responden potensial yang melihat rangkaian tentang "Masalah X" yang diakhiri dengan "Masalah X - FIXED" tahu bahwa tidak perlu membaca rangkaian tersebut (kecuali jika dia secara pribadi menemukan Masalah X menarik) dan dengan demikian dapat menggunakan waktu tersebut untuk memecahkan masalah lain.
Tanggapan Anda tidak perlu panjang dan terperinci; sebuah "Halo — itu adalah kabel jaringan yang rusak! Terima kasih, semuanya. - Bill" lebih baik daripada tidak ada. Sebenarnya, ringkasan yang singkat dan jelas lebih baik daripada disertasi panjang kecuali jika solusinya memiliki kedalaman teknis yang nyata. Katakan tindakan apa yang memecahkan masalah, tetapi Anda tidak perlu mengulang seluruh urutan perbaikan masalah.
Untuk masalah yang memiliki kedalaman tertentu, pantas untuk memposting ringkasan riwayat perbaikan masalah. Gambarkan pernyataan masalah akhir Anda. Gambarkan apa yang berhasil sebagai solusi, dan tunjukkan jalan buntu yang dapat dihindari setelah itu. Jalan buntu harus datang setelah solusi yang benar dan materi ringkasan lainnya, bukan menjadikan tanggapan sebagai cerita detektif. Sebutkan nama orang-orang yang membantu Anda; Anda akan mendapatkan teman dengan cara ini.
Selain bersikap sopan dan informatif, jenis tanggapan semacam ini akan membantu orang lain yang mencari arsip milis/grup diskusi untuk mengetahui dengan pasti solusi mana yang membantu Anda dan dengan demikian juga dapat membantu mereka.
Terakhir, tetapi tidak kalah penting, jenis tindak lanjut ini membantu semua orang yang membantu merasa puas dengan penyelesaian masalah. Jika Anda bukan seorang teknisi atau hacker, percayalah bahwa perasaan ini sangat penting bagi para ahli dan pakar yang Anda minta bantuan. Narasi masalah yang berakhir tanpa penyelesaian yang jelas adalah hal yang membuat frustrasi; para hacker ingin melihat masalah tersebut terpecahkan. Kebaikan hati yang Anda berikan akan sangat membantu Anda ketika Anda membutuhkan untuk mengajukan pertanyaan selanjutnya.
Pertimbangkan bagaimana Anda dapat mencegah orang lain mengalami masalah yang sama di masa depan. Tanyakan pada diri sendiri apakah perbaikan dokumentasi atau FAQ akan membantu, dan jika jawabannya ya, kirimkan perbaikan tersebut kepada pemelihara.
Di antara para hacker, jenis perilaku tindak lanjut yang baik ini sebenarnya lebih penting daripada kesopanan konvensional. Inilah cara Anda mendapatkan reputasi bermain dengan baik dengan orang lain, yang bisa menjadi aset yang sangat berharga.
Bagaimana Menafsirkan Jawaban
RTFM dan STFW: Cara Menyadari Bahwa Anda Telah Berbuat Bodoh
Ada tradisi kuno yang dihormati: jika Anda mendapatkan balasan yang berbunyi "RTFM", orang yang mengirimnya berpikir Anda seharusnya sudah Membaca Manual Sialan. Dia hampir pasti benar. Pergilah membacanya.
RTFM memiliki versi yang lebih muda. Jika Anda mendapatkan balasan yang berbunyi "STFW", orang yang mengirimnya berpikir Anda seharusnya sudah Mencari di Web Sialan. Dia hampir pasti benar. Pergilah mencarinya. (Versi yang lebih ringan dari ini adalah ketika Anda diberitahu "Google adalah temanmu!")
Di forum web, Anda juga mungkin disuruh mencari arsip forum. Bahkan, seseorang mungkin sangat baik hati untuk memberikan tautan ke thread sebelumnya di mana masalah ini telah diselesaikan. Tetapi jangan mengandalkan pertimbangan ini; lakukan pencarian di arsip sebelum bertanya.
Seringkali, orang yang meminta Anda melakukan pencarian memiliki manual atau halaman web dengan informasi yang Anda butuhkan terbuka, dan melihatnya saat dia mengetik. Balasan ini berarti bahwa orang yang merespons berpikir (a) informasi yang Anda butuhkan mudah ditemukan, dan (b) Anda akan belajar lebih banyak jika Anda mencari informasi tersebut daripada jika Anda diberi makan dengan sendok.
Anda tidak boleh tersinggung oleh ini; menurut standar hacker, responden Anda sedang menunjukkan jenis penghargaan kasar dengan tidak mengabaikan Anda. Sebaliknya, bersyukurlah atas kebaikan hati seperti itu.
Jika Anda tidak mengerti...
Jika Anda tidak mengerti jawabannya, jangan langsung membalas dengan permintaan klarifikasi. Gunakan alat yang sama yang Anda gunakan untuk mencoba menjawab pertanyaan asli Anda (manual, FAQ, Web, teman yang terampil) untuk memahami jawabannya. Kemudian, jika Anda masih perlu meminta klarifikasi, tunjukkan apa yang telah Anda pelajari.
Misalnya, anggaplah saya memberi tahu Anda: "Sepertinya Anda memiliki zentry yang macet; Anda perlu menghapusnya." Kemudian: ini adalah pertanyaan tindak lanjut yang buruk: "Apa itu zentry?" Ini adalah pertanyaan tindak lanjut yang baik: "Baik, saya membaca halaman man dan zentry hanya disebutkan di bawah sakelar -z dan -p. Tidak ada yang mengatakan apa pun tentang menghapus zentry. Apakah ini salah satunya atau apakah saya melewatkan sesuatu di sini?"
Menghadapi ketidak sopanan
Banyak hal yang terlihat seperti ketidak sopanan di kalangan hacker sebenarnya tidak dimaksudkan untuk menyakiti perasaan. Sebaliknya, itu adalah hasil dari gaya komunikasi langsung yang memotong omong kosong yang alami bagi orang-orang yang lebih peduli tentang memecahkan masalah daripada membuat orang lain merasa nyaman.
Ketika Anda merasa ada ketidak sopanan, cobalah untuk bereaksi dengan tenang. Jika seseorang benar-benar melakukan hal yang berlebihan, sangat mungkin seseorang yang senior di milis, forum, atau grup diskusi akan menegurnya. Jika itu tidak terjadi dan Anda kehilangan kesabaran, kemungkinan orang yang Anda marahi sedang berperilaku sesuai dengan norma komunitas hacker dan Anda akan dianggap salah. Ini akan merugikan peluang Anda untuk mendapatkan informasi atau bantuan yang Anda inginkan.
Di sisi lain, Anda kadang-kadang akan menemui ketidak sopanan dan sikap yang tidak perlu. Sisi lain dari hal di atas adalah bahwa sah-sah saja untuk menyerang pelaku yang sebenarnya dengan tajam, dengan membedah perilaku mereka dengan pisau bedah verbal yang tajam. Pastikan Anda sangat yakin dengan dasar Anda sebelum mencoba ini. Garis antara memperbaiki ketidak sopanan dan memulai perang kata yang tidak berguna sangat tipis sehingga hacker sendiri sering kali melanggarnya; jika Anda pemula atau orang luar, peluang Anda untuk menghindari kesalahan semacam itu rendah. Jika Anda mencari informasi bukan hiburan, lebih baik tidak mengetik daripada mempertaruhkan hal ini.
(Beberapa orang berpendapat bahwa banyak hacker memiliki bentuk ringan autisme atau Sindrom Asperger, dan sebenarnya kehilangan beberapa sirkuit otak yang melumasi interaksi sosial manusia "normal". Mungkin benar, mungkin juga tidak. Jika Anda bukan seorang hacker, mungkin akan membantu Anda mengatasi eksentrisitas kami jika Anda menganggap kami sebagai orang yang mengalami kerusakan otak. Lanjutkan saja. Kami tidak peduli; kami menyukai apa pun yang kami miliki, dan umumnya skeptis terhadap label klinis.)
Pandangan Jeff Bigler tentang filter taktis juga relevan dan layak dibaca.
Pada bagian berikutnya, kita akan membahas masalah yang berbeda; jenis "ketidak sopanan" yang akan Anda lihat ketika Anda berperilaku buruk.
Menghadapi Tantangan dengan Baik
Kemungkinan Anda akan membuat kesalahan beberapa kali di forum komunitas hacker — dengan cara yang dijelaskan dalam artikel ini, atau yang serupa. Dan Anda akan diberitahu dengan jelas bagaimana Anda salah, mungkin dengan komentar yang berwarna-warni. Di depan publik.
Ketika hal ini terjadi, hal terburuk yang bisa Anda lakukan adalah mengeluh tentang pengalaman tersebut, mengklaim bahwa Anda telah diserang secara verbal, menuntut permintaan maaf, berteriak, menahan napas, mengancam mengajukan gugatan hukum, mengeluh kepada majikan orang-orang, meninggalkan kursi toilet terangkat, dll. Sebaliknya, inilah yang harus Anda lakukan:
Lupakan saja. Ini normal. Bahkan, ini sehat dan pantas.
Standar komunitas tidak dipertahankan dengan sendirinya: Mereka dipertahankan oleh orang-orang yang secara aktif menerapkannya, dengan terlihat, di depan publik. Jangan mengeluh bahwa semua kritik seharusnya disampaikan melalui surel pribadi: Itu bukan cara kerjanya. Juga tidak berguna untuk bersikeras bahwa Anda telah dihina secara pribadi ketika seseorang mengomentari bahwa klaim Anda salah, atau bahwa pandangannya berbeda. Itu adalah sikap pecundang.
Terdapat forum hacker di mana, karena rasa sopan yang berlebihan, peserta dilarang mengemukakan kesalahan dalam postingan orang lain, dan diberitahu "Jangan mengatakan apa pun jika Anda tidak bersedia membantu pengguna." Kepergian peserta yang penuh wawasan ke tempat lain menyebabkan forum tersebut terjerumus ke dalam omong kosong yang tidak berarti dan menjadi tidak berguna sebagai forum teknis.
Terlalu "ramah" (dalam mode seperti itu) atau berguna: Pilih salah satu.
Ingatlah: Ketika seorang hacker memberi tahu Anda bahwa Anda telah membuat kesalahan, dan (tidak peduli seberapa kasar) memberi tahu Anda untuk tidak melakukannya lagi, dia bertindak karena peduli terhadap (1) Anda dan (2) komunitasnya. Lebih mudah baginya untuk mengabaikan Anda dan menghilangkan Anda dari hidupnya. Jika Anda tidak bisa bersyukur, setidaknya tunjukkan sedikit martabat, jangan mengeluh, dan jangan berharap diperlakukan seperti boneka rapuh hanya karena Anda adalah pemula dengan jiwa yang teatrikal dan delusi keistimewaan.
Kadang-kadang orang akan menyerang Anda secara pribadi, menyulut perdebatan tanpa alasan yang jelas, dll., bahkan jika Anda tidak membuat kesalahan (atau hanya membuat kesalahan dalam imajinasi mereka). Dalam hal ini, mengeluh adalah cara untuk benar-benar membuat kesalahan.
Pembakar ini adalah orang-orang yang tidak berpengalaman tetapi percaya bahwa mereka adalah ahli, atau psikolog calon yang menguji apakah Anda akan membuat kesalahan. Pembaca lainnya mengabaikan mereka, atau mencari cara untuk menangani mereka sendiri. Perilaku pembakar ini menciptakan masalah bagi mereka sendiri, yang tidak perlu Anda khawatirkan.
Jangan biarkan diri Anda terlibat dalam perang kata, juga. Sebagian besar pembakaran sebaiknya diabaikan — setelah Anda memeriksa apakah itu benar-benar pembakaran, bukan petunjuk tentang cara Anda membuat kesalahan, dan bukan jawaban yang tersembunyi dengan cerdik untuk pertanyaan sebenarnya Anda (ini juga terjadi).
Pertanyaan yang Tidak Perlu Diajukan
Berikut adalah beberapa pertanyaan bodoh klasik, dan apa yang dipikirkan oleh para hacker ketika mereka tidak menjawabnya.
| P: | Di mana saya bisa menemukan program atau sumber daya X? |
| J: | Di tempat yang sama dengan tempat saya menemukannya, bodoh — di ujung pencarian web. Wah, apakah semua orang belum tahu cara menggunakan Google sekarang? |
| P: | Bagaimana cara menggunakan X untuk melakukan Y? |
| J: | Jika yang Anda inginkan adalah melakukan Y, Anda seharusnya bertanya tanpa mengasumsikan penggunaan metode yang mungkin tidak sesuai. Pertanyaan dalam bentuk ini sering menunjukkan orang yang tidak hanya tidak tahu tentang X, tetapi bingung tentang masalah Y yang sedang mereka selesaikan dan terlalu terpaku pada detail situasi tertentu mereka. Biasanya lebih baik mengabaikan orang-orang seperti ini sampai mereka mendefinisikan masalah mereka dengan lebih baik. |
| P: | Bagaimana cara mengonfigurasi prompt shell saya? |
| J: | Jika Anda cukup pintar untuk bertanya pertanyaan ini, Anda cukup pintar untuk RTFM dan mencari tahu sendiri. |
| P: | Bisakah saya mengonversi dokumen AcmeCorp menjadi file TeX menggunakan konverter file Bass-o-matic? |
| J: | Coba saja dan lihat. Jika Anda melakukannya, Anda akan (a) mengetahui jawabannya, dan (b) berhenti membuang waktu saya. |
| P: | {Program saya, konfigurasi saya, pernyataan SQL saya} tidak berfungsi. |
| J: | Ini bukan pertanyaan, dan saya tidak tertarik untuk bermain Twenty Questions untuk menggali pertanyaan sebenarnya dari Anda — saya memiliki hal yang lebih baik untuk dilakukan. Melihat sesuatu seperti ini, reaksi saya biasanya salah satu dari berikut:apakah Anda memiliki sesuatu yang lain untuk ditambahkan?oh, sayang sekali, saya harap Anda bisa memperbaikinya.dan ini berkaitan dengan saya secara langsung bagaimana? |
| P: | Saya mengalami masalah dengan mesin Windows saya. Bisakah Anda membantu? |
| J: | Ya. Buang sampah Microsoft itu dan instal sistem operasi sumber terbuka seperti Linux atau BSD.Catatan: Anda dapat mengajukan pertanyaan terkait mesin Windows jika itu berkaitan dengan program yang memiliki versi resmi Windows, atau berinteraksi dengan mesin Windows (misalnya, Samba). Hanya jangan terkejut jika jawabannya adalah masalah ada pada Windows dan bukan pada programnya, karena Windows secara umum sangat rusak dan seringkali hal ini terjadi. |
| P: | Program saya tidak berfungsi. Saya pikir fasilitas sistem X rusak. |
| J: | Meskipun mungkin Anda adalah orang pertama yang menyadari kekurangan yang jelas dalam pemanggilan sistem dan perpustakaan yang banyak digunakan oleh ratusan atau ribuan orang, lebih mungkin bahwa Anda sama sekali tidak tahu. Klaim luar biasa membutuhkan bukti yang luar biasa; ketika Anda membuat klaim seperti ini, Anda harus mendukungnya dengan dokumentasi yang jelas dan lengkap tentang kasus kegagalan. |
| P: | Saya mengalami masalah saat menginstal Linux atau X. Bisakah Anda membantu? |
| J: | Tidak. Saya perlu akses langsung ke mesin Anda untuk memperbaiki masalah ini. Tanyakan bantuan langsung kepada kelompok pengguna Linux lokal Anda. (Anda dapat menemukan daftar kelompok pengguna di sini.)Catatan: pertanyaan tentang menginstal Linux mungkin tepat jika Anda berada di forum atau milis tentang distribusi tertentu, dan masalahnya ada pada distribusi itu; atau di forum kelompok pengguna lokal. Dalam hal ini, pastikan untuk menjelaskan detail yang tepat tentang kegagalan yang terjadi. Tetapi lakukan pencarian dengan cermat terlebih dahulu, dengan mencari "linux" dan semua perangkat keras yang mencurigakan. |
| P: | Bagaimana cara membobol akun root/mencuri hak channel-ops/membaca surel seseorang? |
| J: | Anda rendah hati karena ingin melakukan hal-hal seperti itu dan bodoh karena meminta bantuan seorang hacker. |
Pertanyaan yang Baik dan Buruk
Terakhir, saya akan menjelaskan cara mengajukan pertanyaan dengan cara yang cerdas melalui contoh; pasangan pertanyaan tentang masalah yang sama, satu diajukan dengan cara yang bodoh dan satu lagi dengan cara yang cerdas.
Bodoh: Di mana saya bisa mencari tahu tentang Foonly Flurbamatic?
Pertanyaan ini hanya meminta jawaban "STFW" sebagai balasan.
Cerdas: Saya menggunakan Google untuk mencari "Foonly Flurbamatic 2600" di Web, tetapi saya tidak menemukan hasil yang berguna. Bisakah saya mendapatkan petunjuk tentang informasi pemrograman mengenai perangkat ini?
Pertanyaan ini sudah mencari dengan menggunakan STFW, dan terdengar seperti ada masalah nyata.
Bodoh: Saya tidak bisa mengompilasi kode dari proyek foo. Mengapa itu rusak?
Penanya mengasumsikan bahwa orang lain yang membuat kesalahan. Pemikiran arogan...
Cerdas: Kode dari proyek foo tidak dapat dikompilasi di bawah Nulix versi 6.2. Saya sudah membaca FAQ, tetapi tidak ada informasi tentang masalah terkait Nulix di dalamnya. Berikut ini adalah transkrip dari upaya kompilasi saya; apakah ini kesalahan yang saya lakukan?
Penanya telah menyebutkan lingkungan, membaca FAQ, menunjukkan kesalahan, dan tidak menganggap masalahnya adalah kesalahan orang lain. Pertanyaan ini mungkin layak mendapatkan perhatian.
Bodoh: Saya mengalami masalah dengan motherboard saya. Bisa siapa saja membantu?
Respon J. Random Hacker terhadap ini kemungkinan besar adalah "Benar. Apakah Anda juga butuh diburp dan diganti popoknya?" diikuti dengan menekan tombol hapus.
Cerdas: Saya mencoba X, Y, dan Z pada motherboard S2464. Ketika itu tidak berhasil, saya mencoba A, B, dan C. Perhatikan gejala aneh ketika saya mencoba C. Jelas florbish sedang grommicking, tetapi hasilnya tidak seperti yang diharapkan. Apa penyebab umum grommicking pada motherboard Athlon MP? Apakah ada yang punya ide untuk pengujian tambahan yang dapat saya lakukan untuk menemukan masalahnya?
Orang ini, di sisi lain, tampak pantas mendapatkan jawaban. Dia telah menunjukkan kecerdasan dalam memecahkan masalah daripada menunggu secara pasif jawaban turun dari langit.
Pada pertanyaan terakhir, perhatikan perbedaan halus tetapi penting antara menuntut "Beri saya jawaban" dan "Tolong bantu saya mencari tahu diagnostik tambahan apa yang dapat saya jalankan untuk mencapai pencerahan."
Sebenarnya, bentuk pertanyaan terakhir tersebut didasarkan secara langsung pada kejadian nyata yang terjadi pada Agustus 2001 di milis linux-kernel (lkml). Saya (Eric) adalah orang yang mengajukan pertanyaan pada saat itu. Saya mengalami kelumpuhan misterius pada motherboard Tyan S2462. Anggota milis memberikan informasi penting yang saya butuhkan untuk memecahkannya.
Dengan mengajukan pertanyaan dengan cara yang saya lakukan, saya memberikan orang-orang sesuatu untuk dipikirkan; saya membuatnya mudah dan menarik bagi mereka untuk terlibat. Saya menunjukkan rasa hormat terhadap kemampuan rekan-rekan saya dan mengundang mereka untuk berkonsultasi dengan saya sebagai rekan. Saya juga menunjukkan rasa hormat terhadap nilai waktu mereka dengan memberi tahu mereka jalan buntu yang sudah saya jelajahi.
Setelah itu, ketika saya berterima kasih kepada semua orang dan mengomentari seberapa baik proses tersebut berjalan, seorang anggota lkml mengamati bahwa menurutnya hal itu berhasil bukan karena saya adalah "nama" di milis tersebut, tetapi karena saya mengajukan pertanyaan dalam bentuk yang tepat.
Hacker dalam beberapa hal adalah meritokrasi yang sangat tanpa ampun; saya yakin dia benar, dan bahwa jika saya berperilaku seperti spons, saya akan dimusnahkan atau diabaikan tidak peduli siapa pun saya. Sarannya agar saya menuliskan seluruh kejadian tersebut sebagai petunjuk untuk orang lain langsung mengarah pada penulisan panduan ini.
Jika Anda Tidak Mendapatkan Jawaban
Jika Anda tidak mendapatkan jawaban, jangan menganggap pribadi bahwa kami merasa tidak bisa membantu Anda. Terkadang anggota dari grup yang ditanyai mungkin saja tidak tahu jawabannya. Tidak mendapatkan tanggapan bukan berarti diabaikan, meskipun memang sulit untuk membedakan perbedaannya dari luar.
Secara umum, mengirim ulang pertanyaan Anda adalah ide yang buruk. Ini akan dianggap sebagai tindakan yang menyebalkan secara tidak perlu. Bersabarlah: orang yang memiliki jawaban untuk Anda mungkin berada di zona waktu yang berbeda dan sedang tidur. Atau mungkin pertanyaan Anda tidak terbentuk dengan baik sejak awal.
Ada sumber bantuan lain yang dapat Anda tuju, seringkali lebih cocok untuk kebutuhan seorang pemula.
Terdapat banyak kelompok pengguna online dan lokal yang antusias tentang perangkat lunak, meskipun mereka mungkin tidak pernah menulis perangkat lunak sendiri. Kelompok-kelompok ini sering terbentuk agar orang-orang dapat saling membantu dan membantu pengguna baru.
Terdapat juga banyak perusahaan komersial yang dapat Anda kontrak untuk mendapatkan bantuan, baik perusahaan besar maupun kecil. Jangan terkejut dengan ide harus membayar sedikit untuk mendapatkan bantuan! Bagaimanapun juga, jika mesin mobil Anda bocor pakai, kemungkinan besar Anda akan membawanya ke bengkel dan membayar untuk memperbaikinya. Meskipun perangkat lunak tidak menghabiskan uang Anda, Anda tidak bisa mengharapkan dukungan selalu datang secara gratis.
Untuk perangkat lunak populer seperti Linux, terdapat setidaknya 10.000 pengguna per pengembang. Tidak mungkin bagi satu orang untuk menangani panggilan dukungan dari lebih dari 10.000 pengguna. Ingatlah bahwa meskipun Anda harus membayar untuk dukungan, Anda tetap membayar jauh lebih sedikit daripada jika Anda harus membeli perangkat lunak tersebut (dan dukungan untuk perangkat lunak berkode tertutup biasanya lebih mahal dan kurang kompeten dibandingkan dukungan untuk perangkat lunak sumber terbuka).
Cara Menjawab Pertanyaan dengan Cara yang Membantu
Berlaku dengan lembut. Stres yang terkait dengan masalah dapat membuat orang terlihat kasar atau bodoh bahkan ketika sebenarnya tidak demikian.
Balas kepada pelanggar pertama secara pribadi. Tidak perlu ada penghinaan publik bagi seseorang yang mungkin telah membuat kesalahan yang jujur. Seorang pemula sejati mungkin tidak tahu cara mencari arsip atau di mana FAQ disimpan atau diposting.
Jika Anda tidak yakin, katakanlah! Jawaban yang keliru tetapi terdengar berwibawa lebih buruk daripada tidak ada jawaban sama sekali. Jangan mengarahkan seseorang ke arah yang salah hanya karena terdengar menyenangkan untuk terdengar seperti seorang ahli. Jadilah rendah hati dan jujur; berikan contoh yang baik bagi penanya dan rekan-rekan Anda.
Jika Anda tidak bisa membantu, jangan menghalangi. Jangan membuat lelucon tentang prosedur yang dapat merusak pengaturan pengguna — orang malang itu mungkin menganggap ini sebagai instruksi.
Ajukan pertanyaan mendalam untuk mendapatkan lebih banyak rincian. Jika Anda pandai dalam hal ini, penanya akan belajar sesuatu — dan mungkin Anda juga. Cobalah untuk mengubah pertanyaan yang buruk menjadi pertanyaan yang baik; ingatlah bahwa kita semua pernah menjadi pemula.
Meskipun menggerutu RTFM terkadang dibenarkan ketika menjawab seseorang yang hanya malas, memberikan petunjuk ke dokumentasi (bahkan jika hanya saran untuk mencari frasa kunci di Google) lebih baik.
Jika Anda akan menjawab pertanyaan, berikan nilai yang baik. Jangan menyarankan solusi yang tidak efisien ketika seseorang menggunakan alat atau pendekatan yang salah. Sarankan alat yang baik. Ubah ulang pertanyaan tersebut.
Jawablah pertanyaan yang sebenarnya! Jika penanya telah sangat teliti dalam melakukan penelitiannya dan telah menyertakan dalam pertanyaan bahwa X, Y, Z, A, B, dan C telah dicoba tanpa hasil yang baik, sangat tidak membantu untuk menanggapi dengan "Coba A atau B," atau dengan tautan ke sesuatu yang hanya mengatakan, "Coba X, Y, Z, A, B, atau C.".
Bantu komunitas Anda belajar dari pertanyaan tersebut. Ketika Anda menjawab pertanyaan yang baik, tanyakan pada diri sendiri, "Bagaimana dokumentasi atau FAQ yang relevan harus berubah agar tidak ada lagi yang perlu menjawab pertanyaan ini?" Kemudian kirimkan perbaikan ke pemelihara dokumen tersebut.
Jika Anda melakukan penelitian untuk menjawab pertanyaan tersebut, tunjukkan keterampilan Anda daripada menulis seolah-olah Anda mengeluarkan jawaban dari belakang Anda. Menjawab satu pertanyaan yang baik sama seperti memberi makan orang yang lapar satu kali, tetapi mengajarkan keterampilan penelitian kepada mereka dengan contoh adalah menunjukkan kepada mereka cara menumbuhkan makanan seumur hidup.
Sumber Daya Terkait
Jika Anda membutuhkan instruksi dasar tentang cara kerja komputer pribadi, Unix, dan Internet, lihat The Unix and Internet Fundamentals HOWTO.
Ketika Anda merilis perangkat lunak atau menulis patch untuk perangkat lunak, cobalah untuk mengikuti pedoman dalam Software Release Practice HOWTO.
Pengakuan
Evelyn Mitchell memberikan beberapa contoh pertanyaan bodoh dan menginspirasi bagian "Cara Memberikan Jawaban yang Baik". Mikhail Ramendik memberikan beberapa saran yang sangat berharga untuk perbaikan.
