Cara Ajukan Pertanyaan The Smart Way

Eric Steven Raymond

thirsos Usaha


    <[email protected]>
    

Rick Moen


    <[email protected]>
    

Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen

revisi Sejarah
revisi 3.10 21 Mei 2014 esr
bagian baru pada Stack Overflow.
revisi 3.9 23 Apr 2013 esr
perbaikan URL.
revisi 3.8 19 Jun 2012 esr
memperbaiki URL.
revisi 3.7 6 Desember 2010 esr
petunjuk bermanfaat untuk speaker ESL.
revisi 3.7 2 Nov 2010 esr
Beberapa terjemahan telah menghilang.
revisi 3.6 19 Mar 2008 esr
minor update dan link baru.
revisi 3.5 2 Jan 2008 esr
Ketik memperbaiki dan beberapa link terjemahan.
revisi 3.4 24 Mar 2007 esr
bagian baru, "Ketika bertanya tentang kode".
revisi 3.3 29 Sep 2006 esr
Dilipat dalam saran yang baik dari Kai Niggemann.
revisi 3.2 10 Jan 2006 esr
Dilipat suntingan dari Rick Moen.
revisi 3.1 28 Oktober 2004 esr
Dokumen 'Google adalah teman Anda!'
revisi 3.0 2 Feb 2004 esr
Selain besar hal tentang etiket yang tepat di forum Web.

Daftar Isi

terjemahan

Penolakan

pengantar

Sebelum Anda Tanyakan

Ketika Anda Tanyakan

Pilih forum Anda dengan hati-hati

Stack Overflow

forum web dan IRC

Sebagai langkah kedua, menggunakan proyek milis

Gunakan bermakna, header subjek tertentu

Memudahkan untuk membalas

Menulis dengan jelas, tata bahasa, bahasa benar-dieja

Kirim pertanyaan di diakses, format standar

Jadilah tepat dan informatif tentang masalah Anda

Volume tidak presisi

Jangan terburu-buru untuk mengklaim bahwa Anda telah menemukan bug

Grovelling bukanlah pengganti untuk melakukan pekerjaan rumah Anda

Menjelaskan gejala masalah ini, tidak tebakan Anda

Menjelaskan gejala masalah Anda secara kronologis

Jelaskan tujuan, tidak langkah

Jangan meminta orang untuk membalas dengan e-mail pribadi

Eksplisit tentang pertanyaan Anda

Ketika bertanya tentang kode

Jangan posting pertanyaan PR

Prune pertanyaan sia-sia

Jangan bendera pertanyaan Anda sebagai " Mendesak " , bahkan jika itu adalah untuk Anda

Courtesy tidak ada salahnya, dan kadang-kadang membantu

Menindaklanjuti dengan catatan singkat pada solusi

Bagaimana Menafsirkan Jawaban

RTFM dan STFW: Bagaimana Mengenalinya Anda sudah Serius Screwed Up

Jika Anda tidak mengerti ...

Berurusan dengan kekasaran

Pada Tidak Bereaksi Like A Loser

Pertanyaan Tidak Untuk Tanyakan

Baik dan Buruk Pertanyaan

Jika Anda tidak Bisa Dapatkan Sebuah Jawaban

Cara Jawaban di Jalan Bermanfaat

Sumber terkait

Ucapan Terima Kasih

Penolakan

Banyak situs proyek link ke dokumen ini di bagian mereka tentang cara untuk mendapatkan bantuan. Itu baik-baik saja, itu penggunaan kita dimaksudkan - tetapi jika Anda seorang webmaster menciptakan link tersebut untuk halaman proyek Anda, silakan menampilkan mencolok dekat link pemberitahuan bahwa kita tidak meja bantuan untuk proyek Anda!

Kami telah belajar dengan cara yang keras bahwa tanpa pemberitahuan seperti itu, kita akan berulang kali akan direcoki oleh idiot yang berpikir telah menerbitkan dokumen ini membuat tugas kita untuk menyelesaikan semua masalah teknis di dunia.

Jika Anda membaca dokumen ini karena Anda membutuhkan bantuan, dan Anda pergi dengan kesan Anda bisa mendapatkannya langsung dari para penulis dokumen ini, Anda adalah salah satu idiot kita bicarakan. Jangan tanya kami pertanyaan. Kami hanya akan mengabaikan Anda. Kami di sini untuk menunjukkan kepada Anda bagaimana untuk mendapatkan bantuan dari orang-orang yang benar-benar tahu tentang software atau hardware yang anda hadapi, namun 99,9% dari waktu yang tidak akan kita. Kecuali anda tahu pasti bahwa salah satu penulis adalah seorang ahli pada apa yang Anda hadapi, meninggalkan kita, semua orang akan lebih bahagia.

pengantar

Dalam dunia hacker , jenis jawaban yang Anda dapatkan untuk pertanyaan teknis Anda tergantung sebanyak pada cara Anda mengajukan pertanyaan seperti pada sulitnya mengembangkan jawabannya.Panduan ini akan mengajarkan Anda bagaimana mengajukan pertanyaan dengan cara yang lebih mungkin untuk mendapatkan jawaban yang memuaskan.

Sekarang bahwa penggunaan open source telah menyebar luas, Anda dapat sering mendapatkan jawaban yang baik dari lainnya, pengguna yang lebih berpengalaman sebagai dari hacker. Ini adalah Good Thing; pengguna cenderung hanya sedikit lebih toleran terhadap jenis kegagalan pemula sering. Namun, memperlakukan pengguna berpengalaman seperti hacker dengan cara kami sarankan di sini akan umumnya menjadi cara yang paling efektif untuk mendapatkan jawaban yang berguna dari mereka, juga.

Hal pertama yang harus dipahami adalah bahwa hacker benar-benar seperti masalah keras dan baik, pertanyaan pemikiran tentang mereka. Jika kita tidak, kita tidak akan berada di sini. Jika Anda memberi kami pertanyaan yang menarik untuk mengunyah kami akan berterima kasih kepada Anda; pertanyaan yang baik adalah stimulus dan hadiah. Pertanyaan yang baik membantu kita mengembangkan pemahaman kita, dan sering mengungkapkan masalah kita mungkin tidak menyadari atau memikirkan sebaliknya. Di antara hacker, " Pertanyaan yang bagus! " Adalah pujian yang kuat dan tulus.

Meskipun demikian, hacker memiliki reputasi untuk memenuhi pertanyaan sederhana dengan apa yang tampak seperti permusuhan atau kesombongan. Kadang-kadang tampak seperti kami refleks kasar untuk pemula dan bodoh. Tapi ini tidak benar.

Apa yang kita, unapologetically, memusuhi orang-orang yang tampaknya tidak mau berpikir atau melakukan pekerjaan rumah mereka sendiri sebelum mengajukan pertanyaan. Orang-orang seperti yang waktu tenggelam - mereka mengambil tanpa memberikan kembali, dan mereka membuang-buang waktu kita bisa menghabiskan pada pertanyaan lain yang lebih menarik dan orang lain yang lebih layak jawaban. Kami memanggil orang-orang seperti ini " pecundang " (dan untuk alasan historis kadang-kadang kita mengejanya " lusers " ).

Kami menyadari bahwa ada banyak orang yang hanya ingin menggunakan software yang kita tulis, dan yang tidak tertarik dalam mempelajari rincian teknis. Bagi kebanyakan orang, komputer hanyalah alat, sebuah sarana untuk mencapai tujuan; mereka memiliki hal-hal yang lebih penting untuk dilakukan dan hidup untuk hidup. Kami mengakui bahwa, dan tidak mengharapkan semua orang untuk mengambil minat pada hal-hal teknis yang mempesona kami. Namun demikian, gaya kami pertanyaan menjawab disetel untuk orang-orang yang melakukan mengambil bunga tersebut dan bersedia menjadi peserta aktif dalam pemecahan masalah. Itu tidak akan berubah. Atau harus itu; jika itu terjadi, kita akan menjadi kurang efektif dalam hal yang kita lakukan yang terbaik.

Kami (sebagian besar) relawan. Kami mengambil waktu keluar dari kehidupan sibuk untuk menjawab pertanyaan, dan kadang-kadang kami kewalahan dengan mereka. Jadi kita menyaring kejam. Secara khusus, kita membuang pertanyaan dari orang-orang yang muncul untuk menjadi pecundang dalam rangka untuk menghabiskan waktu pertanyaan-menjawab kami lebih efisien, pada pemenang.

Jika Anda menemukan sikap ini menjengkelkan, merendahkan, atau sombong, periksa asumsi Anda. Kami tidak meminta Anda untuk berlutut kepada kami - pada kenyataannya, kebanyakan dari kita akan senang tidak lebih dari untuk berurusan dengan Anda sebagai sama dan menyambut Anda ke dalam budaya kita, jika Anda dimasukkan ke dalam upaya yang diperlukan untuk membuat itu mungkin. Tapi itu hanya tidak efisien bagi kami untuk mencoba untuk membantu orang-orang yang tidak mau membantu diri mereka sendiri. Ini OK untuk menjadi bodoh; itu tidak OK untuk bermain bodoh.

Jadi, sementara itu tidak perlu sudah secara teknis kompeten untuk mendapatkan perhatian dari kami, itu adalah diperlukan untuk menunjukkan jenis sikap yang mengarah ke kompetensi - waspada, bijaksana, jeli, bersedia menjadi mitra aktif dalam mengembangkan solusi. Jika Anda tidak bisa hidup dengan semacam ini diskriminasi, kami sarankan Anda membayar seseorang untuk kontrak dukungan komersial bukannya meminta hacker untuk pribadi menyumbangkan bantuan kepada Anda.

Jika Anda memutuskan untuk datang kepada kami untuk membantu, Anda tidak ingin menjadi salah satu yang merugi. Anda tidak ingin tampak seperti satu, baik. Cara terbaik untuk mendapatkan jawaban yang cepat dan responsif adalah untuk meminta itu seperti orang dengan kecerdasan, percaya diri, dan petunjuk yang kebetulan membutuhkan bantuan pada satu masalah tertentu.

(Perbaikan panduan ini dipersilakan. Anda bisa mengirimkan saran untuk [email protected] atau [email protected] . Namun perlu dicatat bahwa dokumen ini tidak dimaksudkan untuk menjadi panduan umum untuk netiket , dan kita umumnya akan menolak saran bahwa tidak secara khusus terkait dengan memunculkan jawaban berguna dalam forum teknis.)

Sebelum Anda Tanyakan

Sebelum mengajukan pertanyaan teknis melalui e-mail, atau dalam newsgroup, atau pada papan situs chatting, lakukan hal berikut:

  1. Cobalah untuk menemukan jawaban dengan mencari arsip dari forum atau milis Anda berencana untuk mengirim ke.

  2. Cobalah untuk menemukan jawaban dengan mencari Web.

  3. Cobalah untuk menemukan jawaban dengan membaca manual.

  4. Cobalah untuk menemukan jawaban dengan membaca FAQ.

  5. Cobalah untuk menemukan jawaban dengan inspeksi atau eksperimen.

  6. Cobalah untuk menemukan jawaban dengan meminta seorang teman yang terampil.

  7. Jika Anda seorang programmer, mencoba untuk menemukan jawaban dengan membaca kode sumber.

