荣誉

# 荣誉 荣誉是自由软件世界的主要货币。无论人们怎样说他参与项目的动机，我不知道有哪个开发者会乐于匿名，或以其他人的名义的做这些事。有一些有形的原因：一个人在一个项目的名声大体上决定了他的影响力，参与一个开源项目也会间接的带来金钱，因为某些雇主希望寻找简历。也有一些无形的原因，或许更加强大：人们只希望被赏识，本能的寻找被别人识别的标志。荣誉的希望是项目一个最重要的动机。当小的贡献被认可，人们会返回作出更多。 协作开发软件的一项重要特性是（见[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修正很好，在邮件中旁敲侧隐也很不错。但是最好不要单独发一个感谢某人的邮件，除非是真的不同寻常的壮举。很有可能，不要因为表达感激弄乱项目的网页。一旦你开始这样做，便会永远无法清理，也无法停止。而且*绝不要*将感谢置于代码的注释之中；这将会分散注释主要目的的注意力，注释本来的作用是帮助读者理解代码。 - 一个人参与项目越少，就更应该对她的所作所为提出感谢。这似乎与直觉并不一致，但是表示感谢的态度适用与某人作出的贡献，超出了你对他的预期。因此，一直感谢常规贡献者的日常工作表现了对他们所做工作的较低的预期。如果说有效果，可能是反效果！ 这个规则有一些偶尔的例外。如果感谢某人完成了预期角色，而这个角色反复包含了许多临时的、紧张的努力，则这是可以接受的。一个标准的例子是发布管理员，他在每次发布时都会投入紧张的工作，但其他时间则陷入休眠（作为发布管理员休眠，在有些情况下—它还可以是活跃的开发者，但那是另外一回事了）。 - 就像批评和荣誉，感谢必须是特定的。不要因为伟大而感谢，即使确实如此。要为他们所做的超出寻常的事情表示感谢，如果能恰当的说出他们的伟大之处也能额外加分。 通常情况下，在确保某个人的贡献已经被识别出来，和确保整个项目是一个团队，而不是一些荣耀的个体时，总会有些紧张。只要意识到这种紧张，并且强调表现团队，以及未能掌握的事物。