如何向開源社區提問題

如何向開源社區提問題

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

本文以開源類庫 SeaJS 爲例，說說我心目中的最佳實踐。

提問前

遇到問題時，內心都很着急。在決定向開源社區提交問題前，最好先作作如下功課：

嘗試從官方文檔中找到答案

確保本身閱讀過至少一次官方文檔。這樣在遇到問題時，若是能回憶起隻言片語，就能夠再去讀一遍相關文檔，問題每每也就解決了。

Google 是你的朋友

對於成熟的開源項目，你遇到的問題，極可能別人也遇到過。這時經過 Google、StackOverflow 等網站的搜索服務，能夠幫你快速定位並解決問題。永遠記住，地球上的你並不孤單，包括你遇到的問題。

挖掘 Bug 寶藏

開源軟件通常都會有本身的 Bug 管理方案，好比 WebKit、V八、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 中運行的……

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

適當的總結

當問題終於解決時，建議對問題進行總結。能夠編輯原帖，也能夠經過博客等方式總結。你的總結，會讓遇到一樣問題的朋友們受益，而且對本身的技能也是一種提升。前端業界，不管國內仍是國外，有不少牛人之因此成爲牛人，很大程度上都是由於有總結思考的好習慣。

不要忘記感謝

最後，記得感謝。不少開源軟件的做者，都是利用業餘時間在創做代碼。你的感謝，聚集許許多多你們的感謝，會讓開源社區充滿愛與力量。

延伸閱讀

• 如何有效地報告 Bug
• 提問的智慧
• 回答的智慧

---

最後的最後，若是你承認這篇文章，歡迎以各類形式轉載。你的傳播，能讓整個開源社區更美好。

 

原文地址：https://github.com/seajs/seajs/issues/545