Ketika Anda mengajukan pertanyaan Anda, menampilkan fakta bahwa Anda telah melakukan hal-hal ini yang pertama; ini akan membantu menetapkan bahwa Anda tidak menjadi spons malas dan membuang-buang waktu orang. Lebih baik lagi, menampilkan apa yang telah Anda pelajari dari melakukan hal-hal. Kami suka menjawab pertanyaan untuk orang-orang yang telah menunjukkan mereka bisa belajar dari jawaban.

Menggunakan taktik seperti melakukan pencarian Google pada teks pesan kesalahan apa pun yang Anda dapatkan (mencari kelompok Google serta halaman Web). Hal ini mungkin membawa Anda langsung untuk memperbaiki dokumentasi atau thread milis menjawab pertanyaan Anda. Bahkan jika tidak, mengatakan " I googled pada frase berikutnya tetapi tidak mendapatkan apa-apa yang tampak menjanjikan "adalah hal yang baik untuk dilakukan di e-mail atau berita posting meminta bantuan, jika hanya karena mencatat apa mencari won ' t bantuan. Ini juga akan membantu untuk mengarahkan orang lain dengan masalah yang sama dengan thread Anda dengan menghubungkan istilah pencarian dengan apa yang diharapkan akan menjadi masalah Anda dan benang resolusi.

Pelan-pelan saja. Jangan berharap untuk dapat memecahkan masalah rumit dengan beberapa detik dari Googling. Membaca dan memahami FAQ, duduk kembali, bersantai dan memberikan masalah beberapa pemikiran sebelum mendekati ahli. Percayalah, mereka akan dapat menjelaskan dari pertanyaan Anda berapa banyak membaca dan berpikir Anda lakukan, dan akan lebih bersedia untuk membantu jika Anda datang siap. Jangan langsung memecat seluruh gudang senjata Anda dari pertanyaan hanya karena pencarian pertama Anda muncul tidak ada jawaban (atau terlalu banyak).

Siapkan pertanyaan Anda. Berpikir melalui. pertanyaan Hasty-terdengar mendapatkan jawaban yang terburu-buru, atau tidak sama sekali. Semakin Anda lakukan untuk menunjukkan bahwa setelah meletakkan pemikiran dan usaha ke pemecahan masalah Anda sebelum mencari bantuan, semakin besar kemungkinan Anda untuk benar-benar mendapatkan bantuan.

Hati-hati mengajukan pertanyaan yang salah. Jika Anda bertanya salah satu yang didasarkan pada asumsi yang salah, J. Hacker Acak sangat mungkin untuk membalas dengan jawaban yang sia-sia literal sambil berpikir " pertanyaan bodoh ... " , dan berharap pengalaman mendapatkan apa yang Anda minta daripada apa yang Anda butuhkan akan memberimu pelajaran.

Tidak pernah menganggap Anda berhak untuk jawaban. Kamu tidak; Anda tidak, setelah semua, membayar untuk layanan ini. Anda akan mendapatkan jawaban, jika Anda mendapatkan itu, dengan meminta substansial, menarik, dan pemikiran pertanyaan - yang secara implisit memberikan kontribusi untuk pengalaman masyarakat bukan hanya pasif menuntut ilmu dari orang lain.

Di sisi lain, sehingga jelas bahwa Anda mampu dan bersedia untuk membantu dalam proses pengembangan solusinya adalah awal yang sangat baik. " Apakah seseorang memberikan pointer? " , " Apa contoh saya hilang? " , Dan " Apa situs yang harus saya telah memeriksa? " lebih mungkin untuk mendapatkan menjawab dari " Silahkan posting prosedur yang tepat saya harus menggunakan. " karena Anda membuat jelas bahwa Anda benar-benar bersedia untuk menyelesaikan proses jika seseorang hanya dapat menunjukkan Anda arah yang benar.

Ketika Anda Tanyakan

Pilih forum Anda dengan hati-hati

Peka dalam memilih mana Anda mengajukan pertanyaan Anda. Anda mungkin diabaikan, atau dihapuskan sebagai pecundang, jika Anda:

  • posting pertanyaan Anda ke forum di mana itu off topic

  • memposting pertanyaan yang sangat dasar untuk sebuah forum di mana pertanyaan teknis lanjutan diharapkan, atau sebaliknya

  • cross-posting terlalu banyak newsgroup yang berbeda

  • memasukkan e-mail pribadi kepada seseorang yang bukan merupakan kenalan Anda atau pribadi bertanggung jawab untuk memecahkan masalah Anda

Hacker meledak pertanyaan yang tidak tepat sasaran dalam rangka untuk mencoba untuk melindungi saluran komunikasi mereka dari yang tenggelam di tidak relevan. Anda tidak ingin hal ini terjadi pada Anda.

Langkah pertama, oleh karena itu, adalah untuk menemukan forum yang tepat. Sekali lagi, Google dan metode Web-cari lain adalah teman Anda. Menggunakannya untuk menemukan halaman web proyek yang paling dekat hubungannya dengan perangkat keras atau perangkat lunak memberikan Anda kesulitan. Biasanya akan memiliki link ke FAQ (Frequently Asked Questions) daftar, dan untuk proyek milis dan arsip mereka. Milis ini adalah tempat terakhir untuk pergi untuk bantuan, jika usaha Anda sendiri (termasuk membaca mereka FAQ Anda menemukan) tidak menemukan Anda solusi. Halaman proyek juga menjelaskan prosedur bug-pelaporan, atau memiliki link ke satu; jika demikian, mengikutinya.

Shooting off e-mail ke seseorang atau forum yang Anda tidak akrab dengan berisiko di terbaik. Misalnya, jangan menganggap bahwa penulis halaman web yang informatif ingin menjadi konsultan gratis.Jangan membuat tebakan optimis tentang apakah pertanyaan Anda akan diterima - jika Anda tidak yakin, kirimkan ke tempat lain, atau menahan diri dari mengirimnya sama sekali.

Ketika memilih sebuah forum web, newsgroup atau mailing list, tidak percaya nama dengan sendirinya terlalu jauh; mencari FAQ atau charter untuk memverifikasi pertanyaan Anda pada topik. Membaca beberapa lalu lintas kembali sebelum posting sehingga Anda akan mendapatkan merasakan bagaimana hal-hal yang dilakukan di sana. Bahkan, itu ide yang sangat baik untuk melakukan pencarian kata kunci untuk kata-kata yang berkaitan dengan masalah Anda pada newsgroup atau mailing list arsip sebelum Anda posting. Ini mungkin menemukan Anda jawaban, dan jika tidak itu akan membantu Anda merumuskan pertanyaan yang lebih baik.

Jangan senapan-ledakan semua saluran bantuan yang tersedia sekaligus, itu seperti berteriak dan mengganggu orang. Langkah melalui mereka lembut.

Tahu apa topik Anda! Salah satu kesalahan klasik mengajukan pertanyaan tentang antarmuka pemrograman Unix atau Windows dalam forum yang ditujukan untuk bahasa atau perpustakaan atau alat portabel di kedua. Jika Anda tidak mengerti mengapa hal ini kesalahan, Anda akan terbaik off tidak mengajukan pertanyaan sama sekali sampai Anda mendapatkannya.

Secara umum, pertanyaan untuk forum publik yang dipilih lebih mungkin untuk mendapatkan jawaban berguna daripada pertanyaan setara dengan satu pribadi. Ada beberapa alasan untuk ini. Salah satunya adalah hanya ukuran kolam responden potensial. Lain adalah ukuran penonton; hacker lebih suka menjawab pertanyaan yang mendidik banyak orang dari pertanyaan yang melayani hanya beberapa.

Maklum, hacker terampil dan penulis software populer sudah menerima lebih dari mereka yang adil dari pesan yang salah sasaran. Dengan menambahkan untuk banjir, Anda bisa dalam kasus ekstrim bahkan menjadi jerami yang mematahkan punggung unta - beberapa kali, kontributor untuk proyek-proyek populer telah menarik dukungan mereka karena kerusakan jaminan dalam bentuk lalu lintas e-mail yang tidak berguna ke rekening pribadi mereka menjadi tak tertahankan.

Stack Overflow

Cari, kemudian meminta pada Stack Bursa

Dalam beberapa tahun terakhir, masyarakat Stack Pertukaran situs telah muncul sebagai sumber daya utama untuk menjawab pertanyaan teknis dan lainnya dan bahkan disukai forum untuk banyak proyek open-source.

Mulailah dengan pencarian Google sebelum melihat Stack Efek; indeks Google secara real time. Ada kesempatan seseorang yang sangat baik memiliki sudah bertanya pertanyaan serupa, dan situs Stack Exchange sering di dekat bagian atas hasil pencarian. Jika Anda tidak menemukan apa-apa melalui Google, mencari lagi di situs tertentu yang paling relevan dengan pertanyaan Anda (lihat di bawah).Mencari dengan tag dapat membantu mempersempit hasil.

Jika Anda masih tidak menemukan apa-apa, posting pertanyaan Anda pada salah satu situs di mana itu yang paling on-topik. Gunakan alat format, terutama untuk kode, dan menambahkan tag yang terkait dengan substansi pertanyaan Anda (terutama nama bahasa pemrograman, sistem operasi, atau perpustakaan Anda mengalami masalah dengan). Jika commenter meminta Anda untuk informasi lebih lanjut, mengedit posting utama Anda untuk memasukkannya. Jika ada jawaban membantu, klik tanda panah untuk upvote itu; jika jawaban memberikan solusi untuk masalah Anda, klik centang di bawah panah voting untuk menerimanya sebagai benar.

Stack Bursa telah berkembang lebih dari 100 situs , tapi di sini adalah kandidat yang paling mungkin:

  • Super User adalah untuk pertanyaan tentang komputasi tujuan umum. Jika pertanyaan Anda bukan tentang kode atau program yang Anda berbicara dengan hanya melalui koneksi jaringan, mungkin diletakkan di sini.

  • Stack Overflow adalah untuk pertanyaan tentang pemrograman.

  • Server Fault adalah untuk pertanyaan tentang server dan administrasi jaringan.

Beberapa proyek memiliki situs mereka sendiri yang spesifik, termasuk Android, Ubuntu, TeX / LaTeX, dan SharePoint. Periksa situs Stack Exchange untuk daftar up-to-date.

forum web dan IRC

