ถามอย่างไรจึงจะได้คำตอบ

จาก OpenTLE Wiki
(เปลี่ยนทางจาก Smart-questions)
ข้ามไปยัง: ป้ายบอกทาง, ค้นหา

เนื้อหา

ผู้เขียน


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

ประวัติการปรับปรุง

ประวัติการปรับปรุง
Revision 3.4 24 Mar 2007 esr
News section, "When asking about code".
Revision 3.3 29 Sep 2006 esr
Folded in a good suggestion from Kai Niggemann.
Revision 3.2 10 Jan 2006 esr
Folded in edits from Rick Moen.
Revision 3.1 28 Oct 2004 esr
Document 'Google is your friend!'
Revision 3.0 2 Feb 2004 esr
Major addition of stuff about proper etiquette on Web forums.

บทความนี้ในภาษาอื่น

ภาษาอื่นๆ: Bahasa Indonesian Brazilo-Portuguese Chinese Czech Danish Estonian Finnish French Georgian German Hungarian Italian Japanese Polish Portuguese Romanian Russian Serbian Spanish Swedish Turkish

ถ้าท่านต้องการทำสำเนา จัดเก็บ แปล หรือ คัดลอกส่วนใดส่วนหนึ่งของบทความนี้ กรุณาอ่าน copying policy ก่อน ส่วนต้นฉบับภาษาอังกฤษอ่านได้ที่ Smart Questions

ขอบเขตความรับผิดชอบ

มีผู้ดูแลเว็บไซต์หลายที่ ได้เชื่อมโยงและอ้างอิงไปยังบทความนี้ หรือ เชื่อมโยงไปยังต้นฉบับ จริงๆ แล้วเป็นสิ่งที่ดี และ เป็นสิ่งที่ผู้เขียนตั้งใจไว้ และ ถ้าคุณเป็นคนหนึ่งที่ทำแบบนั้นก็ขอให้มีการแสดงข้อความเตือนที่เห็นได้ชัดๆว่า "ผู้เขียนบทความนี้ไม่มีส่วนในการดูแลและให้ความช่วยเหลือกับเว็บไซต์ของคุณ"

ผู้เขียนบทความมักได้รับความเดือดร้อนจากเรื่องการนำบทความนี้ไปใช้โดยไม่มีการประกาศให้ชัดเจน และ หลายคนคิดว่าผู้เขียนบทความสามารถแก้ไขปัญหาต่างๆ ได้

ถ้าคุณกำลังอ่านบทความนี้อยู่เพราะต้องการความช่วยเหลือ และ คุณได้รับประโยชน์จากบทความนี้ก็ขอยกคุณความดีให้กับผู้เขียนบทความต้นฉบับทั้งหมด ถ้าคุณคิดจะถามคำถามอย่าถามผู้เขียนบทความนี้ เพราะคำถามนั้นอาจไม่รับความสนใจ จริงๆ แล้วบทความนี้กำลังบอกคุณว่าจะขอความช่วยเหลืออย่างไรจากผู้รู้ทั้งหลาย ไม่ว่าจะเป็นเรื่องของอุปกรณ์ต่อพ่วง หรือ ซอฟ์ตแวร์ต่างๆ และคำตอบเหล่านั้น เกือบ 99% ผู้เขียนบทความนี้ไม่ใช่คนตอบ

บทนำ

ในโลกของแฮ็กเกอร์ การที่คำถามเชิงเทคนิคที่คุณถามจะได้รับคำตอบแบบใดนั้น รูปแบบการตั้งคำถามก็มีความสำคัญเท่ากับความยากง่ายของปัญหา บทความนี้จะให้คำแนะคำว่าจะถามอย่างไรจึงจะได้คำตอบที่สมความตั้งใจมากที่สุด

ปัจจุบันการใช้งานโอเพนซอร์สได้แพร่วงกว้างออกไปมาก คุณสามารถที่จะหาคำตอบดีๆได้จากผู้ใช้ที่มีประสบการณ์ที่มีอยู่มากมายหรือแฮ็กเกอร์ ซึ่งเป็นสิ่งที่ดี เพราะกลุ่มผู้ใช้เหล่านี้มักจะมีความอดทนกับความผิดพลาดของมือใหม่ ถึงกระนั้นการปฏิบัติตัวกับผู้ใช้ที่มีประสบการณ์ในแบบเดียวกับที่คุณปฏิบัติกับแฮ็กเกอร์ ก็เป็นวิธีที่น่าจะมีประสิทธิภาพสูงสุดในการได้รับคำตอบที่ถูกต้อง

ประการแรกต้องทำความเข้าใจว่าแฮ็กเกอร์มักชอบปัญหาที่ยากๆ และดีพอ คำถามที่เต็มไปด้วยคำแนะให้กับพวกเขา ถ้าพวกเราไม่ทำ พวกเราก็คงไม่มาอยู่กันที่นี่ ถ้าคุณถามคำถามที่น่าสนใจพวกเราจะรู้สึกสำนึกในบุญคุณเป็นอย่างยิ่ง คำถามที่ดีเป็นสิ่งกระตุ้น และ เป็นของขวัญ คำถามที่ดีมีส่วนช่วยในการพัฒนาความเข้าใจของพวกเรา และ บ่อยครั้งทำให้เราพบปัญหาที่ไม่เคยได้คิดหรือ คาดไม่ถึง สำหรับแฮ็กเกอร์แล้วการได้รับคำว่า "คำถามที่ดี" ถือได้ว่าเป็นคำชมที่จริงใจและมีค่า

แต่อย่างไรก็ตาม แฮ็กเกอร์ก็มีชื่อในเรื่องของเย่อหยิ่ง และ ไม่ชอบคำถามพื้นๆ และในบางครั้งดูเหมือนว่าพวกเราจะตอบกลับไปยังมือใหม่ด้วยถ้อยคำที่หยาบและรุนแรง และถึงกับเพิกเฉย แต่จริงๆ แล้วมันไม่จริงเลย

พวกเราปฏิเสธไม่ได้ว่า เรามักจะไม่เป็นมิตรกับคนที่ไม่ยอมช่วยตัวเองก่อนจะมาถามเรา คนเหล่านี้เป็นพวกที่ทำให้เสียเวลา - พวกนี้มักเอาแต่ได้ไม่ยอมให้กลับ และพวกนี้ทำให้เราเสียเวลา แทนที่จะนำไปช่วยแก้ปัญหาที่น่าสนใจ และช่วยคนที่สมควรจะได้รับคำตอบ เราเรียกคนพวกนี้ว่า "พวกขี้แพ้" (และด้วยเหตุผลทางประวัติศาสตร์บางประการเราจะเรียกพวกนี้ว่า "lusers")

พวกเราเข้าใจว่า หลายคนอยากจะใช้โปรแกรมที่เราเขียนขึ้นเท่านั้น ไม่ได้มีความสนใจในการเรียนรู้รายละเอียดด้านเทคนิค สำหรับคนส่วนใหญ่แล้ว คอมพิวเตอร์เป็นแค่เครื่องมือ วิธีการในการทำงานให้ลุล่วง พวกเขามีสิ่งสำคัญที่ต้องทำและมีชีวิตที่ต้องรับผิดชอบ เราเข้าใจจุดนี้ และไม่ได้คาดหวังว่าทุกคุณต้องมาสนใจเรื่องเทคนิคอย่างที่เราสนใจ อย่างไรก็ตาม วิธีการตอบคำถามของเราจะเหมาะสำหรับคนที่ มีความสนใจดังกล่าวและพร้อมจะมีส่วนร่วมในการแก้ไขปัญหา สิ่งเหล่านี้ไม่มีวันเปลี่ยน และไม่ควรจะถูกเปลี่ยน เพราะหากมีการเปลี่ยน เราจะมีประสิทธิภาพในการทำงานลดลง

พวกเรา (ส่วนใหญ่) เป็นอาสาสมัคร เรายอมให้เวลาบางส่วนในชีวิตที่แสนยุ่งเพื่อตอบคำถาม และบางครั้งเราก็รู้สึกว่าคำถามเหล่านี้มีมากเกินไป ดังนั้นเราจะกรองคำถามอย่างไม่เกรงใจ โดยเฉพาะเราจะโยนคำถามของพวกขี้แพ้ทิ้ง เพื่อใช้เวลาในการตอบคำถามกับคนที่ไม่ใช่พวกนั้นอย่างมีประสิทธิภาพ

หากคุณคิดว่าทัศนคติแบบนี้เป็นพวกเอาแต่ใจ, ผยอง, หรือจองหอง ก็ขอให้คุณกลับไปตรวจสมมติฐานของตัวเองก่อน เราไม่ได้ขอให้คุณมานอบน้อมเรา - ที่จริงแล้วพวกเราส่วนใหญ่อยากจะปฏิบัติต่อคุณอย่างเสมอภาคและรับคุณมาเป็นส่วนหนึ่งของเรา หากคุณได้พยายามเพื่อให้สิ่งนี้เป็นจริง แต่ไม่มีประโยชน์ที่เราจะช่วยคนที่ไม่ยอมช่วยตัวเอง การไม่รู้นั้นเป็นเรื่องรับได้ แต่การแกล้งโง่นั้นเป็นอีกเรื่อง

ดังนั้น แม้ว่าคุณไม่ต้องมีความรู้ด้านเทคนิคเพื่อให้เราสนใจ แต่คุณต้องแสดงให้เห็นว่าคุณมีแนวคิดที่จะสร้างความรู้คือ มีความใส่ใจ ใช้ความคิด ช่างสังเกต และพร้อมจะมีส่วนร่วมในการแก้ไขปัญหา หากคุณรับสภาพแวดล้อมแบบนี้ไม่ได้ เราขอแนะนำให้คุณไปจ้างระบบสนับสนุน แทนที่จะขอให้แฮ็กเกอร์มาช่วยคุณฟรีๆ

หากคุณต้องการความช่วยเหลือจากเรา อย่ามาแบบพวกขี้แพ้ คุณเองก็ไม่ควรจะดูเหมือนพวกนี้ด้วย วิธีที่จะได้คำตอบที่เร็วและตรงคือถามอย่างคนที่ฉลาด มั่นใจ และพอรู้เรื่อง จะขอความช่วยเหลือกับปัญหาสักเรื่อง

