如何向開源社區提問題
使用軟件產品，或多或少都會遇到問題。對於商業產品，我們可以諮詢客服尋求幫助。對於公司自己研發的產品，我們可以直接請教專家同事。但對於開源軟件，在遇到問題時，如何才能及時有效地尋求幫助呢？
本文以開源類庫 SeaJS 為例，說說我心目中的最佳實踐。
提問前
遇到問題時，心裡都很着急。在決定向開源社區提交問題前，最好先做做以下功課：
嘗試從官方文檔中找到答案
確保自己閱讀過至少一次官方文檔。這樣在遇到問題時，如果能回憶起隻言片語，就可以再去讀一遍相關文檔，問題往往也就解決了。
Google 是你的朋友
對於成熟的開源項目，你遇到的問題，很可能別人也遇到過。這時通過 Google、StackOverflow 等網站的搜索服務，可以幫你快速定位並解決問題。永遠記住，地球上的你並不孤單，包括你遇到的問題。
挖掘 Bug 寶藏
開源軟件一般都會有自己的 Bug 管理方案，比如 WebKit、V8、jQuery、SeaJS 等等。從它們的官網上找到 Bug 管理地址，然後通過搜索看看有無你遇到的問題。對於活躍社區來說，這一招經常很管用。比如 jQuery 的 Bug Tracker，通過右上角的 Search Tickets 可以找到非常多有用的信息。一個運作良好的 Bug 庫，經常是一座巨大的寶藏。SeaJS 是直接通過 GitHub Issues 來管理，你可以在 Issues 中找到很多信息。
求助身邊的朋友
如果你使用的開源軟件，在朋友圈或同事圈裡也有人使用，那麼抬起你的腳、或拿起你的電話，真摯誠懇的探討不會遭遇拒絕，而會增進友誼。不要猶豫，你的內心渴望面對面交流，你的朋友也是。
如果以上 4 步都無法解決你遇到的問題，也別猶豫，立馬向開源社區提交問題就好。
提問時
提問有很多種，比如你認識作者，直接面對面請教就行。下面探討的是如何通過互聯網的方式來問問題。
平和對等的心態
很多開源軟件都是免費的，作者往往是業餘時間出於興趣在維護，沒有義務回答社區問題。提問時，不要把自己擺在顧客的位置，比如
项目马上要上线了，请务必帮忙解决 这是我的邮箱，请及时联系我
另外，也不要把自己擺在乞食者的位置，比如
冰天雪地跪求解答 救命啊，我的网站挂了
在開源社區，一切皆是朋友。無論對方是 Linux 內核的作者，還是某個 jQuery 插件的作者，你和作者都是對等的。你的提問是在幫助開源軟件完善。平和對等的心態，可以讓你的問題贏得更多人的閱讀和思考。
通過正確的途徑提交
如果遇到問題的開源軟件有專門的 Bug 管理系統，請最好到這些指定系統中提交。比如，對於前端開發工程師來說，下面這些 Tracker 系統很重要。
jQuery Tickets WebKit Bugzilla Mozilla Bugzilla 还有各个开源类库的 Issues 库，比如 SeaJS 的是：seajs/issues
最不好的途徑是 QQ 、阿里旺旺、微信 等群組。這些群組主要是用來工作或休閒的。對開源項目來說，在這些地方提問，作者一般不會關注，效率非常低。 微博、Facebook 等社交網絡。不少人在微博上通過 at 或私信詢問 SeaJS 問題，這些我經常看不到。看到了，也不情願回復。微博是扯淡、交流情感的地方，一般是寫代碼寫累了，才去逛逛，很少會有在社交網絡上回答技術問題的心情。
通過正確的途徑提交問題，一般可以讓你的問題得到及時準確的回覆。
使用明確、有意義的標題
抱着平和對等的心態，找到合適的途徑後，就得靜下心來將遇到的問題寫成文字。書寫文字不是一件簡單的事情，我們可以從遵循一些簡單的規則開始。
首先是標題要簡潔清晰，要言之有物。比如
我遇到了一个 Ajax 问题 SeaJS 在我的浏览器上运行不了
上面的標題很糟糕，光看標題作者無法知道發生了什麼事。當開源社區的問題很多時，上面這類標題，經常會讓作者直接忽視或將優先級降到很低。更妥當的標題是
Ajax 请求未返回正确的 responseXML SeaJS 2.0 在 IE6 上运行时抛错
明確、有意義的標題，可以幫助作者確定問題具體是什麼類型、預估需要多少時間解決、是否現在馬上解決等。一個好的標題，也有利於社區知識的沉澱和後期搜索。標題有如一個人的顏面衣着，雖然不是關鍵，但在嘈雜的信息社區中，這很重要。
遵循良好的模板
如果社區提供了問題模板，一定要仔細看下。比如 Google Code 社區，當你創建一個問題時，會自動提供以下模板：
What steps will reproduce the problem? 该问题的重现步骤是什么？ 1. 2. 3. What is the expected output? What do you see instead? 你期待的结果是什么？实际看到的又是什么？ What version of the product are you using? On what operating system? 你正在使用产品的哪个版本？在什么操作系统上？ Please provide any additional information below. 如果有的话，请在下面提供更多信息。
遵循這個模板去描述問題，經常能省很多事。作者一般也非常歡迎通過模板提交的問題。如果社區沒有提供模板，也可以自己遵循以上模板來提交。
下面針對問題內容，具體說說一些需要注意的點。
語法正確、格式清晰
雖然我們不是作家，但正確的語法、清晰的格式，可以讓讀者賞心悅目，也就更有心情幫你一起思考解決問題。
對於很多需要代碼來描述的問題，要尤其注意格式，比如
seajs.use('jquery',function($){$(document).ready(function() { /* ... */ })});
可讀性不如
seajs.use('jquery', function($) {
$(document).ready(function() {
// ...
});
});
GitHub 的 Markdown 語法可以很好地支持代碼排版、語法高亮等，建議書寫代碼時，一定要先閱讀下說明：GitHub Flavored Markdown。這能讓你的內容看起來很專業，社區也就更有意願會去幫助你，否則糟糕的排版，經常帶來的是發帖之後的石沉大海。
描述事實、而不是猜測
事實是指，依次進行了哪些操作、產生了怎樣的結果。比如
我在 Windows XP 下用 IE6 打開 seajs.org 後，點擊「5 分鐘上手 SeaJS」，這時瀏覽器彈出腳本錯誤提示，例子顯示不正確。
上面是一段比較好的事實描述（更好的是把錯誤提示也截圖上來），而不要像下面這樣猜測：
SeaJS 在 IE6 下運行不正常，我懷疑是源碼第 213 行有問題。
上面的描述，會讓作者一頭霧水、甚至很惱火。儘量避免猜測性描述，除非你能先描述事實，在事實描述清楚之後，再給出合理的猜測是歡迎的。
對於前端項目來說，如果能提供可重現錯誤的在線可訪問代碼，那是最好不過的。一旦你這麼用心去做了，作者往往也會很用心地立馬幫你解決。
描述目標、而不是過程
經常會有這種情況，提問者在腦袋裡有個更高層次的目標，他們在自以為能達到目標的特定道路上卡住了，然後跑來問該怎麼走。比如
SeaJS 的 parseMap 方法在遇到 map 的多個配置項同時匹配同一個路徑時，應該允許用戶指定是全部生效還是僅第一個匹配的配置項生效。
上面這個問題的背後，提問者實際上想解決的是如何通過 SeaJS 來做版本管理。提問者選擇了通過 map 的方式來實現，但這過程中遇到了問題，因此跑過來繼續怎麼走。然而，如果只是描述過程，往往會把作者也繞進去。
實際情況卻是，提問者選擇的路本身就是一條崎嶇之路，對於要解決的問題，實際上有更好的方式。這種情況下，描述清楚目標，講清楚要幹什麼非常重要。
在描述自己是怎麼做之前，一定要先描述要做什麼。提問題時，What 往往比 How 更重要。
要有具體場景
無論在開源社區，還是微博、知乎等平台上，有一種非常常見的問題：
如何维护 JavaScript 代码？ 如何使用 SeaJS 进行模块化开发？
這類問題還有很多，每每遇到，只能笑笑，然後悄悄地忽略掉。因此這類問題很難回答，就如下面這些問題一樣：
如何才能让生命有意义？ 如何打败淘宝？如何获得吴慧敏的男装照 怎么样才能让柠檬给我钱 怎么样才能在你氢气群里两百个人里对我产生良好的影响
這類提問者，一般比較浮躁，經常對問題本身也沒有經過思考。踏實的提問者，不會讓問題浮在空中無法回答，而會在具體場景中讓問題落地：
我的项目有 20 多个 JS 文件，接下来还会急剧增加。目前遇到以下问题……（省略五百字）…… 请问如何维护？
仔細檢查、確保準確
是人都會犯錯誤，特別是在如此快節奏的互聯網環境下。好不容易把問題描述清楚時，不要急着立刻提交。在提交前，至少保證從頭到尾再仔細閱讀一遍，比如語法錯誤、錯別字、標點符號、排版等等。做到這些，不光是尊重別人，也是尊重自己。
提問後
提交問題後，建議通過郵件等方式訂閱回復。互聯網上最有效的溝通方式是異步溝通，不要期待作者馬上回復，也不要心煩意亂着急地等待。出去看看天，數數雲朵，你會逐步明白什麼是風輕雲淡。
儘可能補充信息
在接收到回復時，仔細閱讀。最經常的情況是，社區回復的，經常不是你想要的。比如
根據你的描述，問題無法重現。能否提供具體使用環境和重現步驟？
這時要淡定。仔細看看自己提交的問題描述是否足夠清晰，如果有可補充的信息，儘量補充，以幫助作者能儘快定位問題。比如
很抱歉，我前面有一步描述不正確，實際情況是我是在 IETester 中運行的……
謙和淡定的交流，不光能幫助你解決問題，還有助於你結交更多朋友。
適當的總結
當問題終於解決時，建議對問題進行總結。可以編輯原帖，也可以通過博客等方式總結。你的總結，會讓遇到同樣問題的朋友們受益，並且對自己的技能也是一種提高。前端業界，無論國內還是國外，有很多牛人之所以成為牛人，很大程度上都是因為有總結思考的好習慣。
不要忘記感謝
最後，記得感謝。很多開源軟件的作者，都是利用業餘時間在創作代碼。你的感謝，匯集許許多多大家的感謝，會讓開源社區充滿愛與力量。