kelompok Anda lokal pengguna, atau distribusi Linux Anda, dapat mengiklankan sebuah forum web atau saluran IRC di mana pemula bisa mendapatkan bantuan. (Di negara-negara non-berbahasa Inggris forum pemula masih lebih mungkin mailing list.) Ini baik tempat pertama untuk bertanya, terutama jika Anda pikir Anda mungkin telah tersandung masalah yang relatif sederhana atau umum. Saluran IRC diiklankan adalah undangan terbuka untuk mengajukan pertanyaan di sana dan sering mendapatkan jawaban secara real time.

Bahkan, jika Anda punya program yang memberikan Anda masalah dari distribusi Linux (seperti yang umum hari ini), mungkin lebih baik untuk bertanya di distro forum / daftar sebelum mencoba program forum proyek / daftar. Hacker proyek mungkin hanya mengatakan, " menggunakan kami membangun " .

Sebelum posting ke forum Web, memeriksa apakah ia memiliki fitur Search. Jika tidak, cobalah beberapa kata kunci pencarian untuk sesuatu seperti masalah Anda; itu hanya mungkin membantu. Jika Anda melakukan pencarian Web umum sebelum (seperti yang Anda harus memiliki), cari forum pula; mesin pencari Web-lebar Anda mungkin tidak memiliki semua forum ini diindeks baru-baru.

Ada kecenderungan yang meningkat untuk proyek-proyek untuk melakukan dukungan pengguna melalui forum Web atau saluran IRC, dengan e-mail milik lebih untuk lalu lintas pembangunan. Jadi mencari saluran-saluran pertama ketika mencari bantuan proyek-spesifik.

Di IRC, itu mungkin yang terbaik untuk tidak membuang deskripsi masalah panjang di hal pertama saluran; beberapa orang menafsirkan ini sebagai saluran-banjir. Terbaik untuk mengucapkan satu baris deskripsi masalah dengan cara bernada untuk memulai percakapan pada saluran.

Sebagai langkah kedua, menggunakan proyek milis

Ketika sebuah proyek memiliki perkembangan mailing list, menulis ke milis, tidak pengembang individu, bahkan jika Anda percaya bahwa Anda tahu siapa yang terbaik dapat menjawab pertanyaan Anda.Periksa dokumentasi proyek dan homepage untuk alamat proyek mailing list, dan menggunakannya. Ada beberapa alasan yang baik untuk kebijakan ini:

  • Setiap pertanyaan yang cukup baik untuk diminta dari satu pengembang juga akan menjadi nilai untuk seluruh kelompok. Sebaliknya, jika Anda menduga pertanyaan anda terlalu bodoh untuk mailing list, itu bukan alasan untuk melecehkan pengembang individu.

  • Mengajukan pertanyaan pada daftar mendistribusikan beban di antara para pengembang. Pengembang individu (terutama jika dia adalah pemimpin proyek) mungkin terlalu sibuk untuk menjawab pertanyaan Anda.

  • Kebanyakan milis diarsipkan dan arsip diindeks oleh mesin pencari. Jika Anda mengajukan pertanyaan Anda pada daftar dan dijawab, sebuah querent masa depan bisa menemukan pertanyaan Anda dan jawaban di Web bukannya meminta lagi.

  • Jika pertanyaan-pertanyaan tertentu terlihat untuk diminta sering, pengembang dapat menggunakan informasi tersebut untuk meningkatkan dokumentasi atau perangkat lunak itu sendiri menjadi kurang membingungkan. Tetapi jika pertanyaan-pertanyaan diminta secara pribadi, tidak ada yang memiliki gambaran lengkap dari apa pertanyaan yang paling sering ditanyakan.

Jika proyek memiliki baik " pengguna " dan " pengembang " (atau " hacker " ) mailing list atau Web forum, dan Anda tidak hacking pada kode, minta di " pengguna " daftar / forum. Jangan berasumsi bahwa Anda akan diterima pada daftar pengembang, di mana mereka mungkin mengalami pertanyaan Anda sebagai kebisingan mengganggu lalu lintas pengembang mereka.

Namun, jika Anda yakin pertanyaan Anda adalah non-sepele, dan Anda mendapatkan tidak ada jawaban dalam " pengguna " daftar / forum selama beberapa hari, mencoba " pengembang " satu. Anda akan disarankan untuk mengintai di sana selama beberapa daysor setidaknya meninjau beberapa hari terakhir pesan yang diarsipkan, untuk mempelajari folkways lokal sebelum posting (sebenarnya ini adalah nasihat yang baik pada setiap daftar swasta atau semi-swasta).

Jika Anda tidak dapat menemukan alamat milis proyek, tetapi hanya melihat alamat dari pengelola proyek, pergi ke depan dan menulis ke pengelola. Tetapi bahkan dalam kasus itu, jangan menganggap bahwa milis tidak ada. Menyebutkan dalam e-mail yang Anda mencoba dan tidak bisa menemukan milis yang sesuai. Juga menyebutkan bahwa Anda tidak keberatan untuk memiliki pesan Anda diteruskan ke orang lain. (Banyak orang percaya bahwa e-mail pribadi harus tetap pribadi, bahkan jika tidak ada rahasia di dalamnya. Dengan membiarkan pesan Anda untuk diteruskan Anda memberikan koresponden Anda pilihan tentang bagaimana menangani e-mail Anda.)

Gunakan bermakna, header subjek tertentu

Pada milis, newsgroups atau forum Web, header subjek adalah kesempatan emas Anda untuk menarik perhatian ahli yang berkualitas 'di sekitar 50 karakter atau kurang. Jangan sia-siakan pada celoteh seperti" Tolong bantu saya " (apalagi " PLEASE HELP ME !!!! " ; pesan dengan mata pelajaran seperti yang bisa dibuang oleh reflex). Jangan mencoba untuk mengesankan kami dengan kedalaman penderitaan Anda; menggunakan ruang untuk penjelasan masalah super ringkas gantinya.

Satu konvensi baik untuk header subjek, yang digunakan oleh banyak organisasi dukungan teknis, adalah " objek - penyimpangan " . The " objek " bagian menentukan apa hal atau kelompok hal adalah memiliki masalah, dan " penyimpangan " bagian menggambarkan penyimpangan dari perilaku yang diharapkan.

Bodoh:

MEMBANTU! Video tidak bekerja dengan benar di laptop saya!

Pintar:

X.org 6.8.1 kursor mouse cacat, Fooware MV1005 vid. chipset

Smarter:

X.org 6.8.1 kursor mouse pada Fooware MV1005 vid. chipset - adalah cacat

Proses menulis " objek-penyimpangan " description akan membantu Anda mengatur pemikiran Anda tentang masalah yang lebih detail. Apa yang terpengaruh? Hanya kursor mouse atau grafis lain juga?Apakah ini khusus untuk versi X.org X? Untuk versi 6.8.1? Apakah ini khusus untuk Fooware video chipset? Untuk model MV1005? Seorang hacker yang melihat hasil dapat segera memahami apa yang Anda mengalami masalah dengan dan masalah yang kita alami, sekilas.

Lebih umum, bayangkan melihat indeks arsip pertanyaan, hanya dengan baris subjek menunjukkan. Membuat baris subjek Anda mencerminkan pertanyaan Anda cukup baik bahwa orang berikutnya mencari arsip dengan pertanyaan serupa dengan Anda akan dapat mengikuti thread untuk jawaban daripada posting pertanyaan lagi.

Jika Anda mengajukan pertanyaan pada balasan, pastikan untuk mengubah baris subjek untuk menunjukkan bahwa Anda mengajukan pertanyaan. Sebuah garis Subjek yang terlihat seperti " Re: test " atau "Re: bug baru " cenderung kurang menarik jumlah berguna perhatian. Juga, pare kutipan pesan sebelumnya ke konsisten minimum dengan cluing pembaca baru.

Jangan hanya memukul membalas pesan daftar untuk memulai thread yang sama sekali baru. Hal ini akan membatasi audiens Anda. Beberapa pembaca mail, seperti mutt, memungkinkan pengguna untuk mengurutkan berdasarkan benang dan kemudian menyembunyikan pesan di thread dengan melipat benang. Orang-orang yang melakukan itu tidak akan pernah melihat pesan Anda.

Mengubah subjek tidak cukup. Mutt, dan pembaca email mungkin lainnya, melihat informasi lainnya di header e-mail untuk menetapkan ke thread, bukan baris subjek. Sebaliknya memulai e-mail yang sama sekali baru.

Pada forum Web aturan praktek yang baik yang sedikit berbeda, karena pesan biasanya jauh lebih erat terikat benang diskusi yang spesifik dan sering terlihat di luar topik tersebut. Mengubah topik pembicaraan ketika mengajukan pertanyaan pada balasan tidak penting. Tidak semua forum bahkan memungkinkan baris subjek terpisah pada balasan, dan hampir tidak ada yang membaca mereka ketika mereka lakukan. Namun, mengajukan pertanyaan pada balasan adalah praktek meragukan dalam dirinya sendiri, karena hanya akan dilihat oleh orang-orang yang menonton thread ini. Jadi, kecuali Anda yakin Anda ingin meminta hanya orang-orang yang sedang aktif di thread ini, memulai yang baru.

Memudahkan untuk membalas

Finishing permintaan Anda dengan " Silakan kirim balasan Anda ke ... " membuatnya sangat tidak mungkin Anda akan mendapatkan jawaban. Jika Anda tidak dapat diganggu untuk mengambil bahkan beberapa detik yang dibutuhkan untuk mendirikan benar Reply-To pada agen mail Anda, kami tidak dapat diganggu untuk mengambil bahkan beberapa detik untuk berpikir tentang masalah Anda. Jika program email Anda tidak mengizinkan ini, mendapatkan program email yang lebih baik . Jika sistem operasi Anda tidak mendukung program e-mail yang memungkinkan ini, mendapatkan sistem operasi yang lebih baik.

Dalam forum Web, meminta balasan melalui e-mail adalah terang-terangan kasar, kecuali Anda yakin informasi yang mungkin sensitif (dan seseorang akan, untuk beberapa alasan yang tidak diketahui, membiarkan Anda tetapi tidak seluruh forum tahu itu). Jika Anda ingin salinan e-mail ketika seseorang balasan di thread, meminta forum Web mengirimkannya; Fitur ini didukung hampir di mana-mana di bawah pilihan seperti " menonton thread ini " , " mengirim e-mail pada jawaban " , dll

Menulis dengan jelas, tata bahasa, bahasa benar-dieja

Kami telah menemukan pengalaman bahwa orang-orang yang penulis ceroboh biasanya juga ceroboh di berpikir dan coding (cukup sering untuk bertaruh pada, anyway). Menjawab pertanyaan untuk pemikir ceroboh tidak menguntungkan; kita lebih suka menghabiskan waktu kita di tempat lain.

Jadi mengekspresikan pertanyaan Anda dengan jelas dan baik adalah penting. Jika Anda tidak dapat diganggu untuk melakukan itu, kita tidak dapat diganggu untuk memperhatikan. Menghabiskan usaha ekstra untuk memoles bahasa Anda. Tidak harus kaku atau formal - pada kenyataannya, budaya hacker nilai bahasa resmi, bahasa slang dan lucu digunakan dengan presisi. Tapi itu harus menjadi tepat; harus ada beberapa indikasi bahwa Anda berpikir dan memperhatikan.

