# 榮譽 榮譽是自由軟件世界的主要貨幣。無論人們怎樣說他參與項目的動機，我不知道有哪個開發者會樂于匿名，或以其他人的名義的做這些事。有一些有形的原因：一個人在一個項目的名聲大體上決定了他的影響力，參與一個開源項目也會間接的帶來金錢，因為某些雇主希望尋找簡歷。也有一些無形的原因，或許更加強大：人們只希望被賞識，本能的尋找被別人識別的標志。榮譽的希望是項目一個最重要的動機。當小的貢獻被認可，人們會返回作出更多。 協作開發軟件的一項重要特性是（見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")）保持何人何時做了何事的精確記錄。如果存在，請盡可能使用現有的機制確保榮譽精確的分配，要根據貢獻的本性特別處理。不要僅僅寫下"感謝J. Random <jrandom@example.com>"，作為替代可以在日志信息中寫為"感謝J. Random jrandom@example.com>的bug報告以及對于重現bug的描述"。 在Subversion中，對于bug報告者的榮譽，我們有一個非正式的但是一致的政策，如果有發起的問題，則在問題中記錄，如果沒有發起問題，則在修正該bug的提交日志信息中記錄。對于提交編號14525之前的Subversion日志進行了一個快速調查，發現10%的提交包含了某人名字和郵件地址的榮譽信息，通常是報告或分析該提交的bug修正的人。請注意，這些人與實際作出提交的開發者不同，這些開發者的名字已經自動記錄到了版本控制系統。在目前Subversion的80位完全和部分提交者中，有55位在他們成為提交者之前，曾經在提交日志（通常多次）中被記錄過榮譽。當然這并不是說，被記錄榮譽是繼續參與的一個因素，但至少給了人們知道自己的貢獻如何被認可的氛圍。 很重要的一點是區分常規的感謝和特別感謝。當討論特定代碼片段或其它某人的貢獻時，最好能夠感謝他們的工作。例如，假設“Daniel最近對于增量代碼的變更意味著我們現在可以實現特性X”，需要同時幫助人們識別你所談論的變更并感謝Daniel的工作。另一方面，僅僅單獨感謝Daniel對于增量代碼的變更無法達到即刻的實踐目的。它不會增加任何信息，因為版本控制系統和其他機制已經記錄了他所做的變更。感謝所有人的所有工作則會分散最終的信息，因為感謝的內容是他與所有默認的、背景的評論級別相比的突出程度。當然這并不意味著你不需要感謝大家。只需要確保不會陷入榮譽通貨膨脹。遵循下面的指導會有所幫助： - 這個論壇越是短暫，越應該對在這里自由表達感謝感到自由。例如， 在IRC對話中感謝某人傳來的bug修正很好，在郵件中旁敲側隱也很不錯。但是最好不要單獨發一個感謝某人的郵件，除非是真的不同尋常的壯舉。很有可能，不要因為表達感激弄亂項目的網頁。一旦你開始這樣做，便會永遠無法清理，也無法停止。而且*絕不要*將感謝置于代碼的注釋之中；這將會分散注釋主要目的的注意力，注釋本來的作用是幫助讀者理解代碼。 - 一個人參與項目越少，就更應該對她的所作所為提出感謝。這似乎與直覺并不一致，但是表示感謝的態度適用與某人作出的貢獻，超出了你對他的預期。因此，一直感謝常規貢獻者的日常工作表現了對他們所做工作的較低的預期。如果說有效果，可能是反效果！ 這個規則有一些偶爾的例外。如果感謝某人完成了預期角色，而這個角色反復包含了許多臨時的、緊張的努力，則這是可以接受的。一個標準的例子是發布管理員，他在每次發布時都會投入緊張的工作，但其他時間則陷入休眠（作為發布管理員休眠，在有些情況下—它還可以是活躍的開發者，但那是另外一回事了）。 - 就像批評和榮譽，感謝必須是特定的。不要因為偉大而感謝，即使確實如此。要為他們所做的超出尋常的事情表示感謝，如果能恰當的說出他們的偉大之處也能額外加分。 通常情況下，在確保某個人的貢獻已經被識別出來，和確保整個項目是一個團隊，而不是一些榮耀的個體時，總會有些緊張。只要意識到這種緊張，并且強調表現團隊，以及未能掌握的事物。