mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
73 lines
6.3 KiB
Markdown
73 lines
6.3 KiB
Markdown
[#]: subject: "How to make community recognition more inclusive"
|
||
[#]: via: "https://opensource.com/article/22/5/inclusive-community-recognition"
|
||
[#]: author: "Ray Paik https://opensource.com/users/rpaik"
|
||
[#]: collector: "lkxed"
|
||
[#]: translator: "PeterPan0106"
|
||
[#]: reviewer: "wxy"
|
||
[#]: publisher: "wxy"
|
||
[#]: url: "https://linux.cn/article-14590-1.html"
|
||
|
||
如何使社区认可更加包容
|
||
======
|
||
|
||
> 抛开具体的工作量，我们认为所有的贡献都弥足珍贵。当所有社区贡献者都能获得家庭般的赞赏时，他们会更倾向于继续为社区添砖加瓦。
|
||
|
||
|
||
|
||
给予一个优秀的工作足够的认同和赞赏是我作为一个社区管理员最喜欢做的事。我不但有机会能够对贡献者表示感激，同时还能为社区设立一个优秀的榜样。认同和赞赏可以是为了庆祝一个成就，例如有人帮助其他成员加入社区、减少技术债务或者贡献了激动人心的新功能。
|
||
|
||
但是，用来确定贡献量的规则可能会有难以预料的后果。例如某些社区管理员利用如下图所示的图表来表彰贡献，过度地强调了拉取请求（PR）以及对代码库的贡献量。
|
||
|
||
![A bar graph ranking 15 contributors according the the number of PRs merged in a year, ranging from 250 at the top to 50 at the bottom.][2]
|
||
|
||
![A bar graph ranking 10 contributing organizations by number of contributions, ranging from more than 15 to less than 5][3]
|
||
|
||
使用这样的方法进行表彰会产生三个问题。
|
||
|
||
首先，这样过度关注了对代码库的贡献。早年间，开源项目主要吸引开发者参与，所以自然而然许多贡献是围绕代码的。现在，越来越多的非开发者正在积极参与社区项目（例如通过用户组、会议和用户生产的内容），他们的大多数贡献在代码库以外的地方。这些贡献将不会出现在诸如 *年度合并 PR 数量* 这样的表格上。
|
||
|
||
其次，过度关注贡献指标（指那些易于用数字统计的），最终会演变为奖励数量而不是质量，甚至影响力。在上图的 *贡献组织排行榜* 中，大型组织因为具有更多的可用人力，相对于小型组织就会有更为显著的优势。通过对大型组织在数量上的表彰将可能导致小型组织的人感到权利被剥夺了。
|
||
|
||
最后，尽管本意并非如此，但许多人都会把这些数据看做对个人或组织影响力的排名。
|
||
|
||
基于此，我们最好避免仅仅通过指标数量来表彰对社区的贡献。
|
||
|
||
### 令社区表彰更有意义
|
||
|
||
如何让社区表彰更为包容并且能够覆盖不同的贡献形式呢？诸如 Discord、IRC、邮件列表和Slack 等交流渠道可以很好的表明一个成员的活跃度及其感兴趣的领域。例如每当我看到一些人热衷于解答问题或者帮助新用户时，我会十分开心。这些贡献并不会出现在社区的数据板上，但是让这些贡献得到应有的认同和感谢并广为人知是十分重要的。
|
||
|
||
社区数据板显然是开源社区重要的工具。但是我提醒大家不要花费太多时间在建设数据板上。迟早你会发现，不是所有的东西都可以有清晰的标准进行度量，即便你能够想出规则量化一件事，你也依然会发现这些规则具有局限性。
|
||
|
||
为了获取更多的关于贡献的信息，我经常会安排社区成员茶话会。这些对话经常能够告诉我他们做出贡献的原因、有多少工作量以及谁同时也参与进来了等等。
|
||
|
||
当我第一次与他们对话时，我经常听到他们提及找到回馈社区的方法十分重要，而他们也在寻找方法来提供力所能及的帮助。许多人甚至因不能在代码方面做出贡献而感到内疚，而我会向他们强调代码不再是开源唯一重要的东西。有时这些对话能让我有机会接触到同一城市或同一行业的社区成员，或者发现更多共同的兴趣点。维护这些关系将有助于提升归属感。
|
||
|
||
### 令社区表彰更具影响力
|
||
|
||
除了寻找更多的活动形式，我们也可以让这些活动以更具影响力的形式呈现。例如在看到优质贡献时及时赞美。一个快速的感谢回复会比一两个月之后的正式感谢更有效。许多人包括我自己，都会强调给予更为正式而合理的表彰和奖励，但我们应当谨记，奖励并非社区成员贡献的主要动力。认可好的工作并努力去接触贡献者会令贡献者感到受重视。
|
||
|
||
让其他成员参与到认可的过程中也是一个很好的主意。一旦社区达到了一定的规模，便很难事无巨细地知晓一切细节。如果引入一个成员提名机制则会很好地让大家注意到优秀的贡献。如果你的社区拥有十分正式的奖项，例如在年度会议或聚会上颁发的奖项，请让社区成员参与提名和投票。这不仅提供了成员参与进来的平台，也令这些来自成员投票的奖项更有意义。
|
||
|
||
最后给予认同和感谢也是一个认识成员并加深了解的重要机会。有时候颁奖仿佛在进行交易：“你做了某件事，所以我们给你颁发了某个奖励”。多在介绍成员上花些时间，将令成员感到更受重视并加强归属感。
|
||
|
||
### 社区认可令社区更为健康
|
||
|
||
在提高开源社区的多样性、包容性和归属感方面，我们仍有许多工作亟待改善。更好的社区认可将在其中起着不可或缺的作用。确保所有的贡献都受到重视，让每一位贡献者都感到家庭般氛围和赞赏，将鼓励他们继续为社区贡献。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/22/5/inclusive-community-recognition
|
||
|
||
作者：[Ray Paik][a]
|
||
选题：[lkxed][b]
|
||
译者：[PeterPan0106](https://github.com/PeterPan0106)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://opensource.com/users/rpaik
|
||
[b]: https://github.com/lkxed
|
||
[1]: https://opensource.com/sites/default/files/lead-images/world_hands_diversity.png
|
||
[2]: https://opensource.com/sites/default/files/2022-04/annual%20merged%20PRs.png
|
||
[3]: https://opensource.com/sites/default/files/2022-04/top%20contributing%20orgs.png
|