Mantra, tanda baca, dan memanfaatkan dengan benar. Jangan bingung " nya " dengan " itu " , " longgar " dengan " kehilangan " , atau " diskrit " dengan " bijaksana " . Jangan TYPE DI SEMUA CAPS; ini dibaca sebagai berteriak dan dianggap kasar. (All-smalls hanya sedikit kurang mengganggu, karena sulit untuk membaca. Alan Cox bisa lolos dengan itu, tapi Anda tidak bisa.)

Lebih umum, jika Anda menulis seperti payudara semi-melek Anda akan sangat mungkin diabaikan. Jadi jangan menggunakan cara pintas instant-messaging. Ejaan "Anda" sebagai "u" membuat Anda terlihat seperti payudara semi-melek untuk menyelamatkan dua seluruh keystrokes. Lebih buruk lagi: menulis seperti script kiddie hax0r l33t adalah ciuman kematian mutlak dan menjamin Anda akan menerima apa-apa selain diam membatu (atau, di terbaik, penumpukan membantu cemoohan dan sarkasme) imbalan.

Jika Anda mengajukan pertanyaan di forum yang tidak menggunakan bahasa asli Anda, Anda akan mendapatkan jumlah terbatas slack untuk ejaan dan tata bahasa kesalahan - tetapi tidak kendur tambahan sama sekali untuk kemalasan (dan ya, kita biasanya bisa melihat perbedaan itu). Juga, kecuali anda tahu apa bahasa responden Anda adalah, menulis dalam bahasa Inggris. hacker sibuk cenderung pertanyaan hanya siram dalam bahasa mereka tidak mengerti, dan bahasa Inggris adalah bahasa kerja Internet. Dengan menulis dalam bahasa Inggris Anda meminimalkan kemungkinan Anda bahwa pertanyaan Anda akan dibuang belum dibaca.

Jika Anda menulis dalam bahasa Inggris tetapi merupakan bahasa kedua bagi Anda, itu adalah bentuk yang baik untuk mengingatkan responden berpotensi kesulitan bahasa potensi dan pilihan untuk mendapatkan sekitar mereka. contoh:

  • Bahasa Inggris bukan bahasa ibu saya; mohon maaf kesalahan mengetik.

  • Jika Anda berbicara $ BAHASA, silahkan email / PM saya; Aku mungkin membutuhkan bantuan menerjemahkan pertanyaan saya.

  • Saya kenal dengan istilah-istilah teknis, tetapi beberapa ekspresi gaul dan idiom yang sulit bagi saya.

  • Saya kirimkan pertanyaan saya di $ BAHASA dan Inggris. Aku akan senang untuk menerjemahkan tanggapan, jika Anda hanya menggunakan satu atau yang lain.

Kirim pertanyaan di diakses, format standar

Jika Anda membuat pertanyaan Anda artifisial sulit dibaca, itu lebih mungkin untuk melewati mendukung dari salah satu yang tidak. Begitu:

  • Kirim surat teks biasa, tidak HTML. (Ini tidak sulit untuk mematikan HTML .)

  • MIME lampiran biasanya OK, tetapi hanya jika mereka puas nyata (seperti file sumber terpasang atau patch yang), dan bukan hanya boilerplate dihasilkan oleh klien email Anda (misalnya salinan lain dari pesan Anda).

  • Jangan mengirim e-mail di mana seluruh paragraf tunggal garis multiply-dibungkus. (Hal ini membuat terlalu sulit untuk membalas hanya bagian dari pesan.) Asumsikan bahwa responden Anda akan membaca mail pada display teks 80-karakter-lebar dan mengatur wrap baris yang sesuai, untuk sesuatu yang kurang dari 80.

  • Namun, jangan tidak membungkus data (seperti file log kesedihan atau transkrip sesi) pada setiap lebar kolom tetap. Data harus dimasukkan sebagai-adalah, sehingga responden dapat memiliki keyakinan bahwa mereka melihat apa yang Anda lihat.

  • Jangan mengirim MIME encoding Dikutip-cetak ke forum berbahasa Inggris. pengkodean dapat diperlukan ketika Anda posting dalam ASCII bahasa tidak mencakup, tetapi banyak agen e-mail tidak mendukung hal itu. Ketika mereka melanggar, semua = 20 glyphs tersebar melalui teks yang jelek dan mengganggu - atau mungkin aktif menyabotase semantik teks Anda.

  • Tidak pernah, pernah berharap hacker untuk dapat membaca tertutup format dokumen proprietary seperti Microsoft Word atau Excel. Kebanyakan hacker bereaksi terhadap ini tentang serta Anda akan untuk memiliki tumpukan mengepul kotoran babi dibuang di depan pintu Anda. Bahkan ketika mereka bisa mengatasi, mereka benci harus melakukannya.

  • Jika Anda mengirim e-mail dari mesin Windows, matikan bermasalah Microsoft " Quotes Cerdas " fitur (Dari Peralatan> AutoCorrect Options, menghapus tanda kutip centang pintar bawah AutoFormat As You Type.). Hal ini agar Anda akan menghindari percikan karakter sampah melalui email Anda.

  • Dalam forum Web, jangan menyalahgunakan " tersenyum " dan " HTML " fitur (ketika mereka hadir). Satu atau dua tersenyum biasanya OK, tapi berwarna teks mewah cenderung membuat orang berpikir Anda lumpuh. Serius berlebihan menggunakan smiley dan warna dan font akan membuat Anda datang dari seperti gadis cekikikan remaja, yang tidak biasanya ide yang baik kecuali jika Anda lebih tertarik pada seks daripada jawaban.

Jika Anda menggunakan mail client grafis-user-interface seperti Netscape Messenger, MS Outlook, atau sejenisnya, berhati-hatilah bahwa itu mungkin melanggar aturan ini bila digunakan dengan pengaturan default. Kebanyakan klien seperti memiliki menu berbasis " View Source " perintah. Gunakan ini pada sesuatu di folder sent-mail Anda, memverifikasi pengiriman teks biasa tanpa perlu mentah terpasang.

Jadilah tepat dan informatif tentang masalah Anda

  • Menjelaskan gejala masalah atau bug dengan hati-hati dan jelas.

  • Menggambarkan lingkungan di mana itu terjadi (mesin, OS, aplikasi, apa pun). Memberikan distribusi dan pelepasan tingkat vendor Anda (misalnya: " Fedora Core 7 " , " Slackware 9.1 " , dll).

  • Jelaskan penelitian yang Anda lakukan untuk mencoba dan memahami masalah sebelum Anda mengajukan pertanyaan.

  • Jelaskan langkah-langkah diagnostik yang Anda ambil untuk mencoba dan pin down masalah sendiri sebelum Anda mengajukan pertanyaan.

  • Jelaskan setiap perubahan terbaru yang mungkin relevan dalam komputer atau perangkat lunak konfigurasi Anda.

  • Jika memungkinkan, menyediakan cara untuk mereproduksi masalah dalam lingkungan yang terkendali .

Apakah yang terbaik yang Anda bisa untuk mengantisipasi pertanyaan seorang hacker akan bertanya, dan jawaban mereka di muka dalam permohonan bantuan Anda.

Memberikan hacker kemampuan untuk mereproduksi masalah dalam lingkungan yang terkendali terutama penting jika Anda melaporkan sesuatu yang Anda pikir adalah bug dalam kode. Ketika Anda melakukan ini, peluang Anda untuk mendapatkan jawaban yang berguna dan kecepatan yang Anda akan mendapatkan jawaban yang baik meningkatkan sangat.

Simon Tatham telah menulis sebuah esai yang sangat baik berjudul Cara Laporkan Bug Efektif . Saya sangat menyarankan Anda membacanya.

Volume tidak presisi

Anda harus tepat dan informatif. akhir ini tidak dilayani oleh hanya dumping volume besar kode atau data ke dalam permintaan bantuan. Jika Anda memiliki, kasus uji rumit besar yang melanggar program, cobalah untuk memangkas dan membuatnya sekecil mungkin.

Hal ini berguna untuk setidaknya tiga alasan. Satu: terlihat untuk berinvestasi upaya menyederhanakan pertanyaan membuatnya lebih mungkin Anda akan mendapatkan jawaban, Dua: menyederhanakan pertanyaan membuatnya lebih mungkin Anda akan mendapatkan yang berguna jawaban. Tiga: Dalam proses memperbaiki laporan bug Anda, Anda dapat mengembangkan memperbaiki atau atasi sendiri.

Jangan terburu-buru untuk mengklaim bahwa Anda telah menemukan bug

Ketika Anda mengalami masalah dengan software, tidak mengklaim Anda telah menemukan bug kecuali Anda sangat, sangat yakin tanah Anda. Petunjuk: kecuali Anda dapat memberikan patch source-code yang perbaikan masalah, atau uji regresi terhadap versi sebelumnya yang menunjukkan perilaku yang tidak benar, Anda mungkin tidak cukup yakin. Hal ini berlaku untuk halaman web dan dokumentasi, juga; jika Anda telah menemukan sebuah dokumentasi " bug " , Anda harus menyediakan pengganti teks dan laman mana yang harus pergi.

Ingat, ada banyak pengguna lain yang tidak mengalami masalah Anda. Jika tidak, Anda akan belajar tentang hal itu saat membaca dokumentasi dan mencari Web (kau melakukan itu sebelum mengeluh, kan?). Ini berarti bahwa sangat mungkin itu adalah Anda yang melakukan sesuatu yang salah, bukan perangkat lunak.

Orang-orang yang menulis perangkat lunak bekerja sangat keras untuk membuatnya bekerja sebaik mungkin. Jika Anda mengklaim Anda telah menemukan bug, Anda akan impugning kompetensi mereka, yang mungkin menyinggung beberapa dari mereka bahkan jika Anda benar. Ini terutama kurang bijaksana berteriak " bug " di baris subjek.

Ketika mengajukan pertanyaan Anda, yang terbaik adalah untuk menulis seolah-olah Anda menganggap Anda melakukan sesuatu yang salah, bahkan jika Anda secara pribadi cukup yakin Anda telah menemukan sebuah bug yang sebenarnya. Jika memang ada bug, Anda akan mendengar tentang hal itu dalam jawaban. Memainkannya sehingga pengelola akan ingin meminta maaf kepada Anda jika bug itu nyata, bukan sehingga Anda akan berutang kepada mereka permintaan maaf jika Anda telah kacau.

Grovelling bukanlah pengganti untuk melakukan pekerjaan rumah Anda