(ยินดีรับข้อเสนอแนะเพื่อปรับปรุงคำแนะนำฉบับนี้ โดยสามารถเมล คำแนะนำที่ esr@thyrsus.com หรือ respond-auto@linuxmafia.com แต่ขอให้ทราบว่าเอกสารนี้ไม่ได้จัดทำเพื่อเป็นส่วนหนึ่งของ netiquette และเราจะไม่รับข้อเสนอแนะที่ไม่เกี่ยวข้องกับการขอคำตอบจากกระดานสนทนาด้านเทคนิคให้ได้ผล

ก่อนตั้งคำถาม

ก่อนถามปัญหาทางเทคนิคผ่านทาง e-mail หรือใน newsgroup หรือ ใน chat board แนะให้ทำสิ่งต่อไปนี้ก่อน

  1. หาคำตอบจาก ใน archives ของกระดานนั้นก่อน
  2. ไปค้นในเว็บทั่วไปเสียก่อน
  3. พยายามอ่านหนังสือคู่มือ
  4. ไปหาอ่านใน FAQ (ปัญหาที่เจอบ่อย)
  5. ลองตรวจดู หรือ ทำการทดลองเองก่อน
  6. ถามเพื่อนที่เก่งหรือคล่องกว่า
  7. หากคุณเป็น programmer ลองพยายามศึกษา source code เองดูก่อน

ระหว่างการถามคำถาม ให้แสดงว่าคุณได้พยายามทำด้วยตัวเองแล้ว เพราะมันจะช่วยให้คุณไม่ใช่ตัวขี้เกียจที่รอแต่คนมาป้อนให้และไม่เป็นการเสียเวลาสำหรับผู้ที่จะช่วยให้คำตอบคุณ จะให้ดีกว่านั้น คุณควรนำเสนอสิ่งที่คุณได้ ศึกษา มาก่อนหน้านี้ เพราะเราชอบจะตอบคำถามกับคนที่แสดงให้เห็นว่าพวกเขาสามารถเรียนรู้จากคำตอบได้

หัดใช้ชั้นเชิงในการค้นหา เช่นการใช้ Google โดยใช้ข้อความที่แสดง error ของโปรแกรมที่ใช้ (Google groups) วิธีนี้คุณอาจจะได้คำตอบที่ต้องการแบบตรงๆ จากคู่มือการใช้งาน หรือกลุ่มจดหมายเลยก็เป็นได้ และแม้ว่าจะหาคำตอบไม่ได้ ประโยคที่ว่า "ผมลองหาจาก google ดูแล้ว แต่ยังไม่เจอคำตอบที่น่าจะแก้ไขปัญหาได้" ก็เป็นสิ่งที่ดีที่ควรเขียนไว้ในอีเมลหรือการโพสต์เมื่อขอความช่วยเหลือ เพราะอย่างน้อยก็แสดงแล้วว่าการค้นหาไม่ช่วยเท่าไร

ให้เวลากับการค้นหาหน่อย อย่าไปคิดว่าการค้นหาแป๊บเดียวบน Google จะช่วยแก้ปัญหาซับซ้อนได้ ให้อ่านและทำความเข้าใจกับ FAQs ให้ดีก่อนที่จะถามผู้รู้ เชื่อเราเถอะ พวกเขามองออกเลยว่าคุณได้ศึกษาและขบคิดมามากเท่าไหร่จากลักษณะคำถามของคุณ และพวกเขายินดีจะช่วยหากคุณมีการเตรียมตัวพร้อม อย่าถามทุกอย่าง (หรือมากอย่างเกินไป) ในทันทีเพียงเพราะว่าคุณค้นคำตอบไม่เจอในครั้งแรก

การเตรียมคำถาม ไตร่ตรองให้ดี การถามแบบลวกๆ ก็จะได้คำตอบแบบลวกๆ หรือ ไม่ได้คำตอบอะไรเลยก็เป็นได้ ยิ่งคุณแสดงให้เห็นว่าคุณได้พยายามแก้ไขปัญหาด้วยตนเองก่อนจะขอความช่วยเหลือมากเท่าไร คุณก็ยิ่งมีโอกาสจะได้รับความช่วยเหลือมากเท่านั้น

ให้ระมัดระวังเรื่องการตั้งคำถาม หากคุณถามคำถามที่ตั้งบนสมมติฐานที่ผิด พวกแฮ็กเกอร์ก็จะตอบด้วยคำตอบที่ไม่มีประโยชน์เช่นกัน โดยคิดในใจว่า "คำถามโง่ๆ" และคิดไปว่าประสบการณ์จากการที่ได้รับคำตอบจากคำถามที่ถาม (แทนที่จะเป็นคำถามที่ต้องการ) น่าจะสอนบทเรียนบางอย่างให้กับคุณ

อย่าคิดเอาเองว่าคุณ ต้องได้ คำตอบ มันไม่จำเป็น เพราะคุณไม่ได้เสียเงินจ้างใคร คุณจะได้คำตอบแน่ หากคุณสมควรได้รับ และความสมควรคือการตั้งคำถามที่มีสาระ น่าสนใจ และกระตุ้นความคิด คำถามที่จะช่วยให้กลุ่มได้ประสบการณ์เพิ่มขึ้น ไม่ใช่แค่เรียกร้องความรู้จากคนอื่นแค่อย่างเดียว

ในอีกแง่หนึ่ง การบอกอยากชัดแจ้งว่าคุณสามารถ และยินดีที่จะมีส่วนร่วมในการค้นหาทางแก้ไข นั้นเป็นจุดเริ่มต้นที่ดี "ได้โปรดช่วยชี้นำด้วย" "ตัวอย่างนี้ผิดพลาดที่ไหน?" และ "ผมควรไปค้นในเว็บไซต์ไหน?" นั้นมักจะได้รับคำตอบมากกว่า "ช่วยบอกวิธีที่ผมควรทำให้ที" เพราะคุณแสดงว่าคุณยินดีจะทำด้วยตนเองหากมีใครช่วยให้เบาะแสในทิศทางที่ถูกต้อง

ระหว่างการถาม

ถามให้ถูกที่

ระวังในการเลือกคำถาม คุณอาจถูกเพิกเฉย หากเขียนแบบคนที่ไม่แสวงหาค้นคว้าช่วยตัวเอง ถ้าคุณทำสิ่งต่อไปนี้ :

  • โพสท์ถามในฟอรัมที่ไม่เกี่ยวข้อง
  • โพสท์คำถามพื้นฐานมากบนฟอรัมของพวกผู้ชำนาญการมาก, หรือในทำนองกลับกันถามคำถามยากๆ บนฟอรัมของคนใช้งานใหม่
  • โพสท์ซ้อนทับกับกลุ่มอื่นๆ
  • ถือวิสาสะติดต่ออีเมลของคนที่คุณไม่ได้รู้จักและไม่ได้มีส่วนรับผิดชอบในการตอบปัญหาเป็นการส่วนตัว

แฮ็กเกอร์ จะละทิ้งคำถามที่ไม่เหมาะเหล่านี้เพื่อที่จะรักษาช่องทางการสื่อสารของพวกเขาไม่ให้ถูกรบกวน คุณคงไม่อยากให้เรื่องนี้เกิดขึ้นกับคุณ

เพราะฉะนั้นในขั้นตอนแรก คือ หาฟอรัมที่ถูกต้อง การหาจากเว็บไซต์ต่างๆ เช่น Google เป็นวิธีที่ได้ผล ให้หาจากโครงการที่มีความใกล้เคียงกันของ hardware หรือ software ที่เป็นปัญหาของคุณ โดยปกติแล้วโครงการนั้นๆ จะมี FAQ (คำถามที่ถูกถามบ่อยๆ) และจดหมายภายในกลุ่มผู้ใช้งานที่ติดต่อกันเก็บบันทึกไว้ บันทึกเหล่านี้เป็นที่สุดท้ายที่จะหาตัวช่วย หากความพยายามของคุณ (รวมไปถึงการ อ่าน FAQ ที่พบ) ยังไม่พบการแก้ปัญหา หน้าเว็บโครงการนั้นๆ อาจอธิบายขั้นตอนการรายงานบั๊ก หรือมีลิ้งค์ให้ ซึ่งหากมีลิ้งค์ก็ให้ตามไป การเที่ยวส่งเมล ไปยังใครต่อใครในฟอรัมทั้งที่คุณไม่รู้จักเป็นเรื่องเสี่ยง ตัวอย่างเช่น อย่านึกเอาเองว่าผู้เขียนข้อมูลบนเว็บไซต์ฟรีจะยอมเป็นที่ปรึกษาให้คุณฟรีๆ ด้วย อย่าไปคาดเดาเอาว่าคำถามของคุณจะได้รับการยอมรับหรือไม่ หากคุณไม่แน่ใจ ให้ส่งไปยังที่อื่น หรืออย่าส่งเลยดีกว่า

ในการเลือกฟอรั่ม กลุ่มข่าว หรือกลุ่มจดหมาย อย่าเลือกด้วยชื่ออย่างเดียว ให้อ่าน FAQ หรือคำประกาศเพื่อให้แน่ใจว่าคำถามของคุณนั้นเป็นประเด็นเดียวกัน ให้อ่านข้อความเก่าก่อนจะโพสต์ เพื่อให้รู้จักมารยาทของฟอรัม ความคิดที่ดีอีกอย่างคือการหาด้วยคำสำคัญที่เกี่ยวกับปัญหาของคุณบนบันทึกกลุ่มข่าวหรือกลุ่มจดหมายก่อนจะโพสต์ คุณอาจพบคำตอบ หรืออย่างน้อยก็ช่วยให้คุณสามารถตั้งคำถามได้ดีขึ้น

อย่าไปเที่ยวขอความช่วยเหลือจากหลายๆ ที่ในคราวเดียวกัน เพราะมันเหมือนกับการไปแหกปากไปทั่ว ซึ่งจะทำให้คนอื่นรำคาญ ค่อยๆ ขอความช่วยเหลือทีละแห่ง

คุณต้องรู้ว่าประเด็นของคุณคืออะไร ความผิดพลาดขั้นมูลฐานที่เกิดประจำคือการถามคำถามเกี่ยวกับการโปรแกรมอินเตอร์เฟซของยูนิกซ์ หรือวินโดวส์ ในฟอรั่มที่เกี่ยวกับภาษา หรือชุดโปรแกรม หรือเครื่องมือ ทีใช้ข้ามระบบกันได้ในทีเดียวทั้งสองที่ หากคุณไม่รู้ว่าทำไมมันเป็นความผิดพลาด คุณก็ไม่ควรถาม จนกว่าคุณจะรู้เหตุผลนะ

โดยทั่วไปแล้ว คำถามที่โพสต์บนกระดานสาธารณะที่เลือกได้ดี จะมีโอกาสได้รับคำตอบมากกว่ากระดานส่วนบุคคล เนื่องจากสาเหตุหลายประการ ข้อหนึ่งก็คือจำนวนของผู้ที่สามารถตอบได้ อีกข้อคือจำนวนของผู้ที่จะอ่าน แฮ็กเกอร์นั้นชอบจะตอบคำถามที่สอนคนจำนวนมาก ยิ่งกว่าการตอบคำถามที่สอนคนไม่กี่คน

เป็นที่เข้าใจกันว่า แฮ็กเกอร์ที่มีฝีมือและผู้เขียนโปรแกรมยอดนิยมนั้นมีโอกาสจะได้รับข้อความที่ไม่ได้ตั้งใจส่งให้มากกว่าคนปกติ ยิ่งคุณเพิ่มจำนวนข้อความเหล่านี้ ในแง่เลวร้ายที่สุดคุณอาจเป็นน้ำหยดสุดท้ายที่ทำให้เขื่อนแตก ในหลายครั้ง ผู้ซึ่งช่วยโครงการยอดนิยมจะเลิกสนับสนุน เพราะปัญหาที่ของเมล ที่ไม่มีประโยชน์ได้ทะลักเข้ามาในกล่องเมลของพวกเขา เกินกว่าที่จะรับได้

มือใหม่ถามที่ไหนถึงจะได้คำตอบที่เร็วกว่า

กลุ่มผู้ใช้ในท้องถิ่นของคุณ หรือ ผู้พัฒนาลินุกซ์ อาจจะโฆษณาใน กระดานในเว็บ หรือ IRC channel ว่าพวกผู้เพิ่งเริ่มใช้ จะขอความช่วยเหลือเวลามีปัญหาได้ที่ใหน (ในประเทศที่ไม่ใช้ภาษาอังกฤษ แหล่งความช่วยเหลือ มักจะเป็นแบบกลุ่มจดหมาย) แหล่งเหล่านี้จะเป็นที่ที่จะช่วยพวกผู้ใช้มือใหม่ได้ดีที่สุด โดยเฉพาะอย่างยิ่งหากคุณคิดว่าคุณเจอปัญหาที่คิดว่าไม่ยากและที่เจอกันบ่อย หรือคุณอาจจะลองเข้าไปถามปัญหาที่ IRC channel ซึ่งมักจะได้คำตอบทันทีเลย

ความจริงแล้ว หากท่านเจอปัญหาจากแผ่นลินุกซ์จาก distro ใด (ซึ่งมักจะเจอกันบ่อยในปัจจุบันนี้) ก็น่าจะไปถามใน กระดาน/กลุ่ม ของ distro นั้น ก่อนจะไปถามยัง กระดาน/กลุ่ม ของโครงการ เพราะคนดูแลโครงการเขาอาจจะตอบว่า "คุณต้องใช้ของ เรา"

ก่อนจะถามใน กระดานของเว็บใดๆ ขอให้ดูว่า ในกระดานนั้น สามารถ "ค้นหา" คำตอบเก่าๆหรือเปล่า หากมี ก่อนจะตั้งคำถาม ก็ขอให้ลองค้นหา โดยใช้คำในการหา สักสองสามคำ ที่เกี่ยวกับปัญหาของท่าน อาจจะท่านช่วยได้ หรืออาจจะไปหาในเว็บทั่วไปก่อน (ซึ่งท่านควรจะทำก่อนหน้าจะเข้ามาถามในเว็บเฉพาะเจาะจงสำหรับปัญหาที่ท่านกำลังเจออยู่) หากท่านไปหาในเว็บทั่วไปแล้วไม่สามารถแก้ปัญหาได้ ก็ให้ค้นในเว็บเฉพาะเลย เพราะ การไปหาในเว็บทั่วไปอาจจะยังไม่มี ข้อมูลที่เพิ่งเอาเข้ามาเพิ่มในกระดานเว็บที่เฉพาะเจาะจงสำหรับปัญหาของท่าน

มีความโน้มเอียงที่ โครงการ (โปรแกรมที่ท่านใช้) จะมีการช่วยเหลือผู้ใช้โดยผ่านทาง กระดานเว็บ หรือ IRC channel ส่วนอีเมลนั้นจะสงวนสำหรับกลุ่มนักพัฒนาโครงการนี้เท่านั้น ฉะนั้นขอให้ใช้ กระดานเว็บ หรือ IRC channel เมื่อต้องการความช่วยเหลือ

ใช้กลุ่มเมลของโครงการนั้นๆ

หากโครงการนั้นมีกลุ่มจดหมายสำหรับการพัฒนาโครงการ ให้เขียนจดหมายถึงกลุ่มจดหมายนั้น ไม่ใช่กับคนใดคนหนึ่ง แม้คุณจะคิดว่าคุณรู้ว่าใครจะตอบคำถามได้ดีที่สุด ให้ตรวจสอบเอกสารของโครงการ และเว็บไซด์ เพื่อหาที่อยู่ของกลุ่มจดหมาย นโยบายนี้มีเหตุผลสนับสนุนหลายประการ

  • คำถามที่ดีสำหรับผู้พัฒนาคนใดคนหนึ่งก็เป็นสิ่งที่มีค่าสำหรับทั้งกลุ่ม ในทางตรงข้าม หากคุณคิดว่าคำถามของคุณงี่เง่าเกินกว่าจะถามทั้งกลุ่ม ก็ไม่ได้หมายความว่าคุณมีสิทธิจะไปเซ้าซี้นักพัฒนาคนใดคนหนึ่ง
  • การถามในกลุ่มจะช่วยกระจายงาน เพราะนักพัฒนาแต่ละคน (โดยเฉพาะหัวหน้าโครงการ) อาจยุ่งเกินกว่าจะช่วยตอบคำถามคุณ
  • กลุ่มจดหมายนี้จะมีการบันทึกเก็บไว้ และบันทึกเหล่านี้จะถูกจัดเก็บดัชนีค้นหาโดยเครื่องมือช่วยหา หากคุณถามคำถามบนกลุ่มและได้รับคำถาม ผู้ถามคนต่อๆ ไปจะสามารถค้นหาคำถามและคำตอบจากอินเตอร์เน็ตได้ แทนที่จะต้องมาถามกับอีกรอบ
  • หากมีคำถามใดที่ถูกถามบ่อย ผู้พัฒนาสามารถใช้ข้อมูลเหล่านี้ในการปรับปรุงระบบคู่มือหรือแม้แต่โปรแกรมให้ใช้ง่ายขึ้น แต่หากคำถามเหล่านั้นถูกถามเป็นการส่วนตัว ย่อมไม่มีใครเข้าใจได้ว่าคำถามใดถูกถามบ่อย

หากในโครงการนั้นมีกลุ่มจดหมายหรือกระดานข่าวทั้ง "ผู้ใช้" และ "ผู้พัฒนา" หรือ "แฮ็กเกอร์" และคุณไม่ได้ทำการปรับแต่งโค้ด ให้ถามในกลุ่ม "ผู้ใช้" อย่าคิดว่าคุณจะได้รับการตอบรับในกลุ่มผู้พัฒนา เพราะพวกเขาจะเห็นคุณเป็นแค่สิ่งรบกวนในงาน

อย่างไรก็ตาม หากคุณมั่นใจว่าคำถามของคุณไม่ใช่เรื่องธรรมดา และไม่ได้รับคำตอบจากกลุ่ม "ผู้ใช้" เป็นเวลาหลายวัน ให้ลองถามกลุ่ม "ผู้พัฒนา" เราขอแนะนำให้คุณเข้าไปดูลาดเลาสักสองสามวันก่อนโพสต์ เพื่อเรียนรู้กฎติกามารยาทก่อน (ที่จริงคำแนะนำนี้เหมาะกับกลุ่มที่เป็นส่วนตัวหรือกึ่งส่วนตัวทุกแบบ)

หากคุณหากลุ่มจดหมายไม่พบ พบแต่ที่อยู่ของผู้ดูแลโครงการ ก็ให้เขียนจดหมายถึงผู้ดูแล ในกรณีเช่นนี้อย่าคิดเอาเองว่าไม่มีกลุ่มจดหมาย ให้เขียนไว้ในจดหมายว่าคุณได้พยายามหากลุ่มจดหมาย แต่หาไม่เจอ และให้บอกด้วยว่าคุณไม่ว่าอะไรหากจดหมายของคุณจะถูกส่งผ่านไปยังคนอื่น (หลายคนเชื่อว่าจดหมายส่วนตัว ควรจะเป็นของส่วนตัว แม้ว่าจะไม่มีความลับอะไร การอนุญาตให้ส่งผ่านจดหมายทำให้ผู้ตอบมีทางเลือกในการจัดการจดหมายของคุณเพิ่ม)

ตั้งหัวข้อให้สื่อและชัดเจน

ในกลุ่มจดหมาย กลุ่มข่าว หรือกระดานสนทนา หัวข่าวนั้นเป็นโอกาสทองในการดึงดูดความสนใจของผู้มีฝีมือ ภายใน 50 ตัวอักษร อย่าไปเสียเวลากับคำไร้สาระอย่าง "ช่วยด้วย" (โดยเฉพาะถ้าจะเน้นตัวพิมพ์ใหญ่ทั้งหมด เพราะข้อความพวกนี้จะถูกโยนลงถังขยะโดยอัตโนมัติ) ไม่ต้องแสดงให้เห็นว่าคุณกำลังทนทุกข์ทรมานแค่ไหน ให้บอกปัญหาด้วยข้อความที่กระชับที่สุด

รูปแบบหัวข้อยอดนิยม ที่ใช้ในองค์กรที่ทำงานด้านการสนับสนุนด้านเทคนิคคือ "วัตถุประสงค์ - ข้อผิดพลาด" โดย ส่วน "วัตถุประสงค์" นั้นจะบอกถึงสิ่งที่เป็นปัญหา ส่วน "ข้อผิดพลาด" นั้นจะอธิบายผลลัพธ์ที่แตกต่างไปจากผลลัพธ์ที่เราคาดคะเนไว้

หัวข้อแบบไม่สร้างสรรค์

"ช่วยด้วย แล็ปท็อปผมดูวิดีโอไม่ได้"

หัวข้อสร้างสรรค์

X.org 6.8.1 ทำให้เคเซอร์เมาส์ทำงานผิดปกติ, Fooware MV1005 vid. chipset

หัวข้อที่สร้างสรรค์กว่า

X.org 6.8.1 เคอร์เซอร์เมาส์บน Fooware MV1005 vid. chipset - ทำงานผิดปกติ

กระบวนการเขียน "วัตถุประสงค์ - ข้อผิดพลาด" จะช่วยคุณในการระดมความคิดเกี่ยวกับรายละเอียดของข้อผิดพลาด เกิดอะไรขึ้น? เฉพาะเคอร์เซอร์เมาส์หรือรูปอื่นด้วย? เป็นปัญหาใน X.org เวอร์ชั่นเฉพาะหรือเปล่า? หรือถึง 6.8.1? เป็นเฉพาะชิพของ Fooware? เฉพาะโมเดล MV1005? แฮ็กเกอร์ที่เห็นผลลัพธ์จะเข้าใจได้ในทันทีว่า คุณกำลังมีปัญหาอะไร และ ปัญหาเป็นอย่างไร

โดยทั่วไป ให้ลองจินตนาการว่า เรากำลังมองดัชนีของบันทึกคำถามเก่าๆ โดยเห็นเฉพาะหัวข้อ ให้หัวข้อของคุณสะท้อนคำถามขนาดว่าคนอื่นที่กำลังค้นบันทึกเกี่ยวกับคำถามที่คล้ายกันนั้น สามารถอ่านกระทู้เพื่อหาคำตอบได้ แทนที่จะต้องโพสต์ถามใหม่

หากคุณถามคำถามในช่องตอบ ให้เปลี่ยนหัวข้อเพื่อแสดงว่าคุณกำลังถามคำถาม หัวข้ออย่าง "Re: test" หรือ "Re: new bug" นั้นจะไม่ได้รับความสนใจมาก และอย่าลืมติดคำพูดของข้อความเก่ามาให้น้อยที่สุด เท่าที่คนอ่านใหม่จะอ่านได้โดยเข้าใจ

อย่ากด reply เพื่อสร้างกระทู้ใหม่ เพราะวิธีนี้จะจำกัดคนที่ได้รับ โปรแกรมเมลเช่น mutt จะให้ผู้ใช้จัดลำดับกระทู้ และซ่อนข้อความที่อยู่นกระทู้ไว้ในแฟ้ม คนที่ตั้งค่าไว้แบบนี้จะไม่มีวันเห็นข้อความของคุณเลย

แค่เปลี่ยนหัวข้อนั้นไม่เพียงพอ โปรแกรมอย่าง Mutt หรือโปรแกรมอื่น นั้นจะมองหาข้อมูลในหัวข้อเมล เพื่อจัดในกระทู้ ไม่ใช่มองหาจากหัวกระทู้ ดังนั้นจึงควรเขียนเมลใหม่ทั้งหมด

บนกระดานข่าวนั้น มีวิธีการปฏิบัติที่ถูกต้องต่างกันไปแต่ละกระดาน เพราะข้อความนั้นมักจะขึ้นกับกระทู้ และจะมองจากนอกกระทู้ไม่เห็น การเปลี่ยนหัวข้อเวลาตั้งคำถามด้วยการกดตอบนั้นไม่จำเป็น กระดานข่าวหลายแห่งไม่อนุญาตให้เขียนหัวใหม่เวลากดตอบ และไม่มีใครสนใจจะอ่านหัวพวกนั้นด้วยซ้ำ อย่างไรก็ตาม การถามคำถามโดยการกดตอบนั้นก็เป็นวิธีการที่ไม่ค่อยโสภา เพราะคำถามนี้จะถูกเห็นเฉพาะคนที่อ่านกระทู้เท่านั้น ดังนั้น เว้นแต่ว่าคุณมั่นใจว่าคุณ อยาก จะถามเฉพาะคนในกระทู้นี้ ก็ขอให้ตั้งกระทู้ใหม่

ตั้งค่าให้ตอบกลับง่ายๆ

การลงท้ายประโยคว่า "โปรดส่งคำตอบมาที่..." จะทำให้คุณมีโอกาสไม่ได้รับคำตอบสูง หากคุณยังไม่ยอมจะเสียเวลานิดหน่อยในการตั้งค่า Reply-To ในเมลของคุณ เราก็ไม่อยากจะเสียเวลากับปัญหาคุณเหมือนกัน หากโปรแกรมเมลของคุณไม่ยอมให้ตั้งค่านี้ http://linuxmafia.com/faq/Mail/muas.html ก็ใช้โปรแกรมที่มันดีกว่านี้ซะ หากระบบปฏิบัติการของคุณไม่สนับสนุนโปรแกรมอีเมลแบบนี้ ก็เปลี่ยนระบบปฏิบัติการให้ดีกว่านี้ซะ

ในฟอรั่ม การขอคำตอบผ่านอีเมล นั้นถือว่าหยาบคาย เว้นแต่คุณเชื่อว่าข้อมูลนี้เป็นข้อมูลไม่ควรเปิดเผย (และบางคนก็จะยอมบอกคุณ แต่ไม่บอกฟอรัม ไม่รู้ว่าเพราะอะไรเหมือนกัน) หากคุณต้องการสำเนาคำตอบผ่านอีเมล ให้ขอให้ฟอรัมส่งให้ ฟอรัมส่วนใหญ่มีคุณสมบัตินี้ด้วยตัวเลือกอย่าง "เฝ้ามองกระทู้นี้" , "เมล คำตอบ", ฯลฯ

เขียนให้ถูกต้องตามหลักภาษา

จากประสบการณ์ เราพบว่าคนที่เขียนแบบสะเพร่าหรือทำอะไรแบบลวกๆ ก็มันจะเป็นคนที่คิดหรือเขียนโปรแกรมแบบเดียวกัน (พนันกันได้เลย) ดังนั้นการตอบคำถามของคนที่คิดหรือทำแบบสะเพร่าหรือลวกๆ นี้มันไม่ค่อยจะเป็นประสบการณ์ที่ดี เราอยากเอาเวลาไปใช้ทำอย่างอื่นดีกว่า

ฉะนั้น เวลาตั้งคำถามขอให้เขียนให้ชัดเจน ถูกต้องเรียบร้อย หากคุณไม่อยากเสียเวลาทำ เราก็ไม่อยากเสียเวลาตอบ ขอให้ใช้เวลาเกลาภาษาให้ถูกต้อง ไม่จำเป็นต้องเป็นแบบราชการเต็มที่ เพราะในสังคมของพวก แฮ็กเกอร์ นั้นเราชอบอะไรที่ไม่เป็นทางการ รวมทั้งภาษาแสลงและตลก แต่จะต้องใช้ อย่างถูกต้อง เพราะมันจะบ่งว่าคุณได้ใช้ความตั้งใจและไตร่ตรองในการเขียนคำถามนี้

พยายามใข้ คำสะกด วรรคตอน และตัวพิมพ์ใหญ่ ให้ถูกต้อง อย่าสับสนคำว่า its กับ it's หรือคำว่า loose กับ lose หรือ คำว่า discrete กับ discreet อย่าใช้ตัวพิมพ์ใหญ่ทั้งคำ เพราะมันหมายถึงการตะโกนซึ่งถือว่าไม่สุภาพ (การใช้ตัวพิมพ์เล็กทั้งหมด ก็น่ารำคาญไม่แพ้กันเพราะทำให้อ่านยาก ยกให้แต่ Alan Cox เท่านั้น)

โดยทั่วไป หากคุณเขียนคำถามที่ดูแล้วเหมือนคนไม่ค่อยมีการศึกษา คำถามของคุณมักจะไม่ได้รับการสนใจ ฉะนั้นอย่าใช้คำย่อสั้นๆ แบบที่ใช้ใน instant message สะกดให้ครบคำ การเขียน "you" ว่า "u" เพียงเพื่อประหยัดการกดแป้นไปสองตัว จะทำให้คุณดูเหมือนคนโง่ที่เขียนหนังสือไม่เป็น นอกจากนี้ไอ้การเขียนแบบ "a l33t script kiddie haxOr" รับรองว่าแบบนี้ก็ดับสนิท (ดีไม่ดี อาจจะได้แต่คนเขาประชด หรือด่าเอา)

หากคุณถามคำถามในกระดานซึ่งไม่ใข่ภาษาพ่อภาษาแม่ เราอาจจะยอมหยวนให้ท่านบ้างในกรณีที่สะกดผิดหรือเขียนผิดไวยากรณ์ แต่ไม่ได้หมายความว่าเราจะยอมทนกับความขี้เกียจ (บอกไว้ก่อนเลยว่า พวกเรามองออกนะ) หากไม่ทราบว่าผู้ตอบจะใช้ภาษาอะไร ก็ขอให้เขียนภาษาอังกฤษ ทั้งนี้เป็นเพราะแฮ็กเกอร์ที่ยุ่งมากๆ จะโยนคำถามทิ้งหากเขียนด้วยภาษาที่เขาไม่เข้าใจ แต่ภาษาอังกฤษเป็นภาษาที่ใช้ในอินเตอร์เน็ต ฉนั้นการใช้ภาษาอังกฤษเป็นการเพิ่มโอกาสที่ท่านจะได้คำตอบที่ท่านถามไป

เขียนคำถามในรูปแบบที่เป็นมาตรฐาน

หากคุณเขียนคำถามที่อ่านเข้าใจยาก ก็มีโอกาสที่จะไม่ได้รับคำตอบสูงกว่าคำถามที่เข้าใจง่าย ดังนั้น

  • เขียนเมลด้วยรูปแบบธรรมดา ไม่ใช่ HTML (ไม่ยากหรอก turn off HTML)
  • การแนบ MIME ไปด้่วยพอรับได้ ก็ต่อเมื่อมีเนื้อหาในนั้นเท่านั้น (เช่นซอร์สไฟล์หรือแพทช์) ไม่ใช่พวกของไร้สาระที่เมลคุณสร้างขึ้น (เช่นสำเนาข้อความอีกอัน)
  • อย่าส่งเมล ที่เขียนด้วยย่อหน้าเดียว (เพราะทำให้การตอบเฉพาะส่วนเป็นไปได้ยาก) ให้สมมตว่าผู้ตอบจะอ่านเมล ด้วนหน้าจอที่กว้างน้อยกว่า 80 ตัวอักษร และตั้งค่าการตัดตัวอักษรตามนี้ คือน้อยกว่า 80 ตัวอักษร
  • อย่าส่งอักษรแบบ MIME Quoted-Printable ไปยังฟอรั่มภาษาอังกฤษ ระบบนี้จำเป็นเมื่อคุณต้องโพสต์ข้อความในภาษาที่ไม่ได้ครอบคลุมในรหัส ASCII แต่ระบบเมลหลายแห่งไม่ได้ครอบคลุมระบบนี้ และเมื่อมีการแบ่ง พวก =20 ตัวอักษรนั้นดูน่าเกลียดและทำลายสมาธิ และอาจทำลายความสำคัญของเนื้อหาของคุณ
  • อย่า หวัง ว่าแฮ็กเกอร์จะอ่านเอกสารในระบบปิดอย่า่งเวิร์ดหรือเอ็กเซล แฮ็กเกอร์ส่วนใหญ่จะมีปฏิกริยาต่อเรื่องนี้เหมือนกับคุณจะมีปฏิกริยาหากใครเอาขี้หมูมากองไว้หน้าบ้าน แม้พวกเขาทนได้ แต่ก็เกลียดเข้าไส้
  • หากคุณส่งเมลจากระบบวินโดว์ ให้ปิดระบบ "Smart Quotes" ซะ จะได้ไม่มีตัวอักษรแปลกๆ ติดไปในเมล
  • ในฟอรั่ม อย่าไปใช้ "smiley" กับ "HTML" ให้มากนัก (ถ้าเว็บมีระบบนี้) smiley นิดหน่อยยังพอรับได้ แต่พวกตัวอักษรหลากสีมักทำให้คนคิดว่าคุณน่ะมันห่วย การใข้พวก smiley กับอักษรสารพัดสีมากเกินไปทำให้คุณดูเหมือนพวกผู้หญิงวัยรุ่นไร้สมอง ซึ่งก็คงไม่ใช่ความคิดที่ดีเท่าไร เว้นแต่คุณจะมองหาเซ็กส์มากกว่าคำตอบนะ

หากคุณใช้ระบบเมลที่มีกราฟฟิก อย่าง Netscape Messenger, MS Outlook หรืออะไรที่คล้ายๆ กัน ขอให้ระวังว่าการตั้งค่าดั้งเดิมนั้นอาจละเมิดข้อห้ามที่กล่าวไปแล้ว โปรแกรมเหล่านี้มักมีตัวเลือก "View Source" ให้ใช้ตัวเลือกนี้กับแฟ้มเมลที่ส่งออกไป เพื่อดูว่าส่งไปเฉพาะตัวอักษรล้วน โดยไม่ต้องมีสิ่งไม่พึงประสงค์ติดไปด้วย

ให้ข้อมูลครบถ้วนแม่นยำ

  • อธิบายอาการของปัญหาหรือ bug ให้ถูกต้องและชัดแจ้ง
  • เล่าถึงสภาพ และสิ่งแวดล้อมขณะที่คุณเจอปัญหา (ยกตัวอย่าง เครื่อง ระบบปฎิบัติการ โปรแกรมตัวเจ้าปัญหา หรืออะไรก็ตาม) ให้บอกว่า ใครเป็นคนแจกจ่ายโปรแกรม หรือ รุ่นใหน (เช่น "Fedora Core 4" "Slackware 9.1")
  • พยายามอธิบายก่อนว่า ได้ไปค้นคว้าหรือพยายามเข้าใจปัญหาอย่างไรมาบ้าง
  • พยายามอธิบายขั้นตอนที่คุณได้ทำในช่วงที่พยายามจะแก้ปัญหาด้วยตัวเอง
  • ขอให้เล่าว่าคุณได้ทำการเปลี่ยนแปลงค่าของโปรแกรม (หรือตัวติดตั้งโปรแกรม หรือ configuration) หรือตัวเครื่องอย่างไรบ้าง

ขอให้เตรียมตัวตอบให้ดี หากพวกแฮ็กเกอร์ จะมีคำถามต่อมาอีกกับปัญหาของคุณ หรืออาจจะตอบล่วงหน้าไปก่อนในคำถามที่คุณถามไป (ตอบดักหน้าไปก่อน)

เราขอแนะนำบทความที่ดีมาก เรื่องหนึ่ง ชื่อ วิธีการแจ้งรายงานเรื่อง Bugs ที่ถูกต้อง ซึ่งเขียนโดย Simon Tatham

ปริมาณไม่ใช่ความแม่นยำ

ขอให้เตรียมคำถามให้มีขัอมูลครบและถูกต้อง แต่ไม่ใช่ว่าเอาโปรแกรมมาลงเป็นร้อยๆบรรทัด มาแปะในคำถาม ถ้าท่านมีปัญหาที่เกิดจากโปรแกรมที่ใหญ่และยุ่ง พยายามตัดให้มันเล็กเท่าที่ทำได้ เพราะการเขียนมากก็ไม่ได้แปลว่าจะครบถ้วน

การทำตามคำแนะนำตามที่ว่ามาข้างบนนี้จะมีผลสามอย่างคือ หนึ่ง เป็นการแสดงว่าคุณได้พยายามทำให้คำถามมันอ่านง่ายขึ้น ซึ่งจะทำให้ท่านอาจจะมีโอกาสได้คำตอบมากขึ้นจากผู้ตอบ สอง การพยายามตั้งคำถามให้ง่ายขึ้น มีโอกาสที่ท่านจะได้คำตอบที มีประโยชน์ มากขึ้น สาม ในระหว่างที่คุณพยายามปรับแต่งคำถามของคุณ คุณอาจจะเจอวิธีการแก้ปัญหานี้หรือทางออกแบบอื่นที่แก้ปัญหาอันเดียวกันนี้ก็ได้

อย่าบอกว่าคุณเป็นคนพบบั๊ก

หากคุณมีปัญหากับโปรแกรม อย่าพูดว่าคุณพบบั๊ก นอกเสียจากว่าคุณมั่นใจ มากๆ ข้อเสนอแนะคือ นอกเสียจากว่าคุณสามารถแสดง source-code patch ที่จะแก้ไขปัญหาได้ หรือการทดสอบ regression กับเวอร์ชั่นเก่าที่แสดงให้เห็นว่าโปรแกรมมีพฤติกรรมที่ไม่ถูกต้อง คุณไม่มีทางจะมั่นใจได้หรอก กรณีนี้ก็รวมถึงเว็บไซต์และเอกสารด้วย หากคุณพบ "บั๊ก" ของเอกสาร คุณควรจะแนบเอกสารแก้ไข และบอกด้วยว่าควรจะไปอยู่ที่ไหน

จำไว้ว่า มีอีกหลายคนที่ไม่มีปัญหาอย่างคุณ ไม่อย่างนั้นแล้วคุณก็น่าจะเจอเรื่องนี้ระหว่างอ่านคู่มือ หรือค้นหาทางอินเตอร์เน็ตแล้ว (คุณได้ทำก่อนจะบ่นแล้ว ใช่หรือไม่) ซึ่งนั่นย่อมหมายความว่าคุณนั่นล่ะที่ทำอะไรผิด ไม่ใช่โปรแกรมทำ

คนที่พัฒนาโปรแกรมนั้นได้ทำงานอย่างหนักเพื่อให้โปรแกรมทำงานได้ดีที่สุด หากคุณอ้างว่าคุณเจอบั๊ก คุณกำลังดูแคลนความสามารถของพวกเขา ซึ่งก็ทำให้หลายคนโกรธได้ แม้ว่าคุณจะเป็นฝ่ายถูกก็ตาม มันไม่ถูกมารยาทอย่างยิ่งที่จะใช้คำว่า "บั๊ก" ในหัวข้อ

เวลาถามคำถาม คุณควรจะเขียนในลักษณะที่ว่า คุณ กำลังทำอะไรผิด แม้โดยส่วนตัวคุณจะเชื่อว่าคุณพบบั๊กก็เถอะ หากมันเป็นบั๊กจริง คุณจะเจอมันในคำตอบเอง วางตัวให้คนทำซอฟต์แวร์ขอโทษคุณหากมีบั๊กจริง แทนที่ว่าคุณต้องไปขอโทษเขาหากคุณทำพลาด

อย่าประจบประแจง

บางคนคิดว่าไม่ควรทำตัวหยาบคายหรือโอหัง และเรียกร้องคำตอบ แต่จะทำตัวแบบประจบหรือแบบถล่มตัว เช่นเขียนว่า "ผมเป็นผู้ใช้ใหม่อันแสนต่ำต้อย แต่.... " การเขียนแบบนี้เป็นการทำให้เบี่ยงประเด็นออกจากปัญหาของท่าน ยิ่งทำให้น่ารำคาญมากกว่า โดยเฉพาะเมื่อคำถามไม่ชัดเจน

อย่าเสียเวลาของเราๆ ท่านๆ กับการเล่นการเมืองบนกระดาน ขอให้ใช้เวลากับการเสนอข้อมูลและปัญหาของท่านให้ชัดเจนให้มากที่สุด วิธีนี้จะทำให้ปัญหาของท่านได้รับการพิจารณามากกว่าจะมามัวทำ "ถล่มตัว"

ในกระดานของเว็บบางแห่ง เขาอาจจะมีกระดานสำหรับน้องใหม่ ขอให้ไปที่นั่น และไม่ต้องไป "ถล่มตัว" ที่นั่นด้วย

อย่าเดาอาการ

ไม่มีประโยชน์ที่จะบอกแฮ็กเกอร์ว่า คุณคิดว่าปัญหาคุณเกิดจากอะไร (หากคุณวิเคราะห์อาการได้เก่ง, ทำไมต้องขอความช่วยเหลือจากคนอื่น?) ดังนั้นให้คุณบอกอาการที่เกิดข้อผิดพลาด แทนที่จะบอกว่าคุณมีทฤษฎีอะไร ให้พวกเขาเป็นคนวิเคราะห์อาการ หากคุณคิดว่าคุณจำเป็นต้องบอกการคาดเดา ขอให้บอกอย่างชัดเจน และบอกว่าทำไมคำตอบนี้ไม่ได้ผล

คำถามแบบไม่สร้างสรรค์

ผมเจอ SIG11 errors ตอนพยายามคอมไพล์ เคอร์เนล และสงสัยว่ามีรอยแตกบนมาเธอร์บอร์ด ผมจะเช็คได้ยังไง?

คำถามสร้างสรรค์

เครื่องประกอบเองของผมที่ใช้ชิพ K6/223 บนบอร์ด FIC-PA2007 (ชิพ VIA Apollo VP2) และมี SDRAM 256MB PC133 ของ Corsair เริ่มมีปัญหา SIG11 error ทุก 20 นาทีหลังจากเปิดเครื่อง ระหว่างกำลังคอมไพล์ เคอร์เนล แต่ไม่เกิดขึ้นตอน 20 นาทีแรก เมื่อรีบูตเครื่องใหม่ นาฬิกาเดินต่อตามปกติ แต่ถ้าปิดเครื่องข้ามคืนนาฬิกาจะรีเซ็ต ผมได้สลับ RAM ทุกแถวแล้วแต่ไม่ได้ผล log ของส่วนที่เกี่ยวข้องมีดังนี้

เพราะประเด็นนี้จะเป็นเรื่องที่เข้าใจได้ยาก ผมก็ขอใช้ประโยคหนึ่งเพื่อทำความเข้าใจ "นักตรวจอาการทั้งหมดจะมาจากรัฐมิสซูรี่ และรัฐนี้มีคำขวัญว่า "เอามาดูซิ" (เกิดในปี 1899 เมื่อสส. วิลลาร์ด ดี แวนไดเวอร์ ได้กล่าวว่า "ข้าพเจ้ามาจากประเทศที่สร้างข้าวโพด สำลี ต้น cocklebur และพวกเดโมแครต, แค่คำพูดน่ะไม่สามารถกล่อมข้าพเจ้า หรือทำให้ข้าพเจ้าพอใจได้ ข้าพเจ้ามาจากมิสซูรี่ ท่านต้องเอามาแสดงให้ข้าพเจ้าดู")" ในกรณีของนักตรวจอาการนี้ ไม่ใช่ว่าพวกเขาไม่เชื่อมั่น แต่เขามีความจำเป็นที่ต้องเห็นหลักฐานให้เหมือนกับที่คุณเห็น ไม่ใช่สิ่งที่คุณคิดและสรุป ดังนั้นเอามาให้เราดู

เล่าอาการตามลำดับเวลา

เบาะแสที่มีประโยชน์ในการตรวจความผิดพลาด มักเป็นเหตุการณ์ที่อยู่ก่อนหน้า ดังนั้นคุณต้องบอกอย่างละเอียดว่าคุณทำอะไร เครื่องเกิดอะไร ถึงทำให้เครื่องเจ๊ง ในกรณีของการใส่คำสั่ง ให้ดึง log (ใช้โปรแกรม script) และลอกบรรทัดที่เกี่ยวข้องสักยี่สิบบรรทัดมา จะช่วยได้มาก

หากโปรแกรมที่เจ๊งมีตัวตรวจอาการ (เช่น -v ของ verbose) ลองใช้วิธีนี้ตรวจดู จะได้ข้อมูลที่มีประโยชน์เพิ่มเติม จำไว้ว่ามากเกินไปก็ไม่ดี พยายามเลือกสิ่งที่ให้ข้อมูล มากกว่าที่จะเอาข้อมูลที่ไม่เกี่ยวข้องมากๆ มาให้คนอ่านปวดหัว

หากข้อมูลคุณนั้นยาว (มากกว่าสี่ย่อหน้า) อาจมีประโยชน์กว่าที่จะบอกปัญหาก่อน แล้วค่อยลำดับเหตุการณ์ วิธีนี้แฮ็กเกอร์จะรู้ว่าต้องมองหาอะไรในข้อมูล

ให้บอกเป้าหมาย ไม่ใช่ขั้นตอน

หากคุณต้องการความช่วยเหลือเพื่อให้แก้ปัญหา (ไม่ใช่รายงานบั๊ก) ให้เริ่มว่าจุดประสงค์ของคุณคืออะไร แล้วถึงค่อยอธิบายลำดับขั้นตอนที่นำไปยังปัญหา

โดยปกติแล้วคนที่เข้ามาถามปัญหาทางเทคนิค เขามันจะมีเป้าหมายที่สูง แล้วเกิดไปติดปัญหาในระหว่างที่กระทำกระบวนการเพื่อบรรลุเป้าหมาย เขามาถามหาความช่วยเหลือ โดยที่ไม่ทราบว่า วิธีการแก้ของตนเองนั้นไม่ถูก ซึ่งต้องใช้ความพยายามอย่างมากที่จะแก้ไขแนวคิดนี้

คำถามไม่สร้างสรรค์:

จะทำยังไงถึงเลือกสี ในโปรแกรมที่ชือ FooDraw โดยที่ให้รับค่าที่เป็นฐานสิบหกให้ได้

คำถามสร้างสรรค์:

ผมพยายามจะเข้าไปเปลี่ยนค่าของตารางสี ในรูป ด้วยค่าที่ผมได้เลือก ตอนนี้ผมคิดว่าการเปลี่นต้องเข้าไปปรับช่องในตารางตาราง แต่ ไม่สามารถทำให้โปรแกรม FooDraw รับค่าที่เป็นฐานสิบหกได้

คำถามแบบที่สองเป็นการถามที่ดี เพราะคนตอบสามารถแนะวิธีหรือเครื่องมืออื่นที่เหมาะกับงาน

อย่าถามแล้วทิ้งอีเมลไว้

แฮ็กเกอร์เชื่อว่ากระบวนการแก้ไขปัญหาควรจะเป็นกระบวนการสาธารณะและโปร่งใส ซึ่งคำตอบแรกนั้นสามารถ (และควรจะ) ถูกแก้ไขหากผู้ที่มีความรู้ดีกว่า พบว่าคำตอบนี้ไม่สมบูรณ์หรือไม่ถูกต้อง นอกจากนี้ผู้ที่ช่วยเหลือจะได้รับการตอบแทนจากการตอบคำถาม โดยการยอมรับจากคนในกลุ่มว่า เป็นผู้มีความรู้และความสามารถ

หากคุณขอคำตอบเป็นการส่วนตัว คุณกำลังขัดขวางกระบวนการและการตอบแทนดังกล่าว ดังนั้นจงอย่าทำ ผู้ตอบเป็นผู้มีสิทธิจะเลือกว่าจะตอบเป็นการส่วนตัวหรือไม่ และหากเขาเลือกตอบแบบส่วนตัว ก็เนื่องจากว่าเขาคิดว่าคำถามนี้มีรูปแบบไม่ดี หรือง่ายเกินกว่าจะน่าสนใจสำหรับคนอื่น

มีข้อยกเว้นอยู่ประการหนึ่ง หากคุณคิดว่าคุณจะได้รับคำตอบจำนวนมากที่คล้ายกัน คุณสามารถเติมคำว่า "โปรดเมลมา แล้วผมจะสรุปคำตอบให้สำหรับทั้งกลุ่ม" มันเป็นการดีที่จะช่วยกลุ่มให้ไม่ต้องรับข้อความที่เหมือนกันจำนวนมาก แต่แน่นอนว่าคุณต้องทำตามที่บอกไว้และทำสรุปให้

ตั้งคำถามให้ชัดเจน

คำถามแบบกว้างๆ มักจะถูกมองว่าเป็นคำถามที่กินเวลาไม่สิ้นสุด คนที่จะช่วยตอบคุณได้ดีมักจะเป็นคนที่ยุ่งที่สุด (แม้เพราะว่าพวกเขาชอบจะทำงานทุกอย่างด้วยตัวเองก็เถอะ) คนพวกนี้เกลียดการกินเวลาไม่สิ้นสุด ดังนั้นพวกเขาก็พลอยเกลียดคำถามแบบกว้างๆ ไปด้วย

คุณจะได้คำตอบที่มีประโยชน์หากคุณตั้งคำถามอย่างชัดเจน ว่าคุณต้องการให้ผู้ตอบทำอะไร (ให้แนวทาง, ขอโค้ด, ตรวจแพทช์, ฯลฯ) วิธีนี้ทำให้พวกเขาสามารถใช้ความพยายามได้ถูกที่ และช่วยประหยัดเวลาและพลังงานให้ผู้ตอบ ซึ่งก็เป็นสิ่งที่ดี

เพื่อให้เข้าใจโลกของพวกเซียน ให้คิดว่าฝีมือเป็นทรัพยากรที่มีเหลือล้น ขณะที่เวลาที่จะช่วยตอบนั้นเป็นทรัพยากรหายาก ยิ่งคุณขอใช้เวลาน้อยเท่าใด คุณก็ยิ่งมีโอกาสจะได้รับคำตอบจากคนที่ยิ่งเก่งและยุ่งมากขึ้นเท่านั้น

ดังนั้นการตั้งกรอบคำถามจึงมีประโยชน์ ในการลดเวลาที่ต้องใช้ แต่นี่ไม่ได้หมายความว่าจะต้องตั้งคำถามง่ายๆ ตัวอย่างเช่น "คุณช่วยชี้ไปหาคำอธิบายในการทำ ก ได้ไหม?" เป็นคำถามที่ฉลาดกว่า "ช่วยอธิบายการทำ ก ได้ไหมคะ (ครับ)?" หากคุณมีโค้ดที่ใช้การไม่ได้ คุณควรตั้งคำถามให้คนช่วยอธิบายข้อผิดพลาด มากกว่าจะขอให้คนอื่นช่วยแก้ให้

เมื่อถามเรื่องการเขียนโปรแกรม

เวลาขอให้คนอื่นแก้ปัญหาในโปรแกรมของคุณ ขอให้บอกว่ามีปัญหาอะไร การเอา โปรแกรมของท่านมาลงเป็นร้อยๆบรรทัดแล้วบอกว่า "มันไม่ทำงาน" แค่นี้คงจะไม่มีใครสนใจจะเข้ามาช่วย แต่การเอาโปรแกรมมาลง แล้วบอกว่า บรรทัดที่ 7 คิดว่าน่าจะได้ <ก> แต่กลับได้ <ข> เช่นนี้ น่าจะได้คำตอบจากผู้อ่านมากกว่า

หากคุณต้องการแค่ให้ผู้อื่นตรวจวิจารณ์โปรแกรมของคุณ ก็ขอให้บอกตรงๆเลย และให้บอกว่าทำไมคุณถึงต้องการการตรวจวิจารณ์ และต้องการให้ตรวจวิจารณ์ด้านใดเป็นพิเศษ

อย่าเอาการบ้านมาถาม

แฮ็กเกอร์มักจะรู้ว่าคำถามแบบนี้เป็นการบ้านหรือไม่ เพราะเขาเหล่านี้เคยทำมาแล้วทั้งนั้น การบ้านน่ะมีไว้ให้ คุณ หัดทำ เพื่อจะได้เรียนรู้ หากจะขอคำชี้แนะในการแก้ปัญหาก็ไม่ผิดอะไร แต่ไม่ใช่ว่าจะมาให้เฉลยคำตอบทั้งหมด

หากคุณสงสัยว่า คำถามที่คนอื่นถามท่านนั้นเป็นการบ้าน แต่แก้ปัญหาด้วยตนเองไม่ได้ ก็ขอให้ไปลองถามในกระดานกลุ่มผู้ใช้ หรือ (เอาเป็นแหล่งสุดท้าย) กระดานสนทนาหรือกลุ่มของผู้ใช้ของโครงการนั้น หากพวกแฮ็กเกอร์ไปเจอเข้า เขาอาจจะให้เคล็ดในการแก้ปัญหาก็ได้

งดคำถามที่ไร้จุดหมาย

พยายามเลี่ยงหรือจบคำถามของคุณด้วยคำถามที่ไม่ได้บ่งอะไรเลย เช่น "ใครจะช่วยได้บ้าง" หรือ "ใครมีคำตอบบ้าง" เพราะ ประการแรก หากคุณพยายามอธิบายปัญหามาชนิดรู้เรื่องแบบครึ่งๆ กลางๆ แล้วมาจบด้วยประโยคข้างบน จะทำให้ฟุ่มเฟือยโดยไม่จำเป็น ประการต่อมา พวกแฮ็กเกอร์มักหงุดหงิดรำคาญกับเรื่องนี้ และอาจจะตอบกลับมาแบบตรงคำถามแต่ไม่แก้ปัญหา เช่น "แน่นอน มีคนช่วยคุณได้แน่" หรือ "เสียใจด้วย ไม่มีใครตอบหรือช่วยคุณได้"

โดยทั่วไปแล้ว อย่าถาม หรือพยายามเลี่ยงคำถามที่ว่า "ใช่ หรือ ไม่ใช่" ยกเว้นว่าท่านต้องการ คำตอบเช่นนั้นจริงๆ

อย่าจั่วหัวคำถามส่วนตัวว่า "ด่วนที่สุด"

นี่มันปัญหาของคุณ ไม่ใช่ปัญหาของเรา การมาอ้างว่าเป็นปัญหาเร่งด่วนมักจะได้ผลลบ แฮ็กเกอร์ส่วนใหญ่จะลบข้อความเหล่านี้ทิ้ง เพราะถือว่าเป็นการเรียกร้องความสนใจที่หยาบคายและเห็นแก่ตัว

แต่ก็มีกึ่งๆ ข้อยกเว้นประการหนึ่ง คือหากคุณใช้โปรแกรมนี้ในสถานที่สำคัญ ที่ซึ่งทำให้แฮ็กเกอร์รู้สึกตื่นเต้นได้ กรณีนี้หากคุณต้องทำงานแข่งกับเวลา และคุณขออย่างสุภาพแล้ว คนอาจมีความสนใจพอจะช่วยตอบให้เร็วขึ้นก็ได้

แต่นี่เป็นวิธีที่เสี่ยง เพราะสิ่งที่แฮ็กเกอร์ถือว่าน่าตื่นเต้นนั้นอาจจะต่างกับแนวคิดของคุณ ข้อความจากสถานีอวกาศถือได้ว่าน่าตื่นเต้น แต่ข้อความจากองค์กรการกุศลหรือองค์กรการเมืองนั้นไม่ใช่แน่ ที่จริงแล้ว หากคุณโพสต์ว่า "ด่วนที่สุด โปรดช่วยฉันช่วยลูกแมวน้ำด้วย" นั้นจะทำให้คุณไม่ได้รับความสนใจ หรืออาจถูกสร้างสงครามเมล โดยแฮ็กเกอร์ที่แม้ว่าส่วนตัวจะคิดว่าลูกแมวน้ำเป็นสิ่งสำคัญก็ตาม

หากคุณไม่เข้าใจ ก็ให้อ่านคู่มือนี้ไปเรื่อยๆ จนกว่าจะเข้าใจก่อนจะโพสต์อะไรทั้งสิ้น

ความอ่อนน้อมไม่เคยฆ่าใคร

พยายามมีมารยาท ให้ใช้คำว่า "ครับ (ค่ะ)" และ "ขอบคุณครับ (ค่ะ) ที่ช่วย" หรือ "ขอบคุณครับ (ค่ะ)" แสดงให้เห็นว่าคุณรู้สึกซาบซึ้งใจที่คนอื่นมาช่วยคุณฟรีๆ

หากพูดกันตรงๆ เรื่องนี้ไม่สำคัญเท่า (และไม่สามารถเอามาทดแทน) การเขียนอย่างถูกไวยากรณ์ ชัดเจน สั้นได้ใจความ ไม่ใช้รูปแบบเฉพาะ ฯลฯ โดยทั่วไปแฮ็กเกอร์นั้นรับรายงานบั๊กที่หยาบและมีคุณค่าทางเทคนิค ได้มากกว่างานเขียนที่สุภาพแต่ไม่มีอะไรเด่นชัด (ถ้าคุณงง ก็จำไว้ว่าเราตีค่าคำถาม โดยการประเมินว่าเราเรียนรู้จากมันได้มากเท่าไร)

อย่างไรก็ตาม หากคุณมีคำถามที่ไม่มีคุณค่าทางเทคนิคเอาซะเลย การแสดงความสุภาพจะเพิ่มโอกาสในการได้คำตอบ

(เราขอบอกไว้ก่อนว่า คำค้านที่เราได้รับจากแฮ็กเกอร์ประสบการณ์สูง เกี่ยวกับคู่มือนี้ คือเรื่องของการใช้คำว่า "ขอบคุณล่วงหน้าครับ (ค่ะ)" แฮ็กเกอร์บางคนรู้สึกว่าคำขอบคุณนี้แสดงว่าจะไม่มีการขอบคุณหลังงานเสร็จ เราแนะนำว่าขอให้พูดว่า "ขอบคุณล่วงหน้าครับ (ค่ะ)" ก่อน และ ขอบคุณผู้ตอบอีกครั้งในภายหลัง หรือให้แสดงความขอบคุณในรูปแบบอื่น เช่น "ขอบคุณครับ (ค่ะ) ที่ช่วย" หรือ "ขอบคุณครับ (ค่ะ)")

อย่าลืมบอกว่าแก้ไขได้แล้ว และ ได้อย่างไร

ให้ส่งข้อความถึงคนที่ช่วยคุณหลังจากแก้ไขปัญหาแล้ว บอกให้พวกเขารู้ว่าผลเป็นอย่างไร และขอบคุณพวกเขาอีกทีสำหรับความช่วยเหลือ หากปัญหานี้สร้างความสนใจกับคนในกลุ่ม ก็ควรจะโพสต์คำตอบไว้ด้วย

คำตอบนั้นควรอยู่ในรูปของกระทู้ ที่เริ่มด้วยคำถามดั้งเดิม และควรจะมีคำว่า "ซ่อมได้แล้ว (FIXED)", "แก้ได้แล้ว (RESOLVED)" หรืออะไรประมาณนี้ในหัวเรื่อง ในกลุ่มจดหมายที่มีการรับส่งสูง ผู้ที่จะตอบที่เห็นเธรดของจดหมายว่า "ปัญหา ก" และจบด้วย "ปัญหา ก แก้ไขแล้ว" จะรู้ว่าไม่ต้องเสียเวลามาอ่านเธรดนี้ (เว้นแต่ว่าเขาเห็นว่าปัญหา ก นี้น่าสนใจ) และสามารถใช้เวลาในการแก้ปัญหาอื่นได้

(ในกรณีเป็นฟอรัม สามารถประยุกต์ใช้แนวคิดนี้ได้โดย เมื่อผู้ถามสามารถแก้ปัญหาได้แล้ว ให้ไปแก้ไขกระทู้คำถามตรงส่วนของหัวข้อ โดยเติมคำว่า "แก้ได้แล้ว" หรือ "RESOLVED" ต่อท้ายหัวข้อเดิม -- Kamthorn)

คำตามนี้ไม่ต้องยาวมาก แค่คำง่ายอย่าง "หวัดดีครับ ปัญหาอยู่ที่เคเบิ้ลเน็ตเวิรค์ ขอบคุณทุกคนนะ - บิล" ก็ยังดีกว่าไม่พูดอะไรเลย ที่จริงแล้วคำสรุปสั้นๆ ยังดีกว่าวิทยานิพนธ์ขนาดยาวซะอีก เว้นแต่ว่าทางแก้ไขนี้เป็นเรื่องด้านเทคนิค ให้บอกว่าทำอย่างไรจึงแก้ปัญหาได้ แต่ไม่ต้องบรรยายละเอียดทุกขั้นตอน

สำหรับปัญหาที่ซับซ้อน ก็ควรจะมีการสรุปประวัติการแก้ไขปัญหา ให้บอกปัญหาท้ายสุด บรรยายว่าทางแก้คืออะไร และชี้หลุมพรางที่อาจเกิดขึ้นได้ หลังจากนั้น หลุมพรางเหล่านี้ควรมาหลังทางแก้ไขที่ถูกต้อง และบทสรุปอื่นๆ เพราะเราไม่ต้องการให้สรุปนี้กลายเป็นนิยายนักสืบ ให้บอกรายชื่อของคนที่ช่วยคุณด้วย คุณจะได้เพื่อนด้วยวิธีนี้

นอกจากจะต้องใจกว้างและให้ข้อมูลได้ดีแล้ว การตอบนี้ยังจะช่วยให้คนที่กำลังค้นหาบันทึกในกลุ่มจดหมาย กระดานข่าว หรือกลุ่มข่าว ได้รู้ว่าวิธีใดช่วยแก้ปัญหาให้คุณและอาจช่วยพวกเขาได้

สุดท้ายแต่ไม่ท้ายสุด การตอบแบบนี้ช่วยให้คนที่ช่วยได้รู้สึกดีที่ช่วยแก้ไขปัญหา หากคุณไม่ใช่นักเทคนิคหรือแฮ็กเกอร์ เชื่อเราเถอะว่าความรู้สึกนี้สำคัญกับพวกผู้รู้ที่คุณขอให้ช่วย ปัญหาที่นำไปสู่การไม่แก้ไขอะไรนั้นเป็นเรื่องน่าอึดอัด แฮ็กเกอร์นั้นอยากแก้ปัญหาตัวสั่น และคนที่จะช่วยเกาที่คันให้ย่อมจะช่วยให้คุณได้รับความช่วยเหลือ ในกรณีที่คุณอาจต้องถามคำถามในอนาคต

ให้คิดด้วยว่าคุณสามารถทำให้คนอื่นไม่ต้องเจอปัญหาในอนาคตได้อย่างไร ถามตัวเองว่าแพชต์ของเอกสารหรือ FAQ จะช่วยได้หรือไม่ และหากคำตอบคือใช่ก็ขอให้ส่งแพชต์นั้นให้กับผู้ดูแล

สำหรับแฮ็กเกอร์แล้ว การติดตามที่ดีนั้นสำคัญกว่าความสุภาพ และนี่เป็นวิธีการสั่งสมชื่อเสียง ซึ่งเป็นทรัพย์สินที่มีค่ายิ่ง

วิธีตีความคำตอบ

RTFM และ STFW: ช่วยไขปัญหาหนักอกของคุณได้

ประเพณีโบราณและไม่ซับซ้อนประการหนึ่งคือ หากคุณได้รับคำตอบว่า "RTFM" คนที่ส่งคำตอบนี้มามีความเห็นว่าคุณ ควรจะไปอ่านคู่มือสิ (โว้ย) พวกเขานั้นมักคิดถูก ไปอ่านซะ

RTFM ยังมีญาติผู้น้องอีกคน หากคุณได้คำตอบว่า "STFW" คนที่ส่งมานั้นคิดว่าคุณ ควรจะไปหาเอาในเน็ตสิ (โว้ย) พวกเขาก็มักจะถูก ลองไปหาซะ (ยังมีแบบเบาอีก โดยคุณจะได้รับข้อความว่า "Google คือเพื่อนของนาย")

ในฟอรัม คุณจะได้รับคำแนะนำให้ค้นหาในบันทึกเก่า บางคนอาจจะช่วยถึงขนาดให้ลิ้งก์ของบันทึกเก่าที่มีการแก้ไขปัญหาแล้ว แต่อย่าหวังพึ่งความใจดีให้มากนัก ให้คุณลองค้นหาเองดูก่อนจะถาม

บ่อยครั้งที่คนที่บอกให้คุณหานั้น จะมีคู่มือหรือเว็บไซต์ที่มีข้อมูลที่คุณต้องการอยู่ และกำลังเปิดมันขณะที่พวกเขากำลังพิมพ์ การตอบแบบนี้หมายความว่าพวกเขาคิดว่า (ก) ข้อมูลที่คุณต้องการนั้นหากได้ง่ายมาก (ข) คุณจะได้เรียนรู้มากกว่าหากคุณหาข้อมูลเอง แทนที่จะมีคนมาประเคนให้ถึงที่

คุณไม่ควรโกรธในกรณีนี้ สำหรับแฮ็กเกอร์แล้ว ผู้ตอบได้แสดงการยอมรับแบบหยาบๆ โดยการให้ความสนใจกับคุณ คุณควรจะขอบใจความใจดีในแบบนี้ซะด้วยซ้ำ

ถ้าคุณยังไม่เข้าใจ...

หากคุณไม่เข้าใจคำตอบ อย่าไปขอคำอธิบายโดยทันที ให้ใช้เครื่องมือที่คุณเคยใช้ในการหาคำตอบของคำถาม (คู่มือ, FAQS, อินเตอร์เน็ต, เพื่อนที่มีความรู้) เพื่อทำความเข้าใจคำตอบ หากคุณยังต้องขอคำอธิบายอีก ก็ให้แสดงด้วยว่าคุณได้รู้อะไรเพิ่มเติมมาแล้ว

ตัวอย่างเช่น หากผมบอกคุณว่า "ดูเหมือนว่าคุณจะเจอปัญหา zentry ค้าง, ลองเคลียร์ดู" คำถามต่อแบบ แย่ คือ "zentry คืออะไร?" คำถามที่ ดี ที่ควรถามต่อคือ "โอเค ผมอ่านหน้า man แล้ว zentries นั้นถูกพูดถึงใน -z กับ -p switches แต่ไม่ได้พูดว่าจะเคลียร์อย่างไร เราต้องใช้ switch หนึ่งในสองตัวนี้ หรือในส่วนนี้ผมยังพลาดอะไรไปหรือไม่?"

การรับมือกับความหยาบคาย

สิ่งที่ดูเหมือนความหยาบคายในวงแฮ็กเกอร์นั้น ไม่ได้เป็นการตั้งใจยั่วโมโหแต่อย่างใด แต่มันเป็นผลของวิธีการสื่อสารแบบตรงๆ ไม่ต้องมาตอแหลกัน ที่เป็นระบบของคนที่ต้องการแก้ไขปัญหา มากกว่าจะมารักษาความรู้สึกคนอื่น

หากคุณรู้สึกว่ามีความหยาบคาย ขอให้พยายามตอบด้วยความใจเย็น หากมีใครล้ำเส้นไปมาก บุคคลที่มีอาวุโสในกลุ่มจะเรียกไปตักเตือนเอง หาก ไม่มี การตักเตือนเกิดขึ้น และคุณรู้สึกโกรธ ก็เป็นไปได้ว่าคนที่คุณโกรธนั้น ยังประพฤติตัวอยู่ในปกติวิสัยของสังคมแฮ็กเกอร์ และ คุณ เองนั่นล่ะที่เป็นคนผิด ซึ่งจะมีผลต่อโอกาสในการได้รับข้อมูลหรือความช่วยเหลือที่ต้องการ

ในขณะเดียวกัน คุณอาจเจอความหยาบคาย และท่าทางที่แสดงแบบค่อนข้างแรง ข้อดีของพฤติกรรมนี้คือ วิธีนี้เป็นการเบรกพวกป่วนตัวจริงอย่างได้ผล โดยการชำแหละพฤติกรรมเหล่านี้ด้วยวาจาอันเชือเฉือน แต่ขอให้คุณตรวจสอบให้ดีก่อนจะใช้วิธีนี้ เพราะเส้นแบ่งระหว่างการจัดการคนมารยาททราม กับการโต้เถียงแบบไร้สาระนั้นบางมาก จนบางครั้งแฮ็กเกอร์เองก็ล้ำเส้นไปโดยไม่ตั้งใจ หากคุณเป็นมือใหม่หรือคนวงนอก โอกาสในการหลีกเลี่ยงการล้ำเส้นนี้เป็นไปได้ยาก หากคุณต้องการข้อมูลมากกว่าความบันเทิงแล้ว ก็ควรจะวางนิ้วจากแป้นพิมพ์แทนที่จะเสี่ยง

(บางคนกล่าวว่าแฮ็กเกอร์หลายคนมีอาการของออทิสซึ่ม (ความผิดปกติทางการสื่อสารและอารมณ์) หรือ กลุ่มอาการแอสเพอร์เจอร์ และขาดวงจรสมองบางส่วนที่ทำงานด้านปฏิสัมพันธ์กับสังคม "แบบปกติ" ซึ่งอาจจริงหรือไม่ก็ได้ หากคุณไม่ใช่แฮ็กเกอร์ คุณอาจทนความประหลาดของพวกเราได้มากขึ้นหากคิดว่าเราเป็นพวกสมองไม่ปกติ เชิญตามสบาย เราไม่สนหรอก เรา ชอบ ที่จะเป็นในสิ่งที่เราเป็น และเราไม่ค่อยจะเชื่อถือหมอเท่าไรอยู่แล้ว)

ในส่วนต่อไป เราจะพูดถึงประเด็นต่างๆ เรื่องของ "ความหยาบคาย" ที่จะพบหาก คุณ ประพฤติตัวไม่ดี

อย่าแสดงอาการของพวกขี้แพ้

บางครั้งคุณอาจจะทำสิ่งผิดพลาดในฟอรัมของแฮ็กเกอร์ ในลักษณะที่เขียนไว้ในบทความนี้หรือใกล้เคียง และคุณจะถูกบอกกล่าวว่าคุณได้ทำพลาดอย่างไรชนิดที่ดูไม่จืดเลยละท่ามกลางสาธารณชน

หากสิ่งนี้เกิดกับคุณ สิ่งที่แย่ที่สุดที่คุณทำได้คือ คร่ำครวญกับประสบการณ์นี้ เที่ยวประกาศว่าถูกทำร้ายด้วยวาจา เรียกร้องคำขอโทษ โวยวาย กลั้นหายใจ ขู่ว่าจะฟ้องศาล บ่นให้เจ้านายฟัง ไม่เอาฝาชักโครกลง ฯลฯ

เลิกคิดมากซะ มันเป็นเรื่องธรรมดา ที่จริงแล้ว มันเหมาะสมและมีผลดีด้วยซ้ำ

มาตรฐานสังคมนั้นไม่ได้ดูแลตนเอง แต่มันถูกดูแลด้วยคนที่ใช้มัน ในที่สาธารณะ อย่าบ่นว่าการวิจารณ์ควรจะทำผ่านเมล ส่วนตัว บ่นว่าวิธีนี้ไม่ถูกต้อง และไม่มีประโยชน์ที่จะพร่ำบอกว่าคุณโดนดูถูกเป็นการส่วนตัว เมื่อมีคนวิจารณ์ว่าคำอ้างของคุณผิด หรือมุมมองของเขาไม่เหมือนคุณ เพราะการคิดแบบนี้มันเป็นทัศนคติของพวกขี้แพ้

มีฟอรัมของแฮ็กเกอร์บางที่จะแบนคนที่โพสต์ข้อความในลักษณะ การจับผิดการโสต์ผู้อื่น และบอกว่า "มือไม่พายอย่าเอาเท้าราน้ำ" เพราะต้องการจะแสดงมารยาทที่ดีเกินเหตุ ผลก็คือคนที่มีความรู้ต่างพากันหนีไปที่อื่น ทำให้ฟอรัมกลายเป็นที่รวมการพูดคุยไร้สาระและไม่มีประโยชน์ทางเทคนิค

การ "เป็นมิตร" เกินเหตุ (ในแง่ดังกล่าว) หรือมีประโยชน์: เลือกเอาสักอย่าง

จำไว้ว่า หากแฮ็กเกอร์บอกว่าคุณทำผิดแล้ว และบอกว่าอย่าทำแบบนั้นอีก (ไม่ว่าจะฟังไม่เสนาะหูแค่ไหนก็ตาม) เขานั้นทำเพื่อ (1) ตัวคุณเอง และ (2) สังคมของเขา คงจะง่ายกว่าหากเขาเลือกจะไม่สนใจและตัดคุณออกไปจากชีวิตเขา หากคุณไม่รู้จักสำนึกบุญคุณ อย่างน้อยก็มีศักดิ์ศรีบ้าง อย่าบ่น และอย่าหวังว่าจะได้รับการดูแลอย่างแก้วตาดวงใจ เพียงเพราะคุณเป็นมือใหม่ ที่มีความอ่อนไหวเกินพอดีและให้ความสำคัญกับตัวเองมากเกินไป

บางครั้งคนจะโจมตีคุณ สร้างสงครามเมลโดยไม่มีเหตุผล และอื่นๆ แม้ว่าคุณไม่ได้ทำอะไรผิด (หรือพวกเขาคิดเอาเองว่าคุณผิด) ในกรณีเช่นนี้ การบ่นจะเป็นการ ทำพลาด อย่างแท้จริง

พวกสร้างสงครามเมลนี้จะเป็น พวกงี่เง่าที่ไม่รู้จริงแต่คิดว่าตัวเองเก่ง หรือเป็นพวกอยากเป็นนักจิตวิทยาที่ต้องการทดสอบว่าคุณจะพลาดหรือเปล่า คนอ่านคนอื่นจะไม่สนใจ หรือหาวิธีจัดการพวกนั้นเอง พฤติกรรมพวกนี้จะสร้างปัญหาให้กับตนเอง ซึ่งคุณไม่ต้องไปสนใจ

อย่าไปร่วมสงครามเมล คุณไม่ควรสนใจสงครามเหล่านี้ หากคุณพบว่าเป็นแค่การยั่วยุ ไม่ใช่เครื่องชี้ว่าคุณพลาดตรงไหน และไม่ได้ซ่อนคำตอบของคำถามเอาไว้ในคำถากถาง (กรณีนี้ก็มีเหมือนกัน)

คำถามที่น่ารังเกียจ

ต่อไปนี้เป็นคำถามงี่เง่าระดับคลาสสิค และสิ่งที่แฮ็กเกอร์คิดตอนที่ไม่ยอมตอบ

Q: Where can I find program or resource X?

ถ. ผมจะหาโปรแกรม ก ได้ที่ไหน?

Q: How can I use X to do Y?

ถ. ผมจะใช้โปรแกรม ก ทำงาน ข ได้อย่างไร?

Q: How can I configure my shell prompt?

ถ. ผมจะตั้ง shell prompt อย่างไร?

Q: Can I convert an AcmeCorp document into a TeX file using the Bass-o-matic file converter?

ถ. ผมจะแปลงเอกสารของ Acmecorp เป็น TeX ด้วยเครื่องมือ Bass-o-matic อย่างไร?

Q: My {program, configuration, SQL statement} doesn't work

ถ. (โปรแกรม, การตั้งค่า, ประโยค SQL) ของผมไม่ทำงาน

Q: I'm having problems with my Windows machine. Can you help?

ถ. ผมมีปัญหากับเครื่องที่ใช้วินโดว์ คุณช่วยได้ไหมครับ?

Q: My program doesn't work. I think system facility X is broken.

ถ. โปรแกรมของผมไม่ทำงาน ผมว่าระบบ ก มันเสีย

Q: I'm having problems installing Linux or X. Can you help?

ถ. ผมติดตั้งลินุกซ์หรือโปรแกม ก ไม่ได้ ช่วยได้ไหมครับ?

Q: How can I crack root/steal channel-ops privileges/read someone's e-mail?

ถ. ผมจะเจาะ root/ โขมยสิทธิ channel-ops/อ่านเมลคนอื่นได้ยังไง?

Q:

ผมจะหาโปรแกรม ก ได้ที่ไหนครับ?

A:

ก็ที่เดียวกับที่ตูหาเจอสิ ไอ้ง่าวเอ๊ย ที่เครื่องมือหาไง โห, ป่านนี้ยังมีคนไม่รู้จักใช้ Google อีกเรอะ

Q:

ผมจะใช้โปรแกรม ก ทำงาน ข อย่างไร?

A:

หากคุณต้องการทำงาน ข คุณต้องถามคำถามโดยไม่ทึกทักเอาเองว่าต้องใช้วิธีที่อาจไม่เหมาะสม คำถามแบบนี้มันแสดงว่าคนถามไม่เพียงไม่รู้เรื่องโปรแกรม ก แต่ยังสับสนเกี่ยวกับปัญหา ข และยึดติดกับวิธีการแก้ปัญหาเฉพาะเกินไป โดยทั่วไปแล้วเราควรไม่ใส่ใจคนพวกนี้จนกว่าเขาจะตีโจทย์ให้แตกกว่านี้

Q: ผมจะตั้งค่า shell prompt อย่างไร?
A: ถ้านายฉลาดพอจะถาม นายก็คงฉลาดพอจะ RTFM แล้วหาคำตอบเองนะ
Q: ผมจะแปลงเอกสารของ Acmecorp เป็น TeX ด้วยเครื่องมือ Bass-o-matic อย่างไร?
A: ลองทำเองดู เพราะถ้านายทำ นายจะได้ (ก) เรียนรู้คำตอบ (ข) เลิกมาทำให้ตูเสียเวลาซะที
Q: (โปรแกรม, การตั้งค่า, ประโยค SQL)ของผมไม่ทำงาน
A: นี่ไม่ใ่ช่คำถามแล้ว และผมก็ไม่อยากเล่น 20 คำถามจนกว่าจะได้คำถามที่แท้จริงหรอกนะ ผมมีอย่างอื่นต้องทำ พอเห็นคำถามประเภทนี้ ส่วนใหญ่ผมจะ
  • มีอะไรเพิ่มเติ่มอีกไหม?
  • โอ้แย่จัง หวังว่าคงแก้ได้นะ
  • แล้วมันเกี่ยวอะไรกับตูเนี่ย?
Q: ผมมีปัญหากับเครื่องที่ใช้วินโดว์ คุณช่วยได้ไหมครับ?
A: ได้สิ โยนไอ้ของห่วยๆ ของไมโครซอฟต์ทิ้ง แล้วติดตั้งระบบแบบ open-source อย่างลินุกซ์หรือ BSD สิ
หมายเหตุ: คุณสามารถถามคำถามที่เกี่ยวกับเครื่องวินโดว์ได้ หากมันเกี่ยวกับโปรแกรมที่ทำสำหรับวินโดว์ 
หรือมีการติดต่อกับวินโดว์ (เช่น samba) อย่าแปลกใจแล้วกันที่คำตอบจะเป็นว่า ปัญหาอยู่ที่วินโดว์ไม่ใช่ที่โปรแกรม, 
เพราะวินโดว์นั้นไม่เสถียรขนาดที่ส่วนใหญ่ปัญหาจะเป็นเช่นนั้น
Q: โปรแกรมของผมไม่ทำงาน ผมว่าระบบ ก มันเสีย
A: เป็นไปได้ที่คุณอาจเป็นคนแรกในโลกที่พบข้อบกพร่องในระบบที่มีคนนับแสนใช้ แต่ความเป็นไปได้ที่มากกว่าก็คือคุณน่ะมันไม่รู้เรื่อง การอ้างแบบเหลือเชื่ือนี้ต้องมีหลักฐานแบบเหลือเชื่อเช่นกัน ถ้าคุณพูดแบบนี้ คุณต้องหาเอกสารที่เด่นชัดและครบถ้วนสมบูรณ์ของความผิดพลาด
Q: ผมติดตั้งลินุกซ์หรือโปรแกม ก ไม่ได้ ช่วยได้ไหมครับ?
A: ไม่ได้ ผมต้องสามารถเข้าถึงเครื่องคุณได้โดยตรงเพื่อแก้ปัญหานี้ ลองไปถามกลุ่มผู้ใช้ในพื้นที่เพื่อความช่วยเหลือนี้ (คุณสามารถหารายชื่อกลุ่มผู้ใช้ท้องถิ่นได้ ที่นี่
Note: questions about installing Linux may be appropriate if you're on a forum or mailing list about 
a   particular distribution, and the problem is with that distro; or on local user groups forums. In this case, 
be sure to describe the exact details of the failure. But do careful searching first, with "linux" and 
all suspicious pieces of hardware.


Q: ผมจะเจาะ root/ โขมยสิทธิ channel-ops/อ่านเมลคนอื่นได้ยังไง?
A: แกนี่มัน ทั้งชั่ว ทีอยากทำอะไรแบบนี้ แถมยังโง่อีกที่มาขอให้แฮ็กเกอร์ช่วยน่ะ

จะให้คำตอบดีๆ ได้อย่างไร?

สุดท้ายนี้ ผมจะแสดงให้เห็นว่าจะถามคำถามแบบสร้างสรรค์อย่างไร โดยการยกตัวอย่าง คู่คำถามของปัญหาเดียวกัน วิธีหนึ่งถามอย่างไม่สร้างสรรค์ และอีกวิธีถามอย่างสร้างสรรค์

ไม่สร้างสรรค์: ผมจะหาข้อมูลเกี่ยวกับ Foonly Flurbamatic ได้ที่ไหน?

คำถามนี้ไม่แคล้วโดน "STFW" เป็นคำตอบแน่

สร้างสรรค์: ผมลองหา google เกี่ยวกับ "Foonly Flurbamatic 2600" ในอินเตอร์เน็ต แต่ไม่ได้เรื่องอะไรเลย ผมขอตัวชี้แนะเกี่ยวกับการโปรแกรมเครื่องมือนี้ได้ไหมครับ"

ข้อนี้ได้ทำ STFW แล้ว และดูเหมือนว่าเขาจะมีปัญหาจริงๆ

ไม่สร้างสรรค์: ผมเอาโค้ดจากโครงการมาคอมไพล์ไม่ได้ ทำไม่มันเสีย? คนถามทึกทักเอาว่า คนอื่นทำพลาด ไอ้จองหองเอ๊ย

สร้างสรรค์: โค้ดของโครงการนี้คอมไพล์ด้วย Nulix 6.2 ไม่ได้ ผมอ่าน FAQ แล้ว แต่ไม่ได้พูดถึงปัญหากับ Nulix เลย ผมได้แนบเอกสารการคอมไพล์มาด้วย ผมทำอะไรผิดหรือเปล่าครับ? คนถามได้บอกสภาพแวดล้อม อ่าน FAQ แสดงข้อผิดพลาด และไม่ได้คิดว่าปัญหาของเขาเกิดจากความผิดพลาดของคนอื่น อย่างนี้ค่อยน่าสนใจหน่อย

ไม่สร้างสรรค์: ผมมีปัญหากับมาเธอร์บอร์ด ใครช่วยได้บ้าง? แฮ็กเกอร์ส่วนใหญ่น่าจะตอบว่า "นั่นสิ แล้วฉันต้องจับนายเรอและเปลี่ยนผ้าอ้อมด้วยไหมนี่?" ตามด้วยกดปุ่มดีลีท

สร้างสรรค์: ผมลองวิธี ก, ข, และ ค บนบอร์ด s2464 และเมื่อไม่ได้ผลก็ใช้วิธี ง, จ, และ ฉ ผมพบสิ่งที่น่าสนใจตอนใช้วิธี ฉ เพราะ florbish นั้นทำงาน แต่ผลลัพธ์ได้ไม่ตรงกับที่คาดไว้ โดยปกติบอร์ด Athlon MP นั้นทำงานอย่างไร? ใครมีวิธีจะทดสอบเพื่อตรวจสอบปัญหานี้ได้บ้างครับ? คนนี้นั้นสมควรได้รับคำตอบ เขาได้แสดงให้เห็นถึงปัญญาในการแก้ไขปัญหา แทนที่จะรอให้คำตอบหล่นมาจากฟ้า

ในคำถามท้ายนี้ ให้สังเกตความแตกต่างที่ซ่อนอยู่ระหว่าง เรียกร้องให้ "ตอบมา" กับ "ช่วยผมหาวิธีการตรวจเพิ่มเติมที่จะทำให้ผมเกิดพุทธิปัญญาขึ้นที"

ที่จริงแล้วรูปแบบคำถามสุดท้ายนี้ คล้ายกับเหตุการณ์จริงที่เกิดขึ้นในช่วงเดือนสิงหาคมปี 2001 บนกลุ่มจดหมายลินุกซ์-เคอร์เนล (lkml) ผม (เอริค)เป็นคนถามคำถามนี้ เพราะผมพบการค้างของ Tyan S2462 และสมาชิกของกลุ่มได้ให้ข้อมูลสำคัญที่ช่วยแก้ไขปัญหา

โดยการถามแบบที่ผมได้ทำ ผมได้ให้สิ่งที่เขานำไปคิด ผมได้ทำให้การมีส่วนร่วมของพวกเขาเป็นเรื่องง่ายและน่าสนใจ ผมได้แสดงความเคารพต่อความสามารถของพวกเขา และเชิญให้เขามามีส่วนร่วมในการแก้ปัญหาในฐานะเพื่อน ผมยังเคารพเวลาของพวกเขา โดยการบอกพวกเขาว่าผมได้เจอทางตันตรงไหนแล้วบ้าง

หลังจากนั้น เมื่อผมได้ขอบคุณทุกคน และได้บอกว่ากระบวนการนี้ได้ผลดีอย่างไร สมาชิกคนหนึ่งได้ตั้งข้อสังเกตว่า งานนี้ได้ผลไม่ใช่เพราะผมเป็น "บุคคลในรายชื่อ" แต่เพราะผมได้ถามคำถามนี้ด้วยรูปแบบที่เหมาะสม

แฮ็กเกอร์นั้นเป็นพวกที่่นับถือกันด้วยความสามารถ ผมคิดว่าเขาพูดถูก หากผม ประพฤติตัว เป็นพวกที่รอให้ป้อนอย่างเดียว ผมก็คงถูกโจมตีด้วยเมล หรือถูกทิ้งไม่ใส่ใจ ไม่ว่าผมจะเป็นใครก็ตาม เขาได้แนะนำให้ผมเขียนเหตุการณ์นี้เป็นคู่มือ และนั่นเป็นผลให้เกิดคู่มือนี้ขึ้นมา

ถ้าคุณไม่ได้รับคำตอบ

หากคุณไม่ได้รับคำตอบ อย่าไปคิดว่าพวกเราไม่อยากจะข่วยคุณ บางครั้งสมาชิกในกลุ่มอาจไม่รู้คำตอบก็ได้ การไม่ตอบไม่ได้แปลว่าไม่สนใจ แม้ืว่าสำหรับคนภายนอกแล้ว จะเห็นความแตกต่างได้ยากก็ตาม

โดยทั่วไป การโพสต์ซ้ำเป็นความคิดที่ไม่ดี เพราะจะถูกมองว่าเป็นพวกน่ารำคาญ ขอให้คุณมีความอดทน คนที่จะตอบคำถามคุณอาจอยู่ในโซนเวลาที่ต่างออกไปและกำลังหลับอยู่ หรืออาจเป็นไปได้ว่าคำถามของคุณอาจเขียนได้ไม่ดีเท่าไร

ยังมีแหล่งช่วยเหลืออื่นที่คุณสามารถหาได้ และหลายที่ที่จะเหมาะกับมือใหม่

มีกลุ่มผู้ใช้ออนไลน์และในพื้นที่ ที่มีความสนใจในโปรแกรม แม้ว่าพวกเขาจะไม่เคยเขียนโปรแกรมเอง กลุ่มเหล่านี้มักตั้งขึ้นเพื่อช่วยเหลือกันและกัน รวมทั้งช่วยผู้ใช้รายใหม่ๆ

ยังมีบริษัทเชิงพาณิชย์ที่คุณสามารถจ้างได้ ทั้งขนาดใหญ่และเล็ก (ที่ขึ้นชื่อได้แก่ Red Hat และ SpikeSource และยังมีบริษัทอื่นอีก) อย่าไปคิดว่าการเสียเงินเพื่อขอความช่วยเหลือเป็นเรื่องแย่ เพราะหากรถคุณท่อไอเสียหลุด คุณก็คงต้องเอาไปอู่ซ่อมและเสียเงิน แม้ว่าโปรแกรมจะเป็นของฟรี ก็ไม่ได้หมายความว่าระบบสนับสนุนจะต้องฟรีไปด้วย

สำหรับโปรแกรมยอดนิยมอย่างลินุกซ์ อัตราส่วนของผู้ใช้ต่อผู้พัฒนามีอย่างน้อย 1:10,000 จึงเป็นไปไม่ได้ที่คนหนึ่งคนจะสามาถแก้ไขปัญหาให้คนหมื่นคนได้ จำไว้ว่าแม้คุณจะใช้ระบบสนับสนุนแบบเสียเงิน คุณก็ยังจ่ายน้อยกว่าที่คุณต้องจ่ายเพื่อซื้อทั้งโปรแกรมและระบบสนับสนุน (ระบบสนับสนุนของโปรแกรมแบบไม่เปิดเผยรหัสนั้นมักจะมีราคาแพงกว่าและมีประสิทธิภาพต่ำกว่าระบบ Open Source)

ตอบอย่างไรถึงจะได้ประโยชน์

รักษาความสุภาพไว้ พวกปัญหาเครียดๆ สามารถทำให้ผู้คนดูเหมือนว่าจะหยาบคายและงี่เง่า แม้ว่าพวกเขาจริงๆ แล้วไม่ใช่.

เตือนคนที่ทำพลาดครั้งแรกแบบออฟไลน์ ไม่จำเป็นอะไรที่จะไปดูถูกคนที่ทำพลาดโดยบริสุทธิ์ใจในที่สาธารณะ มือใหม่มักไม่ทราบวิธีการสืบหาบันทึกเก่า หรือ FAQ ที่มีอยู่

ถ้าคุณไม่แน่ใจ ก็ตอบว่าไม่แน่ใจ คำตอบที่ผิด แต่ตอบด้วยความมั่นใจนั้นยังแย่กว่าการไ่ม่ตอบเสียอีก อย่าชี้ไปในทางที่ผิดเพียงเพราะความสนุกกับการตอบเหมือนเป็นผู้ชำนาญการ คุณควรถ่อมตนและซื่อตรง ทำตัวให้เป็นตัวอย่างกับผู้ที่ถามและคนในชุมชน

ถ้าคุณไม่สามารถช่วยได้ อย่าเฉไฉ อย่าบอกคำสั่งที่จะทำให้เครื่องพังแบบทีเล่นที่จริง เพราะคนเหล่านั้นอาจนึกว่าเป็นวิธีการแก้ไขจริงๆ ก็ได้ คนไม่รู้ไม่แน่ว่าจะตีความคำตอบเหล่านั้นเป็นคำแนะนำ

ให้ถามคำถามเจาะลึกเพื่อให้ได้รายละเอียด หากคุณถามเก่ง ทั้งคนมาขอควาามช่วยเหลือและคุณจะได้เรียนรู้บางอย่าง ให้พยายามเปลี่ยนคำถามที่แย่ให้เป็นคำถามที่ดี จำไว้ว่าเราทุกคนเคยเป็นมือใหม่มาก่อนทั้งนั้น

การพูดว่า RTFM (ไปอ่านคู่มือสิ (โว้ย)) นั้นบางครั้งก็เป็นคำตอบที่เหมาะแล้วกับคนที่เอาแต่แบมือขอความช่วยเหลือจากคนอื่น แต่การชี้แนะไปสู่เอกสารประกอบ (แม้ว่าจะเป็นแค่การแนะนำคำสำคัญให้ไปค้นใน google) ก็ยังดีกว่า

หากคุณอยากจะตอบคำถาม ก็จงตอบให้ดี อย่าไปหาวิธีแก้ไขหากมีคนใช้เครื่องมือหรือวิธีการที่ผิด ให้เลือกแนะนำเครื่องมือที่ถูก และเปลี่ยนมุมมองของปัญหาใหม่


ช่วยให้ชุมชนได้เรียนรู้จากคำถาม หากคุณมีคำถามที่ดี ให้ถามตัวเองว่า "ควรจะเปลี่ยนคู่มือหรือ FAQ อย่างไรคนอื่นจึงจะไม่ต้องมาถามคำถามนี้อีก" แล้วส่งเอกสารที่แก้ไขไปยังผู้ดูแลคู่มือ

หากคุณมีการค้นคว้าก่อนตอบคำถาม ก็ให้แสดงว่าคุณค้นคว้ามา ไม่ใช่ว่าเขียนในแง่ว่าคุณเสกคำตอบมาได้เอง การตอบคำถามก็เหมือนการป้อนอาหารให้คนหิว แต่การสอนให้พวกเขารู้จักค้นคว้า ก็เหมือนกับการสอนให้เขาหาอาหารได้เองตลอดชีวิต

แหล่งข้อมูลที่เกี่ยวข้อง

  • ถ้าคุณต้องการคำแนะนำเบื้องต้นเกี่ยวกับการใช้งานคอมพิวเตอร์ส่วนบุคคล ยูนิกซ์ และ อินเทอร์เน็ต ลองอ่านที่ The Unix and Internet Fundamentals HOWTO
  • ถ้าคุณแขียนและแจกจ่ายซอฟ์ตแวร์ หรือ แพตช์ของซอร์ฟแวร์ ลองทำตามคำแนะนำที่ Software Release Practice HOWTO

กิตติกรรมประกาศ

  • คุณ Evelyn Mitchell ได้เสนอตัวอย่างของคำถามแย่ๆ และ คำถามเยี่ยมๆ ใน "หัวข้อจะให้คำตอบดีๆ ได้อย่างไร"
  • คุณ Mikhail Ramendik ได้เสนอตัวอย่างคำแนะนำดีๆ วำหรับการปรับปรุง

ผู้แปลภาษาไทย

เครื่องมือส่วนตัว