如何向開源社群提問題

玉伯也叫射鵰發表於2013-02-22

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

　　本文以開源類庫 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 社群，當你建立一個問題時，會自動提供以下模板：

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

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

　　適當的總結

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

　　不要忘記感謝

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

　延伸閱讀

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

相關文章