Beberapa orang yang mendapatkan bahwa mereka tidak harus bersikap kasar atau arogan, menuntut jawaban, mundur ke ekstrim yang berlawanan dari menyembah-nyembah. " Aku tahu aku hanya seorang pemula pecundang menyedihkan, tapi ... " . Ini mengganggu dan tidak membantu. Ini terutama menjengkelkan ketika itu ditambah dengan ketidakjelasan tentang masalah yang sebenarnya.

Jangan buang waktu Anda, atau kita, politik primata mentah. Sebaliknya, menyajikan fakta-fakta latar belakang dan pertanyaan Anda sejelas mungkin. Itu adalah cara yang lebih baik untuk memposisikan diri Anda daripada merendahkan diri.

Kadang-kadang forum Web memiliki tempat terpisah untuk pertanyaan pemula. Jika Anda merasa Anda memiliki pertanyaan newbie, hanya pergi ke sana. Tapi jangan merendahkan sana baik.

Menjelaskan gejala masalah ini, tidak tebakan Anda

Hal ini tidak berguna untuk mengatakan hacker apa yang Anda pikirkan yang menyebabkan masalah Anda. (Jika teori diagnostik Anda yang seperti barang panas, apakah Anda konsultasi orang lain untuk membantu?) Jadi, pastikan Anda memberitahu mereka gejala baku apa yang salah, bukan interpretasi dan teori. Biarkan mereka melakukan interpretasi dan diagnosis. Jika Anda merasa penting untuk menyatakan menebak Anda, jelas label seperti itu dan menjelaskan mengapa jawaban tidak bekerja untuk Anda.

Bodoh:

Saya mendapatkan back-to-back kesalahan SIG11 pada mengkompilasi kernel, dan mencurigai sebuah retakan di salah satu jejak motherboard. Apa cara terbaik untuk memeriksa mereka?

Pintar:

rumah yang dibangun saya K6 / 233 pada motherboard FIC-PA2007 (VIA Apollo VP2 chipset) dengan 256MB Corsair PC133 SDRAM mulai mendapatkan kesalahan sering SIG11 sekitar 20 menit setelah power-on selama kernel mengkompilasi, tetapi tidak pernah di 20 menit pertama . Reboot tidak restart jam, tapi powering down semalam tidak. Menukar semua RAM tidak membantu. Bagian yang relevan dari log sesi kompilasi khas berikut.

Karena titik sebelumnya tampaknya menjadi satu sulit bagi banyak orang untuk memahami, inilah ungkapan untuk mengingatkan Anda: "Semua diagnosticians berasal dari Missouri." motto resmi bahwa negara AS adalah "Tunjukkan" (yang diperoleh pada tahun 1899, ketika Kongres Willard D. Vandiver mengatakan "Saya datang dari sebuah negara yang menimbulkan jagung dan kapas dan cockleburs dan Demokrat, dan kefasihan berbusa tidak meyakinkan atau memenuhi saya. Saya dari Missouri. Anda harus menunjukkan. ") dalam hal diagnosticians ', itu bukan soal skeptisisme, melainkan literal, kebutuhan fungsional untuk melihat apa pun yang sedekat mungkin dengan bukti mentah yang sama yang Anda lihat, bukan dari dugaanku Anda dan ringkasan. Tunjukkan pada kami.

Menjelaskan gejala masalah Anda secara kronologis

Petunjuk yang paling berguna dalam mencari tahu sesuatu yang tidak beres sering berbohong dalam acara segera sebelum. Jadi, akun Anda harus menjelaskan dengan tepat apa yang Anda lakukan, dan apa mesin dan perangkat lunak lakukan, yang mengarah ke blowup tersebut. Dalam kasus proses command-line, memiliki log sesi (misalnya, menggunakan utilitas script) dan mengutip relevan dua puluh baris sangat berguna.

Jika program yang meledak pada Anda memiliki pilihan diagnostik (seperti -v untuk verbose), cobalah untuk memilih opsi yang akan menambahkan informasi debugging berguna untuk transkrip. Ingat bahwa lebih tidak selalu lebih baik; mencoba untuk memilih tingkat debug yang akan menginformasikan daripada tenggelam pembaca dalam junk.

Jika akun Anda akhirnya menjadi panjang (lebih dari sekitar empat paragraf), hal ini mungkin berguna untuk ringkas menyatakan masalah di bagian atas, kemudian ikuti dengan kisah kronologis. Dengan cara itu, hacker akan tahu apa yang harus diperhatikan dalam membaca akun Anda.

Jelaskan tujuan, tidak langkah

Jika Anda mencoba untuk mencari tahu bagaimana melakukan sesuatu (sebagai lawan melaporkan bug), mulai dengan menggambarkan tujuan. Hanya kemudian menggambarkan langkah tertentu ke arah itu yang Anda diblokir pada.

Seringkali, orang-orang yang memerlukan bantuan teknis memiliki tujuan tingkat tinggi dalam pikiran dan terjebak pada apa yang mereka pikir adalah salah satu jalan tertentu menuju tujuan. Mereka datang untuk membantu dengan langkah, tapi tidak menyadari bahwa jalan yang salah. Hal ini dapat mengambil upaya besar untuk melewati ini.

Bodoh:

Bagaimana cara mendapatkan warna-picker pada program FooDraw untuk mengambil nilai RGB heksadesimal?

Pintar:

Saya mencoba untuk mengganti tabel warna pada gambar dengan nilai pilihan saya. Sekarang satu-satunya cara aku bisa melihat untuk melakukan ini adalah dengan mengedit setiap slot meja, tapi aku tidak bisa mendapatkan warna picker FooDraw untuk mengambil nilai RGB heksadesimal.

Versi kedua dari pertanyaan cerdas. Hal ini memungkinkan jawaban yang menunjukkan alat lebih cocok untuk tugas itu.

Jangan meminta orang untuk membalas dengan e-mail pribadi

Hacker percaya memecahkan masalah harus menjadi proses publik, transparan selama dicoba pertama pada sebuah jawaban dapat dan harus diperbaiki jika seseorang pemberitahuan lebih luas bahwa itu tidak lengkap atau tidak benar. Juga, pembantu mendapatkan beberapa hadiah mereka untuk menjadi responden dari yang dipandang kompeten dan berpengetahuan dengan rekan-rekan mereka.

Ketika Anda meminta balasan pribadi, Anda mengganggu proses dan pahala. Jangan lakukan ini. Ini adalah responden pilihan apakah untuk membalas pribadi - dan jika dia tidak, itu biasanya karena ia berpikir pertanyaannya terlalu sakit-dibentuk atau jelas untuk menarik untuk orang lain.

Ada satu pengecualian terbatas untuk aturan ini. Jika Anda berpikir pertanyaannya adalah seperti yang Anda akan mendapatkan banyak jawaban yang semua erat serupa, maka kata-kata ajaib yang " e-mail saya dan saya akan meringkas jawaban untuk kelompok " . Hal ini sopan untuk mencoba dan menyimpan mailing list atau newsgroup banjir posting substansial identik - tetapi Anda harus menjaga janji untuk meringkas.

Eksplisit tentang pertanyaan Anda

pertanyaan terbuka cenderung dianggap sebagai open-ended waktu tenggelam. Orang-orang yang paling mungkin untuk dapat memberikan jawaban yang berguna juga orang-orang tersibuk (jika hanya karena mereka mengambil paling bekerja sendiri). Orang-orang seperti yang alergi untuk membuka-ended waktu tenggelam, sehingga mereka cenderung alergi untuk membuka-berakhir pertanyaan.

Anda lebih mungkin untuk mendapatkan respon berguna jika Anda eksplisit tentang apa yang ingin responden lakukan (memberikan petunjuk, kirim kode, cek patch Anda, apa pun). Ini akan memfokuskan usaha mereka dan secara implisit menempatkan batas atas waktu dan energi responden harus mengalokasikan untuk membantu Anda. Ini bagus.

Untuk memahami dunia ahli hidup dalam, berpikir keahlian sebagai sumber daya yang melimpah dan waktu untuk merespon sebagai salah satu langka. Kurang dari komitmen waktu Anda secara implisit meminta, semakin besar kemungkinan Anda untuk mendapatkan jawaban dari seseorang yang benar-benar baik dan benar-benar sibuk.

Jadi hal ini berguna untuk membingkai pertanyaan Anda untuk meminimalkan komitmen waktu yang dibutuhkan untuk seorang ahli untuk bidang itu - tapi ini sering tidak sama dengan menyederhanakan pertanyaan. Jadi, misalnya, " Apakah Anda memberi saya pointer ke penjelasan yang baik dari X? " Biasanya pertanyaan cerdas daripada " Apakah Anda menjelaskan X, please? " . Jika Anda memiliki beberapa kode rusak, biasanya cerdas untuk meminta seseorang untuk menjelaskan apa yang salah dengan itu daripada meminta seseorang untuk memperbaikinya.

Ketika bertanya tentang kode

Jangan meminta orang lain untuk debug kode Anda rusak tanpa memberikan petunjuk seperti apa masalah mereka harus mencari. Posting beberapa ratus baris kode, mengatakan "tidak bekerja", akan membuat Anda diabaikan. Posting selusin baris kode, mengatakan "setelah baris 7 saya mengharapkan untuk melihat <x>, tetapi <y> terjadi sebaliknya" jauh lebih mungkin untuk mendapatkan Anda tanggapan.

Cara yang paling efektif untuk menjadi tepat tentang masalah kode adalah untuk memberikan ujian bug-menunjukkan minimal. Apa kasus uji minimal? Ini sebuah ilustrasi dari masalah; hanya cukup kode untuk menunjukkan perilaku yang tidak diinginkan dan tidak lebih. Bagaimana Anda membuat kasus uji minimal? Jika Anda tahu apa line atau bagian kode memproduksi perilaku bermasalah, membuat salinan dan menambahkan hanya cukup kode mendukung untuk menghasilkan contoh lengkap (yaitu cukup bahwa sumber adalah diterima oleh compiler / interpreter / aplikasi apapun proses itu) . Jika Anda tidak dapat mempersempit ke bagian tertentu, membuat salinan dari sumber dan mulai menghapus potongan yang tidak mempengaruhi perilaku bermasalah. Semakin kecil kasus uji minimal Anda, lebih baik (lihat bagian yang disebut "Volume tidak presisi" ).

Menghasilkan kasus uji minimal benar-benar kecil tidak akan selalu mungkin, tetapi berusaha untuk disiplin yang baik. Ini dapat membantu Anda mempelajari apa yang Anda butuhkan untuk memecahkan masalah Anda sendiri - dan bahkan ketika tidak, hacker ingin melihat bahwa Anda telah mencoba. Ini akan membuat mereka lebih kooperatif.

Jika Anda hanya ingin review kode, mengatakan sebanyak di depan, dan pastikan untuk menyebutkan daerah apa yang Anda pikirkan mungkin sangat perlu ditinjau dan mengapa.

Jangan posting pertanyaan PR

