使用軟體產品，或多或少都會遇到問題。對於商業產品，我們可以諮詢客服尋求幫助。對於公司自己研發的產品，我們可以直接請教專家同事。但對於開源軟體，在遇到問題時，如何才能及時有效地尋求幫助呢？

本文以開源類庫 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 系統很重要。

還有各個開源類庫的 Issues 庫，比如 SeaJS 的是：seajs/issues

最不好的途徑是

• QQ 、阿里旺旺、微信等群組。這些群組主要是用來工作或休閒的。對開源專案來說，在這些地方提問，作者一般不會關注，效率非常低。
• 微博、Facebook 等社交網路。不少人在微博上通過 at 或私信詢問 SeaJS 問題，這些我經常看不到。看到了，也不情願回覆。微博是扯淡、交流情感的地方，一般是寫程式碼寫累了，才去逛逛，很少會有在社交網路上回答技術問題的心情。

通過正確的途徑提交問題，一般可以讓你的問題得到及時準確的回覆。

使用明確、有意義的標題

抱著平和對等的心態，找到合適的途徑後，就得靜下心來將遇到的問題寫成文字。書寫文字不是一件簡單的事情，我們可以從遵循一些簡單的規則開始。

首先是標題要簡潔清晰，要言之有物。比如

我遇到了一個 Ajax 問題
SeaJS 在我的瀏覽器上執行不了

上面的標題很糟糕，光看標題作者無法知道發生了什麼事。當開源社群的問題很多時，上面這類標題，經常會讓作者直接忽視或將優先順序降到很低。更妥當的標題是

Ajax 請求未返回正確的 responseXML
SeaJS 2.0 在 IE6 上執行時拋錯

明確、有意義的標題，可以幫助作者確定問題具體是什麼型別、預估需要多少時間解決、是否現在馬上解決等。一個好的標題，也有利於社群知識的沉澱和後期搜尋。標題有如一個人的顏面衣著，雖然不是關鍵，但在嘈雜的資訊社群中，這很重要。

遵循良好的模板

如果社群提供了問題模板，一定要仔細看下。比如 Google Code 社群，當你建立一個問題時，會自動提供以下模板：

遵循這個模板去描述問題，經常能省很多事。作者一般也非常歡迎通過模板提交的問題。如果社群沒有提供模板，也可以自己遵循以上模板來提交。

下面針對問題內容，具體說說一些需要注意的點。

語法正確、格式清晰

雖然我們不是作家，但正確的語法、清晰的格式，可以讓讀者賞心悅目，也就更有心情幫你一起思考解決問題。

對於很多需要程式碼來描述的問題，要尤其注意格式，比如

可讀性不如

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 中執行的……

謙和淡定的交流，不光能幫助你解決問題，還有助於你結交更多朋友。

適當的總結

當問題終於解決時，建議對問題進行總結。可以編輯原帖，也可以通過部落格等方式總結。你的總結，會讓遇到同樣問題的朋友們受益，並且對自己的技能也是一種提高。前端業界，無論國內還是國外，有很多牛人之所以成為牛人，很大程度上都是因為有總結思考的好習慣。

不要忘記感謝

最後，記得感謝。很多開源軟體的作者，都是利用業餘時間在創作程式碼。你的感謝，彙集許許多多大家的感謝，會讓開源社群充滿愛與力量。

延伸閱讀

最後的最後，如果你認可這篇文章，歡迎以各種形式轉載。你的傳播，能讓整個開源社群更美好。