document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

RP

Browse Source 
@PeterPan0106
https://linux.cn/article-14590-1.html
This commit is contained in:
Xingyu Wang 2022-05-13 23:48:58 +08:00
parent 8594564b36
commit 53f2df22be
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
translated/talk/20220502 How to make community recognition more inclusive.md → published/20220502 How to make community recognition more inclusive.md
View File

@ -3,40 +3,40 @@
[#]: author: "Ray Paik https://opensource.com/users/rpaik"
[#]: collector: "lkxed"
[#]: translator: "PeterPan0106"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
[#]: reviewer: "wxy"
[#]: publisher: "wxy"
[#]: url: "https://linux.cn/article-14590-1.html"
如何使社区认可更加包容
======
抛开具体的工作量，我们认为所有的贡献都弥足珍贵。当所有社区贡献者都能获得家庭般的赞赏时，他们会更倾向于继续为社区添砖加瓦。
![Global citizens unite to improve housing with open design and development][1]
（图源： Opensource.com）
> 抛开具体的工作量，我们认为所有的贡献都弥足珍贵。当所有社区贡献者都能获得家庭般的赞赏时，他们会更倾向于继续为社区添砖加瓦。
给予一个优秀的工作足够的认同和赞赏是我作为一个社区管理员最喜欢的事。我不但有机会能够对贡献者表示感激，同时还能为社区设立一个优秀的榜样。认同和赞赏可以是为了庆祝一个成就，例如有人帮助其他成员加入社区、减少技术债务或者贡献了激动人心的新功能。
![](https://img.linux.net.cn/data/attachment/album/202205/13/234756gi7q42f2mgz5mg44.png)
但是，用来确定贡献量的规则可能会有难以预料的后果。例如某些社区管理员利用如下图所示的图表来表彰贡献，过度地强调了pull requests以及对代码库的贡献量。
给予一个优秀的工作足够的认同和赞赏是我作为一个社区管理员最喜欢做的事。我不但有机会能够对贡献者表示感激，同时还能为社区设立一个优秀的榜样。认同和赞赏可以是为了庆祝一个成就，例如有人帮助其他成员加入社区、减少技术债务或者贡献了激动人心的新功能。
但是，用来确定贡献量的规则可能会有难以预料的后果。例如某些社区管理员利用如下图所示的图表来表彰贡献，过度地强调了拉取请求（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]
（图源： Ray Paik, CC BY-SA 4.0）
![A bar graph ranking 10 contributing organizations by number of contributions, ranging from more than 15 to less than 5][3]
（图源： Ray Paik, CC BY-SA 4.0）
使用这样的方法进行表彰会产生三个问题。首先，这样过度聚焦了对代码库的贡献。早年间，开源项目主要吸引开发者参与，所以自然而然许多贡献是围绕代码的。现在，越来越多的非开发者正在积极参与社区项目（例如通过用户组、会议和用户本身生产的内容），他们的大多数贡献在代码库以外的地方。这些贡献将不会出现在诸如*年度合并PR数量*这样的表格上。
使用这样的方法进行表彰会产生三个问题。
其次，过度聚焦贡献指标（指那些易于用数字统计的），最终会演变为更大的数量甚至超越了更好的质量甚至是影响力。在上图的*贡献组织排行榜*中，大型组织因为具有更多的可用人力，相对于小型组织就会有更为显著的优势。通过对大型组织在数量上的表彰将可能导致小型组织感到权利被剥夺了。
首先，这样过度关注了对代码库的贡献。早年间，开源项目主要吸引开发者参与，所以自然而然许多贡献是围绕代码的。现在，越来越多的非开发者正在积极参与社区项目（例如通过用户组、会议和用户生产的内容），他们的大多数贡献在代码库以外的地方。这些贡献将不会出现在诸如 *年度合并 PR 数量* 这样的表格上。
最终，尽管本意并非如此，但许多人都会把这些数据看做对个人或组织影响力的排名。
其次，过度关注贡献指标（指那些易于用数字统计的），最终会演变为奖励数量而不是质量，甚至影响力。在上图的 *贡献组织排行榜* 中，大型组织因为具有更多的可用人力，相对于小型组织就会有更为显著的优势。通过对大型组织在数量上的表彰将可能导致小型组织的人感到权利被剥夺了。
最后，尽管本意并非如此，但许多人都会把这些数据看做对个人或组织影响力的排名。
基于此，我们最好避免仅仅通过指标数量来表彰对社区的贡献。
### 令社区表彰更有意义
如何让社区表彰更为包容并且能够覆盖不同的贡献形式呢？一些通信频道例如Discord、IRC、mailing list和Slack可以很好的表明一个成员的活跃度及其感兴趣的领域。例如每当我看到一些人热衷于解答问题或者帮助新用户时，我会十分开心。这些贡献并不会出现在社区的数据板上，但是让这些贡献得到应有的认同和感谢并广为人知是十分重要的。
如何让社区表彰更为包容并且能够覆盖不同的贡献形式呢？诸如 Discord、IRC、邮件列表和Slack 等交流渠道可以很好的表明一个成员的活跃度及其感兴趣的领域。例如每当我看到一些人热衷于解答问题或者帮助新用户时，我会十分开心。这些贡献并不会出现在社区的数据板上，但是让这些贡献得到应有的认同和感谢并广为人知是十分重要的。
社区数据板显然是开源社区重要的工具。但对于花费在建设数据板的时间上，我锱铢必较。迟早你会发现，不是所有的东西都可以有清晰的标准进行度量，即便你能够想出规则量化一件事，你也依然会发现这些规则具有局限性。
社区数据板显然是开源社区重要的工具。但是我提醒大家不要花费太多时间在建设数据板上。迟早你会发现，不是所有的东西都可以有清晰的标准进行度量，即便你能够想出规则量化一件事，你也依然会发现这些规则具有局限性。
为了获取更多的关于贡献的信息，我经常会安排社区成员茶话会。这些对话经常能够告诉我他们做出贡献的原因、有多少工作量以及谁同时也参与进来了等等。
@ -48,7 +48,7 @@
让其他成员参与到认可的过程中也是一个很好的主意。一旦社区达到了一定的规模，便很难事无巨细地知晓一切细节。如果引入一个成员提名机制则会很好地让大家注意到优秀的贡献。如果你的社区拥有十分正式的奖项，例如在年度会议或聚会上颁发的奖项，请让社区成员参与提名和投票。这不仅提供了成员参与进来的平台，也令这些来自成员投票的奖项更有意义。
最后给予认同和感谢也是一个认识成员并加深了解的重要机会。有时候颁奖仿佛在进行交易：“你做了X，所以我们给你颁发了Y”。多在介绍成员上花些时间，将令成员感到更受重视并加强归属感。
最后给予认同和感谢也是一个认识成员并加深了解的重要机会。有时候颁奖仿佛在进行交易：“你做了某件事，所以我们给你颁发了某个奖励”。多在介绍成员上花些时间，将令成员感到更受重视并加强归属感。
### 社区认可令社区更为健康
@ -61,7 +61,7 @@ via: https://opensource.com/article/22/5/inclusive-community-recognition
作者：[Ray Paik][a]
选题：[lkxed][b]
译者：[PeterPan0106](https://github.com/PeterPan0106)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出