Hacker adalah baik di tempat pertanyaan PR; kebanyakan dari kita telah dilakukan mereka sendiri. Pertanyaan-pertanyaan yang untuk Anda untuk bekerja, sehingga Anda akan belajar dari pengalaman. Hal ini OK untuk meminta petunjuk, tetapi tidak untuk seluruh solusi.

Jika Anda mencurigai Anda telah melewati pertanyaan PR, tetapi tidak dapat memecahkan hal itu, coba minta dalam forum kelompok pengguna atau (sebagai pilihan terakhir) dalam " pengguna " daftar / forum proyek. Sementara hacker akan melihat itu, beberapa pengguna tingkat lanjut mungkin setidaknya memberikan petunjuk.

Prune pertanyaan sia-sia

Menahan godaan untuk menutup permintaan Anda untuk membantu dengan pertanyaan semantik-nol seperti " yang bisa membantu saya? " Atau " Apakah ada jawaban? " Pertama: jika Anda telah menulis deskripsi masalah Anda setengah kompeten, seperti tertempel-on pertanyaan yang di terbaik berlebihan. Kedua: karena mereka berlebihan, hacker menemukan mereka mengganggu - dan kemungkinan untuk kembali jawaban logis sempurna tapi meremehkan seperti " Ya, Anda dapat membantu " dan " Tidak ada, tidak ada bantuan untuk Anda. "

Secara umum, meminta ya-atau-tidak ada pertanyaan adalah hal yang baik untuk menghindari kecuali jika Anda ingin ya-atau-tidak ada jawaban .

Jangan bendera pertanyaan Anda sebagai " Mendesak " , bahkan jika itu adalah untuk Anda

Itu masalah Anda, bukan milik kita. Mengklaim urgensi sangat mungkin menjadi kontra-produktif: hacker yang paling hanya akan menghapus pesan seperti upaya kasar dan egois untuk memperoleh perhatian segera dan khusus. Selain itu, kata 'Mendesak' (dan upaya lain yang serupa untuk menarik perhatian di baris subjek) sering memicu filter spam - penerima Anda dimaksudkan mungkin tidak pernah melihatnya sama sekali!

Ada satu semi-pengecualian. Hal ini dapat layak disebut jika Anda menggunakan program di beberapa tempat yang tinggi-profil, yang hacker akan mendapatkan sekitar bersemangat; dalam kasus seperti itu, jika Anda berada di bawah tekanan waktu, dan Anda mengatakan begitu sopan, orang mungkin mendapatkan cukup tertarik untuk menjawab lebih cepat.

Ini adalah hal yang sangat berisiko untuk dilakukan, namun, karena metrik hacker 'untuk apa yang menarik mungkin berbeda dari Anda. Posting dari Stasiun Luar Angkasa Internasional akan memenuhi syarat, misalnya, tapi postingan atas nama penyebab amal atau politik merasa-baik akan hampir pasti tidak. Bahkan, posting " Mendesak: Bantu saya menyimpan bayi anjing laut kabur! " Andal akan membuat Anda dijauhi atau dinyalakan bahkan oleh hacker yang berpikir bayi anjing laut kabur penting.

Jika Anda menemukan ini misterius, membaca kembali sisa how-to berulang kali sampai Anda mengerti sebelum posting apa-apa.

Courtesy tidak ada salahnya, dan kadang-kadang membantu

Jadilah sopan. Gunakan " Silahkan " dan " Terima kasih atas perhatian Anda " atau " Terima kasih atas pertimbangan Anda " . Jelaskan Anda menghargai waktu yang dihabiskan orang untuk membantu Anda gratis.

Jujur, ini tidak sepenting (dan tidak dapat menggantikan) menjadi tata bahasa, jelas, tepat dan deskriptif, menghindari format proprietary dll .; hacker pada umumnya lebih suka mendapatkan laporan bug agak kasar tapi secara teknis tajam dari ketidakjelasan sopan. (Jika ini membingungkan Anda, ingat bahwa kita menghargai pertanyaan oleh apa yang mengajarkan kita.)

Namun, jika Anda punya bebek teknis Anda berturut-turut, kesopanan tidak meningkatkan kesempatan Anda mendapatkan jawaban yang berguna.

(Kita harus mencatat bahwa satu-satunya keberatan yang serius yang kami terima dari hacker veteran untuk HOWTO ini sehubungan dengan rekomendasi kami sebelumnya untuk menggunakan " Terima kasih sebelumnya " . Beberapa hacker merasa ini berkonotasi niat untuk tidak terima siapa pun setelah itu. Rekomendasi kami adalah baik mengatakan " Terima kasih sebelumnya " pertama dan terima responden setelah itu, atau mengungkapkan kesopanan dengan cara yang berbeda, seperti dengan mengatakan " Terima kasih atas perhatian Anda " atau " Terima kasih atas pertimbangan Anda " .)

Menindaklanjuti dengan catatan singkat pada solusi

Mengirim catatan setelah masalah telah diselesaikan untuk semua yang membantu Anda; biarkan mereka tahu bagaimana keluar dan berterima kasih kepada mereka lagi untuk bantuan mereka. Jika masalah menarik minat umum dalam sebuah mailing list atau newsgroup, itu tepat untuk memposting ikutan di sana.

Secara optimal, jawabannya harus ke thread yang dimulai oleh pertanyaan postingan asli, dan harus 'TETAP', 'Terselesaikan' atau tag juga jelas di baris subjek. Pada milis dengan perputaran cepat, responden potensial yang melihat thread tentang " Masalah X " yang berakhir dengan " Soal X - TETAP " yang tahu tidak membuang-buang / nya waktu bahkan membaca thread (kecuali (s) ia secara pribadi menemukan masalah X menarik ) dan karena itu dapat menggunakan waktu yang memecahkan masalah yang berbeda.

Ikutan Anda tidak harus panjang dan terlibat; sederhana " Howdy - itu adalah kabel jaringan gagal! Terimakasih semuanya. - Bill " akan lebih baik daripada tidak sama sekali. Bahkan, ringkasan pendek dan manis lebih baik dari disertasi panjang kecuali solusinya memiliki kedalaman teknis nyata. Mengatakan tindakan apa memecahkan masalah, tetapi Anda tidak perlu memutar ulang seluruh urutan pemecahan masalah.

Untuk masalah dengan beberapa kedalaman, adalah tepat untuk mengirim ringkasan sejarah pemecahan masalah. Jelaskan pernyataan masalah akhir Anda. Jelaskan apa yang bekerja sebagai solusi, dan menunjukkan jalan buntu dihindari setelah itu . Gang-gang buta harus datang setelah solusi yang tepat dan bahan Ringkasan lainnya, daripada memutar tindak lanjut ke cerita detektif. Nama nama-nama orang yang membantu Anda; Anda akan membuat teman-teman seperti itu.

Selain sopan dan informatif, semacam ini ikutan akan membantu orang lain mencari arsip mailing-list / newsgroup / forum untuk mengetahui persis yang solusi membantu Anda dan dengan demikian juga dapat membantu mereka.

Terakhir, dan tidak sedikit, ini semacam ikutan membantu semua orang yang dibantu merasakan memuaskan penutupan tentang masalah ini. Jika Anda bukan seorang teknisi atau hacker sendiri, percaya bahwa perasaan ini sangat penting untuk para guru dan ahli Anda mengetuk untuk bantuan. Soal narasi yang terdiam dalam kehampaan yang belum terselesaikan adalah hal yang membuat frustrasi; hacker gatal untuk melihat mereka diselesaikan. Goodwill yang menggaruk gatal yang mendapatkan Anda akan sangat, sangat membantu Anda saat Anda perlu mengajukan pertanyaan.

Mempertimbangkan bagaimana Anda mungkin dapat mencegah orang lain memiliki masalah yang sama di masa depan. Tanyakan pada diri Anda jika dokumentasi atau FAQ Patch akan membantu, dan jika jawabannya adalah ya kirim patch yang ke pengelola.

Di antara hacker, perilaku semacam ini ikutan yang baik sebenarnya lebih penting daripada kesopanan konvensional. Ini adalah cara Anda mendapatkan reputasi untuk bermain baik dengan orang lain, yang dapat menjadi aset yang sangat berharga.

Bagaimana Menafsirkan Jawaban

RTFM dan STFW: Bagaimana Mengenalinya Anda sudah Serius Screwed Up

Ada sebuah tradisi kuno dan suci: jika Anda mendapatkan balasan yang bertuliskan " RTFM " , orang yang mengirimkannya berpikir Anda harus Baca Vidio Manual. Dia hampir pasti benar. Pergi membacanya.

RTFM memiliki kerabat yang lebih muda. Jika Anda mendapatkan balasan yang bertuliskan " STFW " , orang yang mengirimkannya berpikir Anda harus Mencari The Vidio Web. Dia hampir pasti benar.Pergi mencari itu. (Versi ringan dari ini adalah ketika Anda mengatakan " Google adalah teman Anda! " )

Dalam forum Web, Anda mungkin juga diberitahu untuk mencari arsip forum. Bahkan, seseorang bahkan mungkin begitu baik untuk memberikan pointer ke thread sebelumnya di mana masalah ini diselesaikan. Tapi jangan bergantung pada pertimbangan ini; melakukan arsip-pencarian Anda sebelum meminta.

Seringkali, orang yang memberitahu Anda untuk melakukan pencarian memiliki manual atau halaman web dengan informasi yang Anda butuhkan terbuka, dan melihat itu karena ia jenis. balasan ini berarti bahwa responden berpikir (a) informasi yang Anda butuhkan adalah mudah untuk menemukan, dan (b) Anda akan belajar lebih banyak jika Anda mencari informasi daripada jika Anda memilikinya sendok-makan untuk Anda.

Anda tidak harus tersinggung oleh ini; dengan standar hacker, responden Anda menunjukkan Anda semacam kasar hormat hanya dengan tidak mengabaikan Anda. Anda malah harus bersyukur atas kebaikan nenek ini.

Jika Anda tidak mengerti ...

Jika Anda tidak mengerti jawabannya, jangan langsung bangkit kembali permintaan untuk klarifikasi. Menggunakan alat yang sama yang Anda gunakan untuk mencoba dan menjawab pertanyaan Anda asli (manual, FAQ, Web, teman terampil) untuk memahami jawabannya. Kemudian, jika Anda masih perlu untuk meminta klarifikasi, menunjukkan apa yang telah Anda pelajari.

Misalnya, saya memberitahu Anda: " Kedengarannya seperti Anda punya zentry terjebak; Anda harus membersihkannya. " Kemudian: inilah buruk pertanyaan tindak lanjut: " ? Apa zentry sebuah " Berikut adalah baik pertanyaan tindak lanjut: " OK, saya membaca halaman manual dan zentries hanya disebutkan di bawah -z dan p switch . Tak satu pun dari mereka mengatakan apa-apa tentang kliring zentries.Apakah salah satu dari ini atau aku kehilangan sesuatu di sini? "

Berurusan dengan kekasaran

