# 人如其文 考慮如下情況：因特網上別人對你的了解都來自你所寫的東西。你或許是一個富有才華、敏銳和領袖氣質的人—但是如果的你的郵件散漫且沒有組織，人們會以為你也是這樣。或者也許你是一個散漫和無組織的人，但沒人會知道這一點，只要你的文字能夠清晰且言之有物。 在寫作上的投入回報巨大。長期自由軟件黑客Jim Blandy說過這樣一個故事： > 回到1993，我為自由軟件基金會工作，正在為GNU Emacs的19版本進行beta測試。我們每周都會發布一個這樣的beta版本，人們會進行測試并回饋我們bug報告。有一個我們都不認識的人，但是完成的工作很好：他的報告總是十分清晰，并能讓我們直接找到問題，而且當他自己提供修正時，也幾乎都是正確的。他是頂尖人物。 > 現在，在FSF可以使用其他人編寫的代碼之前，我們會讓他們準備一些文書工作，將該代碼的版權利潤賦予給FSF。完全獲得陌生人的代碼是處理法律災難的好辦法。 > 所以我給這個家伙發了一份表單，說，“這里是我們需要的一些文書工作，你簽署這一份，讓你的雇主簽另一份，然后我們就可以開始提交你的修正。非常感謝。” > 他回復了一封信息說，“我沒有雇主。” > 所以我說，“很好，那就讓你的大學簽署它并發回來。” > 不久，他又回復了，并說，“很好，實際上，我已經30歲了，與父母一起住。” 因為那個小孩并沒有像30歲的人那樣寫東西，所以沒有人知道他的情況。下面也是讓你的寫作能夠帶來良好印象的一些方法。 ### 結構和格式 不要像編寫手機短信那樣編寫所有的東西。要使用完整的句子，每個句子首字母要大寫，也要根據需要分段。在編寫電子郵件和其他內容時這一點最重要。在IRC或類似的短命論壇上，忽略大小寫或壓縮形式的常見短語也無所謂。只是不要把這個習慣帶到更正式，會持久化保存的論壇中。郵件、文檔、bug報告和其他會永久保存的東西，必須使用標準語法和拼寫，并有一致的敘事結構。并不是因為任何事情都有遵循任意規則的內在特性，而是因為規則并*不是*任意的：他們演化成現在的形式是因為可以讓文本更可讀，因此你應該遵循這些規則。可讀性是令人向往的，并不是因為這樣人們就能夠理解你所寫的，而且是因為這樣可以讓你看起來像是人們可以花時間進行清晰交流的人：也就是值得人們關注的人。 對于個別的電子郵件，有經驗的開源開發者會使用特定的約定： 只發送文本郵件，而不應該是HTML、富文本或其他格式，因為有許多只支持文本的郵件閱讀器。將每行列長格式化為72。列長不要超過80，80已經成為*事實上的*標準終端寬度（也就是會有人使用更寬的終端，但沒有更窄的）。通過將列數設置為*小于*80，可以為其他人回復中的引用字符留出空間，從而不必讓文本強制換行。 *使用真正的換行。*一些郵件程序可以使用一種假的換行，可以讓你編寫的郵件在沒有實際換行時顯示出來有換行。當郵件發送以后，郵件不會有你所以為的換行，他們會非常難看的出現在某些人的屏幕上。如果你的郵件程序使用假換行，應該找一個恰當的設置，可以在編寫郵件時顯示真換行。 當包含屏幕輸出，代碼片段或其他格式化文本時，需要清晰的處理縮進，這樣可以輕易的區分你的敘述和引用的內容。 （當我開始撰寫此書時，我沒有想過編寫這些建議，但是當在許多開源郵件列表中看到了很多人混合文本和其他資源，以至于無法區分開時，我改變了注意。這樣的效果很讓人灰心。這讓他們的文章很難被理解，很明顯也讓這些人看起來有點混亂。） 當引用其他人的郵件時，可以直接在合適的位置插入你的回應，如果需要可以在不同的位置，然后刪節那些在你的郵件不使用的部分。如果你需要為全文進行評述，可以寫在*頂部*（將你的回應置于引用的郵件文本之前）；否則，請首先引述原郵件的相關文本，然后緊跟你的回應。 小心構建新郵件的主題行。這是郵件中最重要的一行，因為它可以讓項目中的其他人決定是否進一步閱讀。現代郵件閱讀軟件可以將相關信息組織成一組線索，并不僅僅是根據共同的主題，而且可以根據其他頭（有時并不顯示）。它遵循了如下原則，如果線索轉移到另一個主題，你可以—也必須—根據回復修改主題行。由于其他郵件頭，線索的完整性得以保全，但是新的主題可以幫助人們獲知主題已經轉移。同樣的，如果你確實希望開始一個新的主題，那么可以發布一個新的郵件，而不是對現有郵件修改主題并回復。否則，你的郵件會仍然分組到你所回復的線程中，因此會讓人們不知道討論的內容已經改變。再次，懲罰不僅僅是所浪費的時間，也會使你使用交流工具的信用受損。 ### 內容 組織良好的郵件會吸引讀者，但是內容可以留住他們。當然，沒有可以確保好內容的固定規則，但是有一些可以讓其更像的原理。 讓事情對你的讀者更簡單。任何一個開源項目都有大量的信息，不能期望讀者熟悉所有的東西—事實上，不可能期望他們知道如何熟悉。所以要盡可能讓你的文章以盡量便利的形式提供給讀者。如果你能夠額外花費幾分鐘在郵件列表歸檔中找出特定線索的URL時，從而減少讀者尋找的麻煩，這樣做非常值得。如果你可以花費5到10分鐘為復雜的線索總結一個結論，從而為人們理解你的文章提供一個上下文環境，那么一定要去做。可以這樣考慮這件事，項目越成功，在任何論壇中的讀者-作者比率越高。如果你的文章被*n*個用戶看到，那么隨著*n*的增大，擴展額外的努力節約其他人的時間就越值得。隨著人們看到你將自己置于這個標準之下，他們也會在自己的交流中與此匹配。理想情況下，會帶來項目整體效率的提升：當人們在*n*個人和一個人這樣努力做出選擇時，大家會選擇前者。 不要使用夸張法。在線發布中的夸大是經典的軍備競賽。例如，一些報告bug的人會擔心開發者不會投入足夠的注意力，所以他們將其描述為嚴重的、會中斷他（以及他的所有朋友/同事/親戚）使用該軟件的問題，而實際上只是一般的不適。但是夸大并不限于用戶—程序員也會在技術討論時也這樣做，特別是當問題是關于他們不認可的某種口味而不是正確性時。 > “這樣做事會讓代碼完全不可讀。 與J. Random的建議相比，這是維護的夢魘。” 當措辭不是如此尖銳，同樣的感情也會變得*更強*： > “這樣也可以工作，但是出于可讀性和可維護性的考慮，并不是理想的方式，我認為。J. Random's的建議避免了這類問題，因為它...” 你不可能完全消滅夸大，一般來說也沒有必要。與其他形式的交流問題相比，夸大并不是對所有人都有害—他只會傷害夸大者。接收者也會做出相應的抵消，每次都會讓發送者損失自己的信用。因此，為了你自己在項目的影響力，請使用溫和的方式。只有這樣，人們在會在你*真的*需要表達強烈觀點時重視你。 編輯兩次。對于任何超過中等長度段落的信息，請在你第一次認為完成之后再從頭到尾檢查一遍。這是所有參加過寫作課程的人會得到的忠告，但是在在線討論中格外重要。因為在線寫作的過程很容易變得非常不連貫（在編寫信息的過程中，你需要回頭檢查其他郵件，訪問特定的網頁，或者運行某個命令捕獲調試信息等），這樣很容易讓你失去敘事的感覺。不連貫編寫的信息，而且在發送以前也不檢查通常會被認為會讓他們的作者懊惱（或者這樣某人會希望）。花時間檢查你發送的內容。你的內容組織的越好，就會有越多的人去閱讀。 ### 基調 在寫過幾千條信息后，你一定會發現自己會趨向于簡潔。這看起來是大多數技術論壇的標準，在本質上沒有任何錯誤。在社會交流中不可接受的簡潔程度則是自由軟件黑客的默認程度。下面是我在一個郵件列表中發表的關于自由內容管理軟件的文章，完全引用： ~~~ 您能更詳細的說一下所遇到的問題嗎？ 可能是： 您使用什么版本的Slash？你能說出原始信息嗎。 你是如何編譯的apache/mod_perl源？ 你嘗試過發布在slashcode.com的Apache 2.0補丁嗎？ Shane ~~~ 這*就是*簡潔！沒有問候，沒有他的名字以外的簽名，整個信息本身只有一系列盡可能緊湊的疑問句。其中的一個祈使語句是隱含的對原始信息的批評。雖然如此，我還是很高興看到Shane的郵件，并沒有因為其簡潔而把他當作一個大忙人。事實僅僅是他們在詢問問題，而不是忽略我的問題，意味著他愿意在這個問題上花更多的時間。 讀者能夠對這種方式作出正面的反應嗎？這不是必須的；這取決于人和上下文。例如，如果某人剛剛承認她犯了一個錯誤（例如寫了一個bug），而你根據以前的經驗知道這個人容易不安全，那么你仍會編寫一個緊湊的回復，你應當確信其中包含一些考慮其感受的內容。你的回復可能很簡短，只有工程師對于形式的分析，和你想的一樣簡潔。但是在最后，應該指明你的簡潔不應該理解為冷漠。例如，如果你要建議如何正確的修正某個bug，應該簽署“好運，<這里是你的名字>”指明你希望他們做好工作而不會發瘋。一個笑臉或其他符號表情通常也足夠安撫你的對話者。 也許像關心參與者所說事情的表面一樣關心其情緒有一些古怪，但是認真的說，情緒影響生產力。由于其他原因情緒也非常重要，但如果僅出于功利原因，我們也能發現不快樂的人會寫出糟糕的軟件。因為大多數電子媒介的本性所限，通常沒有關于人們情緒的明顯線索。你應該根據這些猜測：a)大多數人在那種形勢下的感覺，b)你在以前的交流中對參與者的了解。一些人采用更簡單的態度，僅根據表面處理事情，如果沒有參與者直接說出自己的感受，則別人沒有義務像他已經說出那樣去對待她。我不會選用這個方法，有如下一些原因。首先，人們在真實生活中并不是這樣處事的，為什么要在線上這樣？其次，因為所有的互動發生在公共論壇，人們會比私密情況下更加控制自己的感情表達。更精確的說，他們通常希望對某人直接表達感情，例如感激和憤怒，而不是直接的內部情緒，例如不安和驕傲。當知道其他人會關注到他的心理狀態時，大多數人會工作的更好。通過在細微線索上投入注意力，你可以在大多數時候猜到問題，并且能夠鼓舞人們比原來更深入地參與。 我不是說，你的角色是團隊治療師，一直通過觸及別人的情緒來幫助每個人。但是通過對于個人行為長期模式的觀察，即使你們從來也沒有面對面，也會獲得像單個人之間的感受。而且通過對于自己文章基調的敏感性，你會為自己對于其他人情緒的影響力感到吃驚，最終會使項目受益。 ### 識別無禮 開源文化的一個定性特征是對于何為無禮的特色定義。下面敘述的習慣不只是出現在開源軟件開發，也不只是在一般軟件—在數學、嚴密科學或工程紀律中也并不陌生—自由軟件，由于其跨領域性，并有不斷涌入的新來者，許多不熟悉這種環境的人將要面對這些習慣。 我們先從*不*無禮開始。 技術批評，即使很直接且沒有鋪墊，也不是無禮的。實際上，這可以看作是一種諂媚：批評者在說話，說明目標值得重視，值得花時間研究。可以說，平靜只是簡單的忽視某人的文章，花費更多時間批評它則是更多的贊美（當然，除非批評升級到了*非理性的*攻擊或其他形式的明顯無禮）。 遲鈍、樸實的問題，例如前面Shane的對我的郵件，也不是無禮。在其他環境下這種提問會看起來有些冷酷，玩弄文字或甚至是嘲弄，通常是有意的嚴重行為，而且除了盡快釋放出信息，沒有隱藏的日程表。著名的技術支持問題“你的電腦插電了嗎？”是經典的案例。支持者確實需要知道你的電腦是否插電，經過一段時間的這類工作，他已經厭倦了在問題前點綴一些有禮貌的奉承（“請原諒，我只是要問一些問題以排除一些可能性。有一些可能很基礎，請暫時忍受一下我...”）。 此刻，他沒有再做任何鋪墊，只是直接問：到底插電了沒有？類似的問題會一直在自由軟件郵件列表中被問起。目的不是冒犯接收者，而是快速排除大多數明顯的（或許也是最常見的）解釋。理解這種行為并作出響應的接收者會因為大度的態度獲得成功。不能正確反應的接收者也不會受到譴責。這只是文化的沖突，不是某人的過錯。要和藹的解釋你的問題（或批評）沒有隱藏的含義；只是希望讓（或傳遞）信息盡可能有效率，無他。 那么怎樣是無禮？ 詳細的技術評論一種形式的諂媚，同理，如果不能提供高質量批評也可以看作是一種冒犯。我不是說僅僅忽略某人的工作，是提議、代碼變更、新問題添加或任何事。除非您之前明確的承諾會有詳細的反應，不做任何反應也沒有錯。人們只會假設你沒有時間回答。但是如果你*要*反應，就要用心：花時間真的去分析，提供合適的實在例子，在以前的歸檔中發掘相關的文章等等。或者如果你沒有時間花費這種精力，但仍需要寫一些簡短的回應，然后在信息中公開說明缺陷（“我知道有一個對應的問題，不過我沒時間去搜索，對不起”）。主要是認識到文化標準的存在，通過履行承諾或公開的告知缺乏時間實現。無論何種方式，標準都會被加強。即使不能達到標準，不要在同一時間解釋*為什么*你沒有達到，這樣做好像是說這個主題（以及那些參與者）不值得你花費時間。更好地是通過簡潔而不是懶惰展示你的時間的價值。 也有一些其他形式的無禮，當然，但是大多數并不只存在于自由軟件開發，而且常識足夠引導你避免他們。如果你還沒有看，可以看[Chapter?2, *起步*](# "Chapter?2.?起步")的[the section called “防無禮于未然”](# "防無禮于未然")。 ### 面容 人腦中有一塊專門負責識別面容的區域。它被非正式的稱為“梭型面容區域”，其能力大多來自天生，而不是學習得到。因為識別單個人是至關重要的生存技巧，所以我們演化出了專門的硬件負責這個工作。 互聯網基于的交流從心理上說有些古怪，因為需要許多無法用自然，原始的方法識別對方的人，進行緊密的合作：首先是面部識別，也有聲音和姿勢等。為了彌補這種不足，可以在所有地方使用一致的*屏幕名稱*。他應該是你郵件地址的一部分（@之前的部分），你的IRC用戶名，你的版本庫提交名，你的問題跟蹤用戶名等等。這個名字就是你的在線“面容”：一段可以同你的真實面容起到同樣效果的標識字符串，盡管他不是，但至少模擬了內置在電腦的硬件。。 屏幕名稱應該是你真實姓名的直覺（例如我的是“kfogel”）展示。在一些情況中，會伴隨你的完整名，例如在郵件頭中： ~~~ From: "Karl Fogel" <kfogel@whateverdomain.com> ~~~ 實際上，這個例子有兩件事。就像前面提到的，屏幕名稱用直覺方式匹配真實姓名。但是，真實姓名是*真實的*。而不是某種修飾的名稱： ~~~ From: "Wonder Hacker" <wonderhacker@whateverdomain.com> ~~~ Paul Steiner有一副著名的卡通，刊登在1993年6月5日的*紐約客*，里面是一條狗登錄到了電腦終端并陰險的與另一個人交談：“在因特網上，沒人知道你是一條狗。”這類思想的背后是自我夸大，這些有些俏皮的在線標識的人給了他們自己—好像被叫做“Wonder Hacker”*就*真的是神奇黑客了。但是事實沒有改變：即使沒人知道你是條狗，你還是條狗。一個幻想的在線標識不會打動讀者。相反，他們會認為你只是形象而沒有本體，或者僅僅是你是不安全的。在所有的交流中使用真實姓名，或者因為某些原因需要匿名，那么就請起一個完全像真名的名稱，并一直用下去。 為了保持你的在線面容的一致，有一些方法可以讓他更吸引人。如果你有正式的頭銜（例如”博士“、”教授“和”導師“），不要炫耀，除非與對話內容相關，最好不要提及。作為一般的黑客之道，特別是自由軟件文化，認為這些頭銜是多余和不安全的標志（例如叫獸和磚家）。當然，如果這些頭銜是作為標準的簽名出現在每封郵件，不要把這個當作支持你在討論中位置的工具—這種嘗試必定事與愿違。你需要尊敬人的家伙，而不是尊敬這些頭銜。 說到簽名區：要保證短小有意義，或者更好的情況是沒有簽名區。避免大段的法律免責聲明出現在每個郵件的結尾，特別是當他們表達的感情與自由軟件項目的參與精神不匹配時。例如，如下是我參與的一個公開郵件列表中的某個用戶每個文章都會出現的的經典流派： ~~~ IMPORTANT NOTICE If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to the statement below or contact the sender. This communication is from Deloitte & Touche LLP. Deloitte & Touche LLP is a limited liability partnership registered in England and Wales with registered number OC303675. A list of members' names is available for inspection at Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR, United Kingdom, the firm's principal place of business and registered office. Deloitte & Touche LLP is authorised and regulated by the Financial Services Authority. This communication and any attachments contain information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please return it with the title "received in error" to IT.SECURITY.UK@deloitte.co.uk then delete the email and destroy any copies of it. E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so. When addressed to our clients, any opinions or advice contained in this e-mail and any attachments are subject to the terms and conditions expressed in the governing Deloitte & Touche LLP client engagement letter. Opinions, conclusions and other information in this e-mail and any attachments which do not relate to the official business of the firm are neither given nor endorsed by it. ~~~ 對于只想偶爾詢問一個問題的人，如此巨大的免責聲明雖然有點傻，但是沒有任何永久的傷害。但是，如果某人希望活躍的參與到項目中，這個法律的陳詞濫調會開始一個更潛在的影響。它會釋放出兩個潛在的破壞性的信號，這個人對于自己的工具沒有完全的控制權力—他陷入了某個公司的郵件系統，這個系統會在每個郵件結尾添加討厭的信息，而他無法繞過—其次，他對自己參與的自由軟件活動只有有限或沒有任何組織支持。誠然，組織明顯沒有禁止他在公共列表發表文章，但可以讓他的文章看起來明顯的不受歡迎，仿佛泄漏機密信息的風險必須排在第一位。 如果你所在的組織堅持對所有外發郵件添加這種簽名區，應該考慮申請一個免費郵件帳號，例如，[gmail.google.com](http://gmail.google.com/)、[www.hotmail.com](http://www.hotmail.com/)或[www.yahoo.com](http://www.yahoo.com/)，然后作為你在項目中的地址。 [[22](#)] 關于這個主題有許多有趣的學術研究；例如Gutwin、Penner和Schneider所著的*Group Awareness in Distributed SoftwareDevelopment*。這篇論文曾經在網上出現過一段時間，之后消失，后來又在[http://www.st.cs.uni-sb.de/edu/empirical-se/2006/PDFs/gutwin04.pdf](http://www.st.cs.uni-sb.de/edu/empirical-se/2006/PDFs/gutwin04.pdf)再次出現。所以，如果這個地址無法訪問，請通過搜索引擎搜索新地址。