原文作者：Jeff Atwood
作者在Twitter上發的一條短訊：
“我希望我們行業裡有更多的人先去嘗試建立社群，然後再做産品，就像photomatt和WordPress。”
11:28 PM –2012-5-30
譯者注：photomatt.net是由Matt Mullenweg創辦的一個分享圖檔的線上社群。（現在這個網站已經自動重定向到ma.tt。）Matt于2003年建立了WordPress——一種使用PHP語言和MySQL資料庫開發的開源、免費的部落格引擎。目前已經有超過16%的網站在使用WordPress。
大家都知道，面試官是多麼熱衷于問這樣的問題，“你最大的弱點是什麼？”“你曾經犯過最大的錯誤是什麼？”這些問題聽起來可能都是公式化的，甚至都是些陳詞濫調，但是你在回答的時候可要小心了：它們貌似無足輕重，其實不然！
如果有人問我，“在創辦Stack Overflow網站的過程中你犯過最大的錯誤什麼”，我會很坦然，因為我不用費盡心思地去尋找答案。我可以很誠實地告訴大家，我在開發Stack Overflow的第一天就犯了個天大的、非常荒唐的錯誤，而且我還固執地堅持了整整9個月，完全不顧社群裡此起彼伏的抗議。我越陷越深，甚至還寫了一篇長長的部落格去駁斥。
長久以來，我一直有一種很可怕的“搏擊俱樂部”式的觀念：“Stack Overflow網站的第一條規則，就是你别對Stack Overflow說三道四！”畢竟，大家上這個網站來是為了找到志同道合的人一起學習程式設計，而不是讨論一個做得很傻的網站。是這樣嗎？
譯者注：《搏擊俱樂部》（《Fight Club》）是一部美國電影，改編自恰克·帕拉尼克1996年的同名小說，由二十世紀福克斯電影制片公司發行。故事講的是，傑克（一個充滿中年危機意識、非常憎恨自己的生活的人）偶然遇到了賣肥皂的商人泰勒，兩人因緣際會成為了好友，并建立了“搏擊俱樂部”：一個讓彼此不戴護具而互毆的聚會，旨在發洩情緒……
我沒有意識到大家對“元”（meta）的需要。
所謂“元”，就是一個大家讨論自身所處之地的地方。聽起來很費解吧，但是其含義值得我們好好想想。“元”是給那些深切關注社群、也願意更進一步做出貢獻、組織起來并費盡心思去研究怎樣維持和管理社群的人的。是以，我很懊悔！我當初的所作所為，實際上是在告訴那些熱愛Stack Overflow的人們：“滾一邊去！”
回想起來，我真是羞愧難當！
在社群的不斷刺激之下，也在我反複的防守還擊過程中，很慶幸，我最終醒悟了。盡管我們在一開始的測試階段用了一個第三方的“元”站點，但在公測後的10個月，也就是2009年6月最終釋出的時候，我們還是用了自己的域名：meta.stackoverflow。同樣的錯誤絕不再犯第二次，在我們後來做Stack Exchange的時候就注意了——我們為每一個上線的Stack Exchange子網站從一開始就配備了一個“元”。我們現在知道了，“元”的參與是社群有序上司和治理的源泉，我們須培養它，也是以要加以密切的監控。
為了“贖罪”，我也成為了我們自己“元”的頂級使用者。在過去的2年又7個月的時間裡，我将自己埋身在成堆的bug、功能需求和各種讨論中，而支援所有這些的就是我們的“元”。從我的使用者賬号概況裡可以看出，在那段時間裡，我有901天都泡在“元”裡，其實差不多也就是每天都在了！我以自己對“元”的參與度而感到驕傲，好比是得了一塊勳章，而更重要的是，我認識到了我們應該圍繞着使用者開展工作。我們在Stack Exchange上所做的任何一件事都是特意公開的——這跟象牙塔式的開發模式完全是對立的。
這一路走過來，在開發社群軟體和處理社群回報方面，我學到了不少的經驗和教訓。現總結如下：
1．90%的社群回報都是垃圾
讓我們現在就承認吧！在這方面，“史特金定律”是不可能被任何人否定的，無論你是男人、女人、孩子，還是一個社群。“元”社群，我愛死你了；正因為如此，讓我們彼此坦誠相待吧：你們提出的大部分回報和功能需求，其實沒有任何可操作性……需要的話，我可以說出一萬條理由。
譯者注：“史特金定律”（Sturgeon's Law）是科幻作家史特金提出的，其内容是：任何事物，其中90%都是垃圾。以社群網站的内容為例：在社群所有的作品中，90%以上的都是“垃圾”。是以要有能力去蕪取菁。
且慢，别忽略了要點：這也意味着，有另外10%的社群回報是非常棒的！假如你有毅力看上上百條文章，我保證你會發現其中有10條的含金量很高，而就是它們能讓你的網站得到明顯的提升。做好準備吧，若想從一大堆社群回報裡挖掘出“寶石”，你需要花很多時間，而且這時間還不是一般的多！我堅信，每個社群總會有一些足夠聰明的人來制造一定數量的“寶石”，他們常常讓你喜出望外。
2．别抵擋不住誘惑而誤入歧途
當你收到回報和功能需求的時候，你應該立即把它們分成兩大類：
我們需要給這輛轎車安上電動窗！
或者
我們需要給這輛轎車加個貨車車廂！
顯而易見，前者隻是給轎車增加一個合理的配件，而後者試圖改變車輛的基本特性。軟體本身固有的“易于修改的特性”，使得增加功能變得很誘人，但這有時候無異于給轎車加上一個貨車車廂。為什麼不這麼做呢？使用者們會不斷地反問你。貨車多友善呀！真的是這樣嗎？
别掉進陷阱！牢記你當初的使命。轎車加貨車的混合體對于很多人來說都很有吸引力，但是這很可怕，你會最終做出一輛像斯巴魯Brat一樣的車。除非你真的想要做出一輛貨車來，否則，如果使用者提出想要貨車這樣的功能，你最好大方地把他們帶到附近的貨車經銷商那裡，因為他們似乎來錯了地方。
3．坦誠地說出你不想做的事
當看到bug跟蹤系統裡或回報論壇裡有成千上萬條記錄無人問津時，我總是很沮喪。這是社群疏于治理的信号，更為糟糕的是，它折射出了社群裡一種信賴缺失的關系。這很常見，也很可悲。千萬别搞成這樣！
盡管很多時候來自社群的回報是令人讨厭的，但我并不建議你把對他們的厭惡之情赤裸裸地表現出來。那樣隻會顯得你很卑劣。但當你覺得他們提出的請求沒有道理，或者你無法在一個合理的範疇内将它們實作的時候，請你不要羞于“禮貌地”拒絕他們。（當然，你應該總是保留将來改變主意的權力。）毫無疑問，被人拒絕是很傷心的，但被人忽略讓人尤其心灰意冷。我非常非常堅定地相信，隻要你對你的社群待之以誠，他們最終會是以而更加敬重你。
所有的關系都是基于誠實的。如果你不願意誠實地對待你的社群，你憑什麼要求他們來尊敬你呢？他們最終會離你而去……
4．傾聽社群的聲音，但别被他們牽着鼻子走
把“元”社群裡的需求一股腦兒地吸收進你的軟體或者網站中加以實作，這麼做看起來很不錯。“元”的出發點是傾聽來自社群的聲音，然後根據社群回報采取相應的行動，對嗎？遺憾的是，如果你過于直接地對社群回報采取行動，那是非常危險的，它也是很多社群失敗的原因。讓我們一起來看看GitHub的聯合創始人Tom Preston-Werner是怎麼解釋的吧：
我們來看一個這樣的需求：“GitHub應該允許我用FTP的方式把我項目裡的一個文檔站點上傳上去。”其實，這個客戶真正想說的是：“我想要一個簡單的方法來釋出與我項目相關的内容。”隻是他們早已經習慣了現有的東西，是以他們必然以他們熟悉的術語來表達他們的需求。我們本可以按照他們要求的那樣，實作一個糟糕的基于FTP的解決方案。然而，經過我們深入研究之後，我們發現了問題的根本，最終的解決方案是：允許使用者通過往賬号裡加一個Git倉庫來實作内容釋出。這種做法既滿足了功能需求，又不失優雅，堪稱完美。
譯者注：Git是一個分布式的版本控制系統，最初由Linus Torvalds編寫，用作Linux核心代碼的管理。而GitHub可以托管各種Git庫，并提供一個Web界面，使得操作更加簡易。
社群回報是美妙的，但它的作用絕不應該被誇大并濫用，它不能代替你去深刻反思你要做的東西以及你為什麼要這樣做。花點功夫去挖掘潛在的真正需求吧，然後制定出一個合理的産品路線圖。
5．參與并支援你的社群
大概有一半的社群關系都不盡如人意，他們并不在恪守承諾地做着社群認為他們應該做的事情。即便這樣，建議你還是要去積極參與社群，去傾聽，去回應。當Stack Exchange的聯合創始人回複你在“元”裡的發帖時，即使他的回複不能完全達到你的期望，我希望你也能了解，他的行動足以證明了我們對社群的承諾，那就是我們始終跟社群在一起并肩作戰。
不管你現在缺不缺錢用，你都應該熱衷到“元”裡的社群回報或bug報告裡挖掘出稀有的“寶石”。這些“寶石”能讓你的網站或産品更加出色。你應該義無反顧地這麼去做，以促成公衆回報的良性循環：“你所關心的就是我們所關注的，所有事情都在朝着一個好的方向持續得到改進。”
這就是社群的真谛！難道不是嗎？