Banyak dari apa yang tampak seperti kekasaran di kalangan hacker tidak dimaksudkan untuk memberikan pelanggaran. Sebaliknya, itu adalah produk dari gaya komunikasi langsung, memotong-melalui-the-omong kosong yang alami untuk orang-orang yang lebih peduli tentang pemecahan masalah daripada membuat orang lain merasa hangat dan kabur.

Ketika Anda merasakan kekasaran, cobalah untuk bereaksi dengan tenang. Jika seseorang benar-benar bertindak keluar, sangat mungkin orang senior dalam daftar atau newsgroup atau forum akan memanggil dia di atasnya. Jika itu tidak terjadi dan Anda kehilangan kesabaran Anda, ada kemungkinan bahwa orang yang Anda kehilangan itu di berperilaku dalam norma-norma komunitas hacker dan Anda akan dianggap bersalah. Ini akan menyakiti kesempatan Anda untuk mendapatkan informasi atau bantuan yang Anda inginkan.

Di sisi lain, kadang-kadang Anda akan berjalan di kekasaran dan sikap yang cukup beralasan. Flip-sisi di atas adalah bahwa itu adalah bentuk yang dapat diterima untuk membanting pelaku nyata cukup sulit, membedah perilaku mereka dengan pisau bedah lisan yang tajam. Menjadi sangat, sangat yakin tanah Anda sebelum Anda mencoba ini, namun. Garis antara mengoreksi ketidaksopanan dan memulai flamewar sia-sia cukup tipis bahwa hacker sendiri tidak jarang blunder di atasnya; jika Anda seorang pemula atau orang luar, peluang Anda untuk menghindari kesalahan seperti yang rendah. Jika Anda setelah informasi daripada hiburan, lebih baik untuk menjaga jari-jari Anda dari keyboard daripada risiko ini.

(Beberapa orang menyatakan bahwa banyak hacker memiliki bentuk ringan autisme atau Sindrom Asperger, dan benar-benar hilang beberapa sirkuit otak yang melumasi " biasa " interaksi sosial manusia. Hal ini mungkin atau mungkin tidak benar. Jika Anda bukan seorang hacker sendiri , mungkin membantu Anda mengatasi eksentrik kami jika Anda berpikir kita sebagai kerusakan otak Silakan saja kami tidak akan peduli;.. kita ingin menjadi apa pun yang kita, dan umumnya memiliki skeptisisme yang sehat tentang label klinis).

Pengamatan Jeff Bigler tentang filter bijaksana juga relevan dan layak dibaca.

Pada bagian berikutnya, kita akan berbicara tentang masalah yang berbeda; jenis " kekasaran " Anda akan melihat ketika Anda berperilaku buruk.

Pada Tidak Bereaksi Like A Loser

Kemungkinan besar Anda akan mengacaukan beberapa kali di forum komunitas hacker - cara rinci dalam artikel ini, atau serupa. Dan Anda akan diberitahu persis bagaimana Anda mengacaukan, mungkin dengan asides berwarna-warni. Di muka umum.

Ketika ini terjadi, hal terburuk yang dapat Anda lakukan adalah merengek tentang pengalaman, mengklaim telah verbal diserang, permintaan maaf, menjerit, menahan nafas, mengancam tuntutan hukum, mengeluh kepada pengusaha orang, meninggalkan toilet duduk up, dll Sebaliknya, inilah yang Anda lakukan:

Lupakan saja. Itu normal. Bahkan, itu sehat dan tepat.

Standar masyarakat tidak menjaga diri mereka sendiri: Mereka dipelihara oleh orang-orang secara aktif menerapkan mereka, tampak, di depan umum . Jangan merengek bahwa semua kritik seharusnya disampaikan melalui e-mail pribadi: Itu bukan cara kerjanya. Juga tidak berguna untuk memaksa Anda telah secara pribadi terhina ketika seseorang berkomentar bahwa salah satu klaim Anda salah, atau bahwa pandangannya berbeda. Mereka adalah sikap pecundang.

Ada forum hacker mana, dari beberapa pengertian sesat hiper-kesopanan, peserta dilarang dari posting setiap kesalahan-temuan dengan tulisan orang lain, dan mengatakan " Jangan mengatakan apa-apa jika Anda tidak bersedia untuk membantu pengguna. " The mengakibatkan keberangkatan peserta clueful ke tempat lain menyebabkan mereka turun ke celoteh berarti dan menjadi tidak berguna sebagai forum teknis.

Berlebihan " ramah " (dengan cara itu) atau berguna: Pilih salah satu.

Ingat: Ketika hacker yang memberitahu Anda bahwa Anda telah mengacaukan, dan (tidak peduli seberapa kasar) memberitahu Anda untuk tidak melakukannya lagi, dia bertindak dari kepedulian (1) Anda dan (2) komunitasnya. Akan jauh lebih mudah baginya untuk mengabaikan Anda dan menyaring Anda keluar dari hidupnya. Jika Anda tidak dapat mengatur untuk bersyukur, setidaknya memiliki martabat sedikit, tidak merengek, dan tidak mengharapkan untuk diperlakukan seperti boneka yang rapuh hanya karena Anda seorang pendatang baru dengan jiwa teatrikal hipersensitif dan delusi hak .

Kadang-kadang orang akan menyerang Anda secara pribadi, api tanpa alasan yang jelas, dll, bahkan jika Anda tidak mengacaukan (atau hanya mengacaukan dalam imajinasi mereka). Dalam hal ini, mengeluh adalah cara untuk benar-benar mengacaukan.

flamers ini baik Lamers yang tidak memiliki petunjuk tapi percaya diri untuk menjadi ahli, atau calon psikolog pengujian apakah Anda akan mengacaukan. Pembaca lainnya baik mengabaikan mereka, atau menemukan cara untuk berurusan dengan mereka sendiri. perilaku flamers 'menciptakan masalah bagi diri mereka sendiri, yang tidak perlu perhatian Anda.

Jangan biarkan diri Anda ditarik ke flamewar, baik. Kebanyakan api yang terbaik diabaikan - setelah Anda sudah memeriksa apakah mereka benar-benar api, tidak pointer ke cara di mana Anda telah mengacaukan, dan tidak cerdik ciphered jawaban untuk pertanyaan Anda yang sesungguhnya (hal ini terjadi juga).

Pertanyaan Tidak Untuk Tanyakan

Berikut adalah beberapa pertanyaan bodoh klasik, dan apa yang hacker berpikir ketika mereka tidak menjawabnya.

 

Q: Dimana saya bisa menemukan program atau sumber daya X?

Q: Bagaimana cara menggunakan X untuk melakukan Y?

Q: Bagaimana cara mengkonfigurasi saya prompt shell?

Q: Dapatkah saya mengkonversi dokumen AcmeCorp ke file TeX menggunakan Bass-o-matic file converter?

Q: Saya {Program, konfigurasi, pernyataan SQL} tidak bekerja

Q: Saya mengalami masalah dengan mesin Windows saya. Bisakah kamu menolong?

Q: Program saya tidak bekerja. Saya pikir fasilitas sistem X rusak.

Q: Saya mengalami masalah menginstal Linux atau X. Bisakah Anda membantu?

Q: Bagaimana saya bisa memecahkan akar / mencuri channel-ops hak / membaca e-mail seseorang?

Q:

Di mana saya dapat menemukan program atau sumber daya X?

SEBUAH:

Tempat yang sama aku merasa, menipu - di ujung lain dari pencarian web. Ghod, tidak semua orang tahu bagaimana menggunakan Google belum?

Q:

Bagaimana saya bisa menggunakan X untuk melakukan Y?

SEBUAH:

Jika apa yang Anda inginkan adalah untuk melakukan Y, Anda harus menanyakan pertanyaan itu tanpa pra-mengandaikan penggunaan metode yang mungkin tidak sesuai. Pertanyaan dari formulir ini sering menunjukkan seseorang yang tidak hanya tahu tentang X, tapi bingung tentang apa masalahnya Y yang mereka memecahkan dan terlalu terpaku pada rincian situasi tertentu mereka. Hal ini biasanya cara terbaik untuk mengabaikan orang-orang seperti itu sampai mereka menentukan masalah mereka lebih baik.

Q:

Bagaimana cara mengkonfigurasi saya prompt shell?

SEBUAH:

Jika Anda cukup cerdas untuk mengajukan pertanyaan ini, Anda cukup pintar untuk RTFM dan mencari tahu sendiri.

Q:

Dapatkah saya mengkonversi dokumen AcmeCorp ke file TeX menggunakan Bass-o-matic file converter?

SEBUAH:

Cobalah dan lihat. Jika Anda melakukannya, Anda akan (a) belajar jawabannya, dan (b) berhenti membuang-buang waktu saya.

Q:

Saya {Program, konfigurasi, pernyataan SQL} tidak bekerja

SEBUAH:

Ini bukan pertanyaan, dan aku tidak tertarik bermain Twenty Questions untuk membongkar pertanyaan Anda yang sebenarnya dari Anda - Saya memiliki hal-hal lebih baik untuk dilakukan. Pada melihat sesuatu seperti ini, reaksi saya biasanya dari salah satu dari berikut:

  • apakah Anda memiliki hal lain untuk menambah itu?

  • oh, itu terlalu buruk, saya harap Anda mendapatkannya tetap.

  • dan ini persis apa hubungannya dengan saya?

Q:

Saya mengalami masalah dengan mesin Windows saya. Bisakah kamu menolong?

SEBUAH:

Iya nih. Membuang bahwa Microsoft sampah dan menginstal sistem operasi open-source seperti Linux atau BSD.

Catatan: Anda dapat mengajukan pertanyaan yang berkaitan dengan mesin Windows jika mereka tentang program yang tidak memiliki resmi Windows membangun, atau berinteraksi dengan mesin Windows (yaitu, Samba). Hanya jangan heran dengan jawaban bahwa masalah dengan Windows dan tidak program, karena Windows begitu rusak pada umumnya bahwa ini sangat sering terjadi.

Q:

Program saya tidak bekerja. Saya pikir fasilitas sistem X rusak.

SEBUAH:

Meskipun dimungkinkan bahwa Anda adalah orang pertama yang melihat kekurangan yang jelas dalam sistem panggilan dan perpustakaan banyak digunakan oleh ratusan atau ribuan orang, agak lebih mungkin bahwa Anda benar-benar mengerti. Klaim luar biasa membutuhkan bukti yang luar biasa; ketika Anda membuat klaim seperti ini, Anda harus kembali ke atas dengan dokumentasi yang jelas dan lengkap dari kasus kegagalan.

Q:

Saya mengalami masalah menginstal Linux atau X. Bisakah Anda membantu?

SEBUAH:

Tidak, aku akan membutuhkan tangan-on akses ke mesin Anda untuk memecahkan masalah ini. Pergi meminta kelompok pengguna Linux lokal Anda untuk tangan-pada bantuan. (Anda dapat menemukan daftar kelompok pengguna di sini .)

