對 SegmentFault 社區提問標準的一些解釋

有心的用戶應該發現最近 SegmentFault 問答的審覈趨向嚴格，甚至一些已經正常展現的問題都會因質量問題提示做者修改。隨着社區用戶的增加，新進入用戶的習慣正逐漸衝擊着以前社區造成的默契，咱們的問答質量出現了必定程度的降低。這對整個社區的運營提出了挑戰，咱們不但願發生劣幣驅逐良幣的情況，所以有必要在這個問題上達成新的共識。

應該說 SegmentFault 的提問一直都是有具體的標準的（https://segmentfault.com/faq#...），可是在具體理解的時候每一個人都會產生誤差，爲了儘可能縮小這個誤差，咱們約定以下幾個提問的原則：

1. 回答者優先
2. 考慮後來者

回答者優先

當你理解了回答者優先的原則，就會天然而然地理解咱們的運營規範，甚至你都不須要時刻記住這些規範，由於它們只是保證這一原則的最低要求。

什麼是回答者優先？簡而言之，就是你在提問的時候要優先考慮回答者可否清晰準確地知曉你要表達的意思，咱們在審覈的時候也是以這一條標準作爲最優先的準則。提問者怎麼判斷呢？很簡單，把本身置於回答者的位子上去審視一下你的問題，看看作爲回答者的你是否能夠經過這些表述知曉題意。

以這條原則爲出發點，咱們會對存在如下狀況的問題說不：

1. 問題表述過於簡略，每每就一句話甚至一個標題的。（舉例：標題是「如何實現一個淘寶同樣的網站？」，內容是：「如題」）
2. 問題中徹底沒有本身的觀點，也就是傳說中的伸手黨。伸手黨的存在主要有兩大害處，第一，你沒有說出已經嘗試過哪些方法，沒有儘可能爲回答者排除錯誤狀況，會大大下降回答者的答題效率。第二，你的付出過少，沒法達到回答者的內心預期，會大大影響回答者的答題積極性。用通俗的話說就是，你本身都不重視本身的事情，其餘人又憑什麼去幫你呢？
3. 問題的排版過於混亂。從語法上講，咱們並不認爲 Markdown 語法比你手上要寫的任何編程語言語法更加複雜。而混亂的排版至少代表你並不重視這個問題，也不重視回答者的感覺。不少人沒有把代碼用 Markdown 包裹起來，咱們也視爲排版混亂。
4. 沒有代碼或者用圖片代替了代碼。這是一個最近比較突出的問題，代碼勝千言，準確簡短的描述配上必要的代碼，比你說一大堆廢話要好得多，咱們已經看到了無數可愛的回答者在問題下方的評論中呼喚代碼。與不貼代碼相比，用代碼截圖來代替代碼走入了另外一個誤區，讓咱們仍是站在回答者的角度，當你面對上百行沒頭沒尾的代碼時，怎麼去調試它們呢？你想讓回答者浪費本身寶貴的時間，照着大家的圖片一個字一個字的敲進去麼？因此，當你要這麼作的時候，想想本章的標題「回答者優先」。在這裏，還有一個比較特殊的狀況，就是錯誤信息算不算代碼，可不能夠用截圖代替？在這裏，給出明確的答覆：算。大部分的錯誤信息，包括瀏覽器的出錯，c, java等預編譯語言的運行時錯誤，都是一個簡單的文本，你能夠直接用鼠標選中複製，用 Markdown 的代碼塊語法包裹後附加到問題裏。這樣能夠大大方便回答者定位錯誤。

考慮後來者

考慮後來者能夠說是咱們建立這個社區的一大目的，咱們之因此讓你們的問題能夠公開討論，就是爲了下降在開發領域的信息不對稱，讓後來者少走彎路。爲了作到這一點，咱們提倡你們：

1. 標題應該直接地表達問題的中心思想，若是你是由於運行時拋出某些錯誤而提問，你能夠直接寫「爲何JAVA運行時拋出xxxx異常?」。而不要寫什麼「一個關於JAVA的問題？」，請問作爲一個後來者，我能從你的標題裏得到什麼重要的信息呢？若是這則問題被搜索引擎索引了，後來者遇到同類問題是怎麼搜索的呢？你們想一想大家搜問題，是否是喜歡把錯誤信息直接丟到搜索框裏，那麼怎樣纔算一個有用的問題就不言而喻了。
2. 不要用圖片代替代碼，不要用圖片代替代碼，不要用圖片代替代碼！圖片裏的內容不能被任何搜索引擎檢索到，你的問題會變成信息海洋裏的垃圾沉沒水底，這不是咱們作爲社區所提倡的。
3. 用好標籤。標籤的做用在於更好地組織內容，這也是爲了方便後來者。因此首先不要濫用，你的標籤必定要跟問題相關。其次，標籤不是用來描述問題的，不要本身創造一些描述性的語言作爲標籤。一般選擇標籤就選擇這個問題所涉及到的技術就能夠了，並且儘可能至少使用一個大的語言標籤，好比「php, java, c, javascript」 等等。

一些措施

俗話說「用霹靂手段,顯菩薩心腸」，咱們的菩薩心腸在上面已經告訴你們了。爲了保證這些目的可以達到，咱們將採起一系列措施。除了在審覈時咱們會嚴格按照標準來執行以外，咱們還鼓勵你們共同維護社區的秩序。你們能夠經過評論來提醒一些違規的內容，或者使用舉報和建議關閉功能。

咱們針對把代碼截圖到圖片裏的行爲，專門開發了自動掃描機器人，它會最大程度地去監控這一行爲，一旦發現這一狀況會提醒你修改問題。若是在一小時內沒有修改的話，這個問題會被提交人工審覈後處理。注意：機器人可能存在誤判行爲，若是你肯定你的內容沒有存在這種狀況，請放心交給咱們人工審覈便可，咱們會及時處理。

寫在最後

當咱們在6年前創立 SegmentFault 的時候，願景是作一個高質量的中文技術問答社區。固然如今 SegmentFault 上承載的不止有問答的內容，但它依然是整個社區重要的組成部分。常常有人向咱們抱怨國內技術社區的討論氛圍，思想浮躁，問題質量差，伸手黨盛行等等。當咱們體量比較小的時候，咱們老是以提升素質還須要時間之類的理由來安慰本身或者他人。而當咱們逐漸成長爲國內技術問答領域一支重要力量以後，咱們已經沒法逃避肩上的責任，所以咱們但願帶領整個社區一塊兒進步，共同打造一個屬於咱們本身的技術家園。

更多閱讀

• 關於【提問】和【寫做】你須要知道的一些點
• 那位提問的開發者，能否組織好你的提問和代碼再把問題丟出來啊？—— 如何有條理地提問
• 程序員，你真的會提問嗎？
• 一篇技術文章合格的標準