Catatan: pertanyaan tentang menginstal Linux mungkin tepat jika Anda berada di sebuah forum atau mailing list tentang distribusi tertentu, dan masalahnya adalah dengan bahwa distro; atau di forum kelompok pengguna lokal. Dalam hal ini, pastikan untuk menggambarkan rincian tepat dari kegagalan. Tapi apakah hati mencari pertama, dengan "linux" dan semua potongan curiga hardware.

Q:

Bagaimana saya bisa memecahkan akar / mencuri channel-ops hak / membaca e-mail seseorang?

SEBUAH:

Anda seorang orang rendahan karena ingin melakukan hal-hal seperti itu dan tolol untuk meminta hacker untuk membantu Anda.

Baik dan Buruk Pertanyaan

Akhirnya, saya akan menggambarkan bagaimana mengajukan pertanyaan dengan cara yang cerdas dengan contoh; pasang pertanyaan tentang masalah yang sama, salah satu bertanya dengan cara yang bodoh dan salah satu cara yang cerdas.

Bodoh: Dimana saya bisa mengetahui hal-hal tentang Foonly Flurbamatic?

Pertanyaan ini hanya memohon untuk "STFW" sebagai balasan.

Pintar: Saya menggunakan Google untuk mencoba untuk menemukan " Foonly Flurbamatic 2600 " di Web, tapi saya tidak punya hit berguna. Bisakah saya mendapatkan pointer ke pemrograman informasi pada perangkat ini?

Yang satu ini sudah STFWed, dan terdengar seperti mungkin ada masalah nyata.

Bodoh: saya tidak bisa mendapatkan kode dari foo proyek untuk mengkompilasi. Mengapa rusak?

querent berasumsi bahwa orang lain kacau. Sombong git ...

Cerdas: Kode dari foo proyek tidak dikompilasi di bawah Nulix versi 6.2. Saya sudah membaca FAQ, tetapi tidak memiliki apa-apa di dalamnya tentang masalah Nulix terkait. Berikut adalah transkrip dari upaya kompilasi saya; itu sesuatu yang saya lakukan?

querent telah ditentukan lingkungan, baca FAQ, menunjukkan kesalahan, dan tidak menganggap masalah itu adalah kesalahan orang lain. Yang satu ini mungkin layak perhatian.

Bodoh: Saya mengalami masalah dengan motherboard saya. Ada yang bisa membantu?

Tanggapan J. Acak Hacker untuk ini mungkin " Benar. Apakah Anda perlu bersendawa dan popok, juga? " Diikuti dengan pukulan dari tombol hapus.

Pintar: Aku mencoba X, Y, dan Z pada motherboard S2464. Ketika itu tidak berhasil, saya mencoba A, B, dan C. Perhatikan gejala penasaran ketika saya mencoba C. Jelas florbish yang grommicking, tapi hasilnya tidak apa yang bisa diharapkan. Apa penyebab biasa grommicking pada motherboard Athlon MP? Ada yang punya ide untuk tes lagi saya dapat menjalankan untuk dijabarkan masalah?

orang ini, di sisi lain, tampaknya layak jawaban. Dia / dia telah dipamerkan kecerdasan pemecahan masalah dan bukan pasif menunggu jawaban untuk menjatuhkan dari atas.

Dalam pertanyaan terakhir, melihat perbedaan halus namun penting antara menuntut " Beri aku jawaban " dan " Tolong bantu saya mencari tahu apa diagnostik tambahan yang bisa saya jalankan untuk mencapai pencerahan. "

Bahkan, bentuk pertanyaan terakhir erat berdasarkan kejadian nyata yang terjadi pada bulan Agustus 2001 di linux-kernel mailing list (LKML). Saya (Eric) adalah orang mengajukan pertanyaan saat itu. Saya melihat kemacetan misterius pada motherboard Tyan S2462. Para anggota daftar memasok informasi penting yang saya butuhkan untuk menyelesaikannya.

Dengan mengajukan pertanyaan dengan cara yang saya lakukan, saya memberikan sesuatu untuk mengunyah orang; 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 penghormatan terhadap nilai waktu mereka dengan mengatakan kepada mereka jalan buntu saya sudah lari ke bawah.

Setelah itu, ketika saya mengucapkan terima kasih semua orang dan mengatakan seberapa baik proses bekerja, seorang anggota LKML mengamati bahwa ia pikir itu telah bekerja bukan karena aku " nama "dalam daftar itu, tapi karena saya mengajukan pertanyaan dalam bentuk yang tepat.

Hacker dalam beberapa hal meritokrasi yang sangat kejam; Aku yakin dia benar, dan bahwa jika saya telah berperilaku seperti spons saya akan telah dinyalakan atau diabaikan tidak peduli siapa aku.Sarannya bahwa saya menulis seluruh kejadian sebagai instruksi kepada orang lain dipimpin langsung kepada komposisi panduan ini.

Jika Anda tidak Bisa Dapatkan Sebuah Jawaban

Jika Anda tidak bisa mendapatkan jawaban, jangan tersinggung bahwa kita tidak merasa kami dapat membantu Anda. Kadang-kadang anggota kelompok diminta mungkin hanya tidak tahu jawabannya. Tidak ada respon tidak sama dengan yang diabaikan, meskipun diakui sulit untuk melihat perbedaan dari luar.

Secara umum, hanya kembali posting pertanyaan Anda adalah ide yang buruk. Ini akan dilihat sebagai sia-sia menjengkelkan. Memiliki kesabaran: orang dengan jawaban Anda mungkin berada dalam zona waktu yang berbeda dan tertidur. Atau mungkin bahwa pertanyaan Anda tidak terbentuk dengan baik untuk memulai dengan.

Ada sumber-sumber bantuan Anda bisa pergi ke, sering sumber-sumber yang lebih baik disesuaikan dengan kebutuhan seorang pemula ini.

Ada banyak kelompok pengguna online dan lokal yang penggemar tentang perangkat lunak, meskipun mereka mungkin tidak pernah ditulis perangkat lunak sendiri. Kelompok-kelompok ini sering membentuk sehingga orang dapat saling membantu dan membantu pengguna baru.

Ada juga banyak perusahaan komersial Anda dapat kontrak dengan bantuan, baik besar maupun kecil. Jangan kecewa pada gagasan harus membayar untuk sedikit bantuan! Setelah semua, jika mesin mobil Anda pukulan paking kepala, kemungkinan Anda akan bawa ke bengkel dan membayar untuk mendapatkannya tetap. Bahkan jika perangkat lunak tidak dikenakan biaya apapun, Anda tidak dapat mengharapkan dukungan yang selalu datang secara gratis.

Untuk perangkat lunak populer seperti Linux, ada pengguna setidaknya 10.000 per pengembang. Itu tidak mungkin bagi satu orang untuk menangani panggilan dukungan dari lebih dari 10.000 pengguna.Ingat bahwa bahkan jika Anda harus membayar untuk dukungan, Anda masih membayar jauh lebih sedikit daripada jika Anda harus membeli perangkat lunak juga (dan dukungan untuk perangkat lunak sumber tertutup biasanya lebih mahal dan kurang kompeten dibandingkan dukungan untuk perangkat lunak open-source) .

Cara Jawaban di Jalan Bermanfaat

Jadilah lembut. Stres yang berhubungan dengan masalah dapat membuat orang tampak kasar atau bodoh bahkan ketika mereka tidak.

Membalas pelaku pertama off-line. Tidak perlu penghinaan publik untuk seseorang yang mungkin telah membuat kesalahan yang jujur. Seorang newbie nyata mungkin tidak tahu bagaimana untuk arsip atau di mana FAQ disimpan atau diposting pencarian.

Jika Anda tidak tahu pasti, mengatakan begitu! A jawaban yang salah tapi berwibawa terdengar lebih buruk daripada tidak sama sekali. Jangan arahkan siapa pun menyusuri jalan yang salah hanya karena itu menyenangkan untuk terdengar seperti seorang ahli. Jadilah rendah hati dan jujur; menetapkan contoh yang baik untuk kedua querent dan rekan-rekan Anda.

Jika Anda tidak dapat membantu, tidak menghambat. Jangan membuat lelucon tentang prosedur yang bisa sampah setup pengguna - getah miskin mungkin menafsirkan ini sebagai petunjuk.

Tanyakan pertanyaan mendalam untuk memperoleh rincian lebih lanjut. Jika Anda pandai ini, querent akan belajar sesuatu - dan mungkin Anda. Cobalah untuk mengubah pertanyaan buruk menjadi baik satu;ingat kami semua pemula sekali.

Sementara bergumam RTFM kadang-kadang dibenarkan ketika membalas seseorang yang hanya malas jorok, pointer ke dokumentasi (bahkan jika itu hanya saran untuk google untuk frase kunci) yang lebih baik.

Jika Anda akan menjawab pertanyaan sama sekali, memberikan nilai yang baik. Jangan menyarankan workarounds kludgy ketika seseorang menggunakan alat yang salah atau pendekatan. Menyarankan alat yang baik. Membingkai pertanyaan.

Menjawab pertanyaan yang sebenarnya! Jika querent telah begitu menyeluruh untuk melakukan atau penelitian dan telah dimasukkan dalam query yang X, Y, Z, A, B, dan C telah mencoba tanpa hasil yang baik, itu adalah amat membantu untuk menanggapi dengan " Coba A atau B, " atau dengan link ke sesuatu yang hanya mengatakan, " Coba X, Y, Z, A, B, atau C. " .

Membantu komunitas Anda belajar dari pertanyaan itu. Ketika Anda bidang pertanyaan yang bagus, tanyakan pada diri sendiri " Bagaimana dokumentasi atau FAQ yang relevan harus mengubah sehingga tak seorang pun harus menjawab ini lagi? " Lalu mengirim patch ke pengelola dokumen.

Jika Anda melakukan penelitian untuk menjawab pertanyaan, menunjukkan keterampilan Anda daripada menulis seolah-olah Anda menarik jawabannya keluar dari pantat Anda. Menjawab satu pertanyaan yang baik seperti makan lapar orang satu kali makan, tetapi mengajarkan mereka keterampilan penelitian dengan contoh yang menunjukkan mereka bagaimana tumbuh makanan untuk seumur hidup.

Sumber terkait

Jika Anda membutuhkan pengajaran dalam dasar-dasar komputer bagaimana pribadi, Unix, dan pekerjaan Internet, lihat The Unix dan Internet Fundamentals HOWTO .

Ketika Anda melepaskan perangkat lunak atau patch untuk menulis perangkat lunak, cobalah untuk mengikuti panduan di HOWTO Software Rilis Practice .

Ucapan Terima Kasih

Evelyn Mitchell kontribusi beberapa contoh pertanyaan bodoh dan mengilhami " Bagaimana Untuk Berikan A Jawaban Baik " bagian. Mikhail Ramendik kontribusi beberapa saran sangat berharga untuk perbaikan.