标签 开源社区 下的文章

那些被你领入社区的人,有一天也会向其他人伸出援手。

开源领导者可以通过创造归属感、提供机会和表示支持来为新来者创造包容性社区。他们了解提交代码和与其他社区成员建立联系的复杂性。创造包容性社区可以建立信誉并获得影响力。这种经验对于想要参与但不知道从哪里开始的贡献者来说是无价的。

几年前,当我开始管理一个活跃于 Linux 内核社区的团队时,我发现自己因为没有任何内核经验而感到处境困难。复杂的代码库、庞大的电子邮件归档和高风险的交流让我感到害怕。当我团队中的新内核开发人员表达了类似的感受时,我意识到我的感觉在团队里普遍存在。对于那些支持贡献者或想自己做出贡献的人来说,入门的道路并不总是清晰的,甚至可能感觉遥不可及。

4 个策略建立包容性领导力

开源领导者可以通过为那些希望融入社区的人创造途径来发挥自己的影响力。本文涵盖的策略可应用于正式的 指导辅导 关系,但同样适用于日常互动。在培养环境的包容性时,看似微不足道的交流往往会产生最重要的影响。

怀着好奇心接近了解新人

经验较少或来自非传统背景的人可能会以意想不到或不同的方式解决问题。在应对这些差异时,如果用妄加评论或批评的方式,可能会在知识曲线通常很陡峭的社区中创造一个不安全的学习环境。例如,Linux 内核的长期贡献者了解社区丰富的历史,这意味着他们不需要明说就能理解社区的决策和反应。新的贡献者必须积累这方面的知识,但只有当他们感到安全,并愿意冒必要的风险来发展自己的技能时,他们才能有效地做到这一点。

开源领导者可以通过带着好奇心去接近新人来支持他们学习。你可以问他们这样的问题,“你能帮我理解一下你为什么采用这种方法吗?”而不是直接宣布提议的解决方案“对或错”。问题打开了一个继续学习的对话,而不是关闭那些值得探索的重要方面的想法。这个过程也拓宽了领导者的视野,他们可以通过考虑新的观点来学习。

发现并分享学习机会

开源领导者可以确定适合其他人的项目,使他们可以获得技术专长和学习社区流程。在为他人创造机会的同时,领导者也为自己创造了更多机会。这是因为他们有更多时间探索新的尝试,同时通过分派任务继续推进他们的工作。随着领导者的成长,他们帮助周围的人取得成功的能力变得与他们的直接贡献一样重要。

要知道 失败 是学习的一部分,因此你要考虑找一些新手失败后不会造成严重后果的项目。例如,在 Linux 内核中,代码库的某些部分的小改动可能会造成灾难性的后果。考虑可以实现小小的胜利的项目,以帮助新来者在没有高风险的情况下建立信心并感到掌控感。通过会议、电子邮件论坛或任何涉及如何参与到社区里的宣传活动分享这些想法,让人们更容易获取到这些信息。

展现你脆弱的一面

拥有更多的经验并不意味着你知道一切。通常情况下,即使是与我共事过的最有经验的 Linux 内核贡献者也会被未知子系统中的新挑战击败。经验不足的社区成员通常会认为经验丰富的社区成员已经了解了一切。但是,经验就是要善于找出你不知道的东西。如果你处于权威地位或者被认为是专家,你可以通过分享个人挣扎和坚持的经验来表现你脆弱的一面,这样做可以鼓励那些和你有着类似感受的人。

为他人做担保

向你的人脉介绍新来的成员。在激发他们兴趣的领域里,让新成员和在这个领域内具有专业知识的社区成员建立联系。在公共论坛上说出他们的名字,并称赞他们所做的出色工作。作为受人尊敬的领导者,你的支持可以帮助他们在社区内建立联系和信任。

通过树立社区包容性,我们可以拥有丰富多样的社区。我希望开源领导者会考虑这些建议,因为你提拔到社区的人未来的某天也会同样向别人伸出援手。

(题图:MJ:inclusive environment community illustration in high resolution, very detailed


via: https://opensource.com/article/23/2/open-source-leaders-inclusive-environment

作者:Kate Carcia Poulin 选题:lkxed 译者:XiaotingHuang22 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

研究一下这个框架,来建立你自己的开源项目的数据分析。

在数据分析的黄金时代,开源社区也不能免俗。大家都热衷于将一些华丽的数字放到演示幻灯片上,但如果你掌握了正确的分析方法,这些信息可以为你带来更大的价值。

或许你认为作为一名 数据科学家,我会告诉你数据分析和自动化能为你的社区决策提供信息。但实际上,情况恰恰相反。利用数据分析来构建你现有的开源社区知识,吸收其他的知识,并发现潜在的偏见和没有思考过的观点。你或许是实施社区活动的专家,而你那些同事则是代码方面的专家。当你们每个人都在自己的知识背景下将信息可视化时,你们都可以从这些信息中受益。

让我们来面对现实吧。每个人都有一千零一件事情要做,而且总感觉一天的时间永远不够用。如果需要几个小时才能得到你的社区的答案,你就不可能有足够的精力去解决这些事情。但是,花时间创建一个全面发展的可视化项目,可以帮助你时刻掌握你所关心的社区的不同方面,这就将你从精疲力尽中解放了出来。

随着“数据驱动”思维的盛行,围绕开源社区的信息宝库可能是一种祝福,也可能是一种诅咒。下面我将分享一些方法,告诉你如何从数据干草堆中挑出有价值的信息。

你的预期是什么?

当考虑一个指标时,首先要明确你想提供的观点。以下是几个可能涉及的概念:

告知性和影响性的行动: 你的社区是否存在某个领域尚未被理解?你是否已迈出第一步?你是否试图确定特定方向?你是否正在衡量现有倡议的效果?

暴露需要改进的领域和突出优势: 有时你想宣传你的社区,突出它的优势,特别是在试图证明商业影响或为项目宣传时。然而,当涉及到向社区内部传递信息时,你通常需要从一堆指标中精准的找到你们的缺点,以此来帮助你们改进。虽然突出优点并非不可取,但需要在适当的时间和地点。不要把优势指标作为社区内部的拉拉队,告诉每个人都有多棒,而是要与外界分享,以获得认可或推广。

社区和商业影响: 数字和数据是许多企业的语言。但是这可能使得为你的社区进行宣传并真正展示其价值变得异常困难。数据可以成为用他们的语言说话的一种方式,并展示他们想看到的东西,以使你数据背后的潜在含义能够被有效转达。另一个角度是对开源的整体影响。你的社区是如何影响他人和生态系统的?

这些观点并非非此即彼,而是相互关联的。适当的框架将有助于创造一个更深思熟虑的衡量标准。

数据科学和机器学习的工作流程

当人们谈论通用的数据科学或机器学习工作时,通常会描述这样的工作流程。我将重点关注第一步,即编写问题和度量标准,并简要提及第二步。从数据科学的角度来看,这个演示可以被视为这个步骤的一个案例研究。这一步有时会被忽视,但你的分析的实际价值始于此。你不能一天醒来就知道要看什么。从理解你想知道什么和你所拥有的数据开始,逐步实现更加深度的数据分析。

3个开源数据分析用例

以下是您在开源数据分析过程中可能遇到的三种不同场景。

场景 1:现有数据分析

假设你开始进行分析,并且已经知道你将要研究的内容对你或你的社区是有用的。那么你该如何提高分析的价值呢?这里的想法是建立在“传统”的开源社区分析基础之上。假设你的数据表明,在项目的整个生命周期内,你共有 120 个贡献者。这是你可以放在幻灯片上的价值,但你不能从中做出决策。从仅有一个数字到获得洞见,逐步采取措施。例如,你可以从相同的数据中将贡献者分为活跃和流失的贡献者(那些已经有一段时间没有做出贡献的贡献者),以获得更深入的了解。

场景 2:社区活动的影响测量

目标和影响

针对聚会、会议或其他任何社区外联活动,你如何看待你的影响力和目标?这两个步骤实际上互相影响。一旦你确定了活动的目标,就要确定可以用什么来检测效果。这些信息有助于设定活动的目标。在活动开始时,很容易陷入模糊的计划而非具体的计划的陷阱中。

场景3:形成新的影响分析区

新的分析区

当你从头开始进行数据分析时,就会出现这种情况。前面的例子是这个工作流程的不同部分。这个工作流程是一个不断发展的循环;你可以随时进行改进或扩展。基于这个概念,以下是你应该经历的必要步骤。在本文的后面,将会有三个不同的例子,展示这种方法在现实世界中的应用。

第一步:分解关注区和视角

首先,想象一下魔法 8 球——你可以问任何问题,摇一摇,就能得到答案的玩具。考虑你的分析领域。如果你能立即得到任何答案,那会是什么?

接下来,考虑数据。从你的魔法 8 球问题中,哪些数据源可能与问题或关注领域有关?

在数据背景下,哪些问题可以回答,让你更接近你提出的魔法 8 球问题?需要注意的是,如果你试图将所有的数据汇集在一起,你必须考虑到所做出的假设。

第二步:将问题转化为指标

以下是第一步中每个子问题的处理过程:

  • 选择所需的具体数据点。
  • 确定可视化以实现目标分析。
  • 假设这些信息的影响。

接下来,引入社区提供反馈并触发迭代开发过程。这个协作部分可能就是真正的魔力所在。最好的想法通常是在将一个概念带给某个人时产生的,会激发他们的灵感,这是你或他们无法想象的。

第三步:分析实践

这一步是你开始处理你所创建的指标或可视化的影响。

首先要考虑的是,这个度量标准是否符合当前对社区的了解。

  • 如果:是否有假设得出的结果?
  • 如果不是:你需要进一步调查,是否这是一个潜在的数据或计算问题,或者只是先前被误解的社区的一部分。

一旦你确定你的分析足够稳定,可以开始在信息上实施社区倡议。当你正在进行分析以确定下一步最佳步骤时,你应该确定衡量倡议成功的具体方法。

现在,观察这些由你的指标提供信息的社区倡议。确定是否可以用你之前建立的成功衡量指标观察到影响。如果没有,可以考虑以下几点:

  • 你是否在衡量正确的事情?
  • 倡议战略是否需要调整?

分析区的例子:新贡献者

魔法 8 球问题是什么?

  • 如何分析哪些人为持续的贡献者?

我有什么数据可以纳入分析区和魔法 8 球问题?

  • 仓库存在哪些贡献者的活动,包括时间戳?

现在你有了这些信息和一个魔法 8 球问题,把分析分成几个子部分执行。这个想法与上述步骤 2 和 3 相关。

子问题 1: “人们是怎么进入这个项目的”

这个问题的目的是先看看新的贡献者在做什么。

数据: GitHub 上的首次贡献随时间推移的数据(议题、PR、评论等)。

每季度首次贡献图表

可视化: 按季度划分的首次贡献条形图。

潜在的意义: 在你与其他社区成员交谈后,进一步检查按季度细分的信息,以及贡献者是否为重复贡献者或仅仅是路过。你可以看到人们进来的时候在做什么,以及这是否能告诉你他们是否会留下来。

每季度路过贡献图标

从这些信息中了解到的可以采取的行动。

  • 目前的文档是否能够帮助到最常见的新手?你能不能更好地帮助和支持新人朋友,这将有助于他们中更多的人留下来?
  • 是否有一个贡献领域在整体上并不常见,但重复贡献者却集中在这个区域?也许 PR 是重复贡献者的一个常见区域,但大多数人却不在这个区域工作。

行动项目:

  • 给 “好的第一个问题” 贴上一致的标签,并将这些问题链接到贡献文档中。
  • 在这些问题上添加一个 PR 伙伴。

子问题 2: “我们的代码库真的依赖于路过的贡献者吗?”

数据: GitHub 的贡献数据。

贡献者类型随时间变化的图表

可视化: “贡献总额:按路过和重复贡献者的贡献进行细分。”

根据这一信息可能采取的行动。

  • 这个比例是否达到了项目的目标?很多工作都是由路过贡献者完成的吗?这是否是一种未被充分利用的资源,项目是否没有尽到自己的责任来吸引他们?

分析:吸取教训

数字和数据分析并不是“事实”,它们可以支持任何观点。因此,在处理数据时,内部怀疑者应该非常积极,并进行反复迭代,以带来真正的价值。你不希望你的分析只是一个 “yes man”,因此花点时间退一步,评估你所做的假设。

如果一个指标只是指出了调查的方向,那也是一个巨大的胜利。你不可能看清或想到所有的事情,兔子洞可以是一个好事,对话的起点可以把你带到一个新的地方。

有时,你想测量的东西恰恰不在那里,但你也许能得到有价值的细节。不要假设你有所有的拼图碎片来获得你最初问题的准确答案。如果你开始强迫一个答案或解决方案,你会把自己带入一条由假设引领的危险道路。为分析的方向或目标的改变留出空间,可以让你获得比最初的想法更好的洞察力。

数据只是是一种工具,并不是标准答案,它可以汇集原本无法获得的见解和信息。将你想知道的东西分解成可管理的小块,并在此基础上进行分析,这是最重要的部分。

开源数据分析是一个很好的例子,说明你必须对所有的数据科学采取谨慎态度。

  • 主题领域的细微差别是最重要的。
  • 通过“问什么/答什么”的工作过程经常被忽视。
  • 知道“问什么”可能是最难的部分,当你想出一些有洞察力和创新的东西时,这比你选择的任何工具都要重要。

如果你是一个没有数据科学经验的社区成员,正在寻找开始的地方,我希望这些信息能告诉你,你在这个过程中是多么重要和宝贵。你带来了社区的洞察力和观点。如果你是一个数据科学家或实施指标或可视化的人,你必须倾听你周围的声音,即使你也是一个活跃的社区成员。关于数据科学的更多信息列在本文的最后。

总结

把上面的例子作为建立你自己的开源项目的数据分析的框架。对你的结果有很多问题要问,知道这些问题和它们的答案可以把你的项目引向一个令人兴奋和富有成效的方向。


via: https://opensource.com/article/22/12/data-scientists-guide-open-source-community-analysis

作者:Cali Dolfi 选题:lkxed 译者:Chao-zhi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

作为一个开源项目的成员,你可以做很多事情来帮助新手找到为项目作出贡献的方式。

当有人刚开始为开源做贡献时,最好从对新手友好的故障和议题开始。但在他们修复故障之前,他们必须要能够找到这类问题。作为一个开源项目的成员,你可以做很多事情来帮助新手找到为项目贡献的方式。

鉴于此,AnitaB.org 开源社区 优先考虑让我们的社区做到对新手友好。我们提倡包容性,确保不同经验和水平的贡献者都可以参与进来,并且他们的贡献不止限于跟编程有关。

我最近在 Upstream 2021,即 Tidelift 活动中介绍了我们在 AnitaB.org 上所做的一些社区工作,该活动启动了“维护者周”,这是一个为期一周的开源维护者庆祝活动。在活动中我讨论了我们策略的三个主要部分:

  • 我们如何沟通
  • 项目和议题
  • 开源项目

我们如何沟通

透明度是开源的重要组成部分,我们将透明度原则应用于我们的沟通方式。实际上,这意味着我们所有的社区会议都是公开进行的,并且影响我们设置 Zulip 聊天的方式以及我们提供文档的方式。

开放会议

任何人都可以加入我们的会议,并讨论与我们社区相关的话题。他们可以参与讨论或者旁听。会议相关信息在我们的社区日历中都可以找到。在这些通话中我们通常只使用语音聊天,我们发现这可以让人们在参与时感觉更自在。

我们举办以项目为中心的会议和一些分类的会议。会议上,来自不同领域的人们可以讨论同一个项目并帮助改进我们的流程。偶尔,我们会有“ 自由提问 Ask Me Anything (AMA)”会议,任何人都可以来问任何与开源相关的问题。

所有会议我们都会在共享文档中进行记录,并在 我们的 Zulip 中共享摘要和文档链接。

我们的 Zulip 聊天

开源 Zulip 聊天平台是我们的主要社区交流渠道,虽然我们也在 Github 的评论区讨论议题和 拉取请求 Pull Request (PR)。一般来说,我们禁用了私人消息以确保我们尽可能透明。对于这条规则,我们只有少数例外,那些私人聊天是管理员在处理我们运行程序的后勤工作所用的。我们发现这种方法更受欢迎,它还使我们能够更清楚公共聊天中的违规行为。

我们在 Zulip 聊天室分享所有会议摘要,包括讨论的要点、行动项目和文档。这些听起来好像是些显而易见的要求,但我一直惊讶于很多开源项目并不提供会议笔记,所以 Zulip 可以让那些没有参加会议的人也随时了解情况。

在 Zulip上,我们讨论项目路线图,回答社区的问题和疑问,并积极促进人们通过不同的方式方法和在不同的场景下做出自己的贡献。有时我们为贡献者的成就而庆祝 —— 无论是为了突出他们测试或者审查的第一个拉取请求,还是强调我们志愿者所做的出色工作。

文档

我们尽量保持关于我们流程的开放文档,例如常见问题解答,以便这些社区成员可以按照自己的节奏和时间了解社区。这是为了让他们在联系我们之前了解我们的工作方式以及我们从事的工作类型。

项目和议题

关于我们的项目和议题管理,我们鼓励通过多种方式做出贡献,我们为新手专门创建特定的议题,并尝试让项目的设置变得简单。

多种贡献的方式

我们努力创建需要不同贡献的问题,例如文档、测试、设计和外展。这是为了让任何人 —— 无关他们的经验水平和兴趣领域 —— 都能做出贡献。这样能够帮助社区参与进来,而且我们发现它使成员能够从一些省力但有价值的任务开始一步步做出贡献。

我们提倡的贡献类型有:

  • 不同复杂性的编程任务。
  • 质量保证任务 —— 贡献者可以测试我们的应用程序或拉取请求并报告错误。
  • 社区成员可以参与讨论的设计会议。此外,创建模型和重新设计我们应用程序某些部分的机会,并探索改进用户体验。
  • 外展任务,我们主要在 Zulip 上推广,我们建议在我们的 Medium 出版物上发表博客,介绍他们的开源经验和他们的贡献。
  • 文档任务,可以包括一般社区文档或我们在 Docusaurus 上的项目文档。

仅限新手的问题

我们将一些议题标记为“仅限新手”。这些问题适用于尚未为议题存储库做出贡献的人。为议题做标签还使我们能够让人们在贡献者大量涌入时开始他们的开源之旅,例如,在 谷歌编程之夏(GSoC) 申请期间。

有时,这些可能是“唾手可得的果实”,可以让他们熟悉作出贡献和提交拉取请求的过程。

简单的项目设置

我们也很在意为我们的项目提供新手友好的安装设置。我们注意到最活跃的项目通常是最容易设置的。我们知道,为你不熟悉的项目做出贡献可能需要付出很多努力并且关乎贡献体验的成败。

我们尝试提供有关如何在多个操作系统上运行我们项目的说明。在过去,我们有一些项目有单独的说明,可以在 Unix 环境下运行,我们注意到贡献者在 Windows 上运行这些项目有些困难。自那以后我们不断进行改进,以避免贡献者在 Zulip 上寻求帮助时出现混乱。

我们根据贡献者的经验,一直在改进我们最活跃的项目之一 mentorship-backend 的自述文件。新手在这个项目中遇到的困难之一是设置与配置电子邮件帐户相关的部分环境变量,以使后台功能能够发送电子邮件。但是,由于此功能对于本地开发并不重要,因此默认情况下,我们将电子邮件设置设为可选,以便将电子邮件打印到终端,而不是发送给用户。这种方法仍然使贡献者可以看到这些电子邮件。与此更改类似,我们将 SQLite 数据库 作为本地开发的默认设置,以避免对 Postgres 数据库进行额外设置,虽然我们在部署版本中会使用到 Postgres。

我们注意到,一些贡献者在为我们的 bridge-in-tech-backend 项目做出贡献时觉得很困难,该项目的设置很复杂,并且包含的步骤比 mentorship-backend 多得多。自从我们在一个开源项目中注意到这一点以来,我们一直在探索如何改进其结构。

对于我们的大多数项目,我们还提供应用程序的实时体验版本或打包版本,以便贡献者无需设置即可测试项目。这有助于我们为那些对开发设置不感兴趣或不熟悉的贡献者提供一种方式,来尝试我们应用程序的最新版本,并通过报告发现的任何错误来做出贡献。我们在 质量保证指南 中放了这些应用程序的链接。

开源计划

我们在社区中组织了两个主要计划:开源黑客(OSH)(一个为期一个月的项目)和 Open Source Ambassadors(一个为期六个月的项目)。

开源黑客(OSH)

在此计划中,我们在多个类别的贡献中创建议题 —— 文档、编码、外展、测试和设计(类似于 谷歌的 Code-in 竞赛)。 参与者可以为每个类别至少贡献一次并获得电子证书。一个议题可能包含多个类别,并且无需合并拉取请求也能使贡献有效。

我们为这个计划选取几个项目,请导师们集思广益为参与者创造议题。项目开始后参与者可以认领议题并开始作出贡献。导师们会支持帮助并审查他们的贡献。

这种方法鼓励贡献的多样性,并欢迎任何人,无论他们的编码能力如何,都可以在友好和不怕出错的环境中做出贡献。

开源大使

在此计划中,我们从社区中选择大使,理想情况下他们将涵盖我们旨在促进的每一类贡献。至今该计划已启动了两次。

该计划旨在让成员通过回答社区的议题、协助贡献者参与并为他们指定的类别宣传来帮助管理项目和计划。

第一个计划举行时我们接受了所有的申请者。我们评估了社区成员的兴趣所在,并为那些想要做出贡献但最初不敢踏出第一步的人提供了一个体系。

第一个计划的举办给了我们很多启发。因为我们的活动中既有经验丰富的开源贡献者和社区成员,也有初来乍到缺乏经验的新手,因此项目的执行要求管理员进行大量的管理工作。一些社区大使信心十足准备好进一步采取新措施,而其他大使则需要更多支持。到了第二个,我们决定缩减该计划,只接受那些已经熟悉社区、可以领导倡议和项目并帮助我们培训新人的贡献者。

第二个计划中形成了正反馈循环。那些在第一个计划中还是新手的大使们,通过为上一个项目做出贡献并且从项目经验中学习之后能够做到轻松带领项目。

这种方法的改变使管理员能够更加专注于支持大使团队,帮助他们传播我们的使命,并继续让我们的社区对新手友好,并指导更多人做出贡献。

总结

这些计划帮助我们提高了对开源贡献和回馈的不同方式的认识。通过它们,我们发现志愿者通过管理项目和举办公开会议来提供帮助,这有助于管理社区并为我们的贡献者提供指导。

尽管我们得到了贡献者的良好反响,并帮助人们做出了他们的第一个贡献,但我们仍有很大的改进空间。我们将继续改进我们项目的设置和贡献指南,以改善贡献者的体验。我们还将继续专注于确保我们的组织始终拥有并推动不同类别的问题,促进包容性,以便任何有意愿做出贡献的人都能出自己的一份力。


via: https://opensource.com/article/21/8/beginner-open-source-community

作者:Isabel Costa 选题:lujun9972 译者:XiaotingHuang22 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

如果想让开源社区繁荣发展,管理者需要达到透明度的五个层次。

 title=

开源社区的管理者必须意识到社区有五个层次的透明度,这对于建设繁荣发展的开源社区来说至关重要。

本文将详细介绍各个层次及其目标与作用。不过首先,我想谈一谈透明度对开源社区的重要性。

为什么开源社区需要保证透明度?

  • 透明能够增进社区成员之间的信任,促进合作。
  • 开放是社区合作和交流的前提。
  • 只有在开放透明的环境下,开源工作才能避免矛盾与冲突。
  • 社区管理者需要向参与者报告社区情况。
  • 向成员公开社区各项情况,营造信任氛围,有利于社区健康发展。

透明度的五个层次

层次一:发布源码

在这一层次,社区需要遵循 OSI 认可的许可证,在 Git 等公开的版本控制系统上发布源码。

层次一的目标在于创建开源项目。

  • 建立开源社区,理应达到这一层次。因为没有公开源代码,也就无所谓开源项目。
  • 开源项目的核心便是参与者们编写的源码,并在 OSI 批准的许可证下授权。
  • 公开的版本控制系统能够促进合作,使得每一位开发者都能了解项目情况,理解合作模式。

层次二:发布社区指南

达到这一层次,需要发布相关文档以及资源。也可通过组织活动来指导社区成员。

层次二的目标在于为一个开源项目建立和发展一个开源社区。

  • 建立一个活跃的社区需要的不仅仅是源代码。
  • 公开项目开展方式和贡献方式,能够吸引更多的开发者参与到项目当中。
  • 为了推动社区的发展,管理者可能需要举办一些重要活动,并为贡献者们筹办一些特殊的活动。

层次三:继往开来

到了这个层次,管理者有必要分享自己对于社区的见解,发布项目进展情况报告。

层次三的目标在于继往开来,确保社区进入后续阶段后能够更上一层楼,实现长远发展。

  • 随着开源社区的发展,社区内的情况将会越来越难以把握。
  • 公开社区活动,让成员意识到自己的付出能够为公众所见,为公众所识。
  • 在这一层次,无论是报告还是分析,发布的时间并不固定,使用的工具也无定法。

层次四:掌握社区的动态

这一层次就在于倾听社区声音:通过观察社区活动,关注项目发展;跟进软件开发进度,据此采取合适的应对措施。

层次四的目标在于保持科学严谨的态度,持续把握社区的发展情况及发展轨迹,引导社区朝着下一个层次迈进。

  • 建立报告机制,运用分析工具,掌握社区动态。
  • 将社区的各项活动与社区成员的反响与基线和社区内的其他活动进行比较。
  • 坚持倾听社区声音,形成对于社区更深刻的见解。

层次五:维护社区,长久发展

最后一个层次就是依据社区各项指标,提高社区成员的参与度。

层次五的目标在于制定行之有效、能够产生积极影响的决策方案,让开发者更好地参与社区项目。

  • 适当调整系统,以适应社区各项指标的变动。
  • 跟进这些变动,理解它们是如何通过各项指标和数据分析体现出来的。
  • 针对社区维护者与开发者,制定服务等级协议和问责制度,为其设立参与度目标,确保项目整体顺利进行。

总结

开源社区管理者需要做到上述五个层次,保证透明度,才能构建起一个繁荣发展的社区。


via: https://opensource.com/article/22/2/transparency-open-source-communities

作者:Emilio Galeano Gryciuk 选题:lujun9972 译者:aREversez 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这比较复杂。

作为一个经常管理软件开发团队的人,多年来我一直关注度量指标。一次次,我发现自己领导团队使用一个又一个的项目平台(例如 Jira、GitLab 和 Rally)生成了大量可测量的数据。从那时起,我已经及时投入了大量时间从记录平台中提取了有用的指标,并采用了一种我们可以理解的格式,然后使用这些指标对开发的许多方面做出更好的选择。

今年早些时候,我有幸在 Linux 基金会遇到了一个名为 开源软件社区健康分析 Community Health Analytics for Open Source Software (CHAOSS)的项目。该项目侧重于从各种来源收集和丰富指标,以便开源社区的利益相关者可以衡量他们项目的健康状况。

CHAOSS 介绍

随着我对该项目的基本指标和目标越来越熟悉,一个问题在我的脑海中不断翻滚。什么是“健康”的开源项目,由谁来定义?

特定角色的人认为健康的东西可能另一个角色的人就不会这样认为。似乎可以用 CHAOSS 收集的细粒度数据进行市场细分实验,重点关注对特定角色可能最有意义的背景问题,以及 CHAOSS 收集哪些指标可能有助于回答这些问题。

CHAOSS 项目创建并维护了一套开源应用程序和度量标准定义,使得这个实验具有可能性,这包括:

  • 许多基于服务器的应用程序,用于收集、聚合和丰富度量标准(例如 Augur 和 GrimoireLab)。
  • ElasticSearch、Kibana 和 Logstash(ELK)的开源版本。
  • 身份服务、数据分析服务和各种集成库。

在我过去的一个程序中,有六个团队从事于不同复杂程度的项目,我们找到了一个简洁的工具,它允许我们从简单(或复杂)的 JQL 语句中创建我们想要的任何类型的指标,然后针对这些指标开发计算。在我们注意到之前,我们仅从 Jira 中就提取了 400 多个指标,而且还有更多指标来自手动的来源。

在项目结束时,我们认定这 400 个指标中,大多数指标在以我们的角色做出决策时并不重要。最终,只有三个对我们非常重要:“缺陷去除效率”、“已完成的条目与承诺的条目”,以及“每个开发人员的工作进度”。这三个指标最重要,因为它们是我们对自己、客户和团队成员所做出的承诺,因此是最有意义的。

带着这些通过经验得到的教训和对什么是健康的开源项目的问题,我跳进了 CHAOSS 社区,开始建立一套角色,以提供一种建设性的方法,从基于角色的角度回答这个问题。

CHAOSS 是一个开源项目,我们尝试使用民主共识来运作。因此,我决定使用 组成分子 constituent 这个词而不是利益相关者,因为它更符合我们作为开源贡献者的责任,以创建更具共生性的价值链。

虽然创建此组成模型的过程采用了特定的“目标-问题-度量”方法,但有许多方法可以进行细分。CHAOSS 贡献者已经开发了很好的模型,可以按照矢量进行细分,例如项目属性(例如,个人、公司或联盟)和“失败容忍度”。在为 CHAOSS 开发度量定义时,每个模型都会提供建设性的影响。

基于这一切,我开始构建一个谁可能关心 CHAOSS 指标的模型,以及每个组成分子在 CHAOSS 的四个重点领域中最关心的问题:

在我们深入研究之前,重要的是要注意 CHAOSS 项目明确地将背景判断留给了实施指标的团队。什么是“有意义的”和“什么是健康的?”的答案预计会因团队和项目而异。CHAOSS 软件的现成仪表板尽可能地关注客观指标。在本文中,我们关注项目创始人、项目维护者和贡献者。

项目组成分子

虽然这绝不是这些组成分子可能认为重要的问题的详尽清单,但这些选择感觉是一个好的起点。以下每个“目标-问题-度量”标准部分与 CHAOSS 项目正在收集和汇总的指标直接相关。

现在,进入分析的第 1 部分!

项目创始人

作为项目创始人,我关心:

  • 我的项目对其他人有用吗?通过以下测量:

    • 随着时间推移有多少复刻?

      • 指标:存储库复刻数。
    • 随着时间的推移有多少贡献者?

      • 指标:贡献者数量。
    • 贡献净质量。

      • 指标:随着时间的推移提交的错误。
      • 指标:随着时间的回归。
    • 项目的财务状况。

      • 指标:随着时间的推移的捐赠/收入。
      • 指标:随着时间的推移的费用。
  • 我的项目对其它人的可见程度?

    • 有谁知道我的项目?别人认为它很整洁吗?

      • 指标:社交媒体上的提及、分享、喜欢和订阅的数量。
    • 有影响力的人是否了解我的项目?

      • 指标:贡献者的社会影响力。
    • 人们在公共场所对项目有何评价?是正面还是负面?

      • 指标:跨社交媒体渠道的情感(关键字或 NLP)分析。
  • 我的项目可行性程度?

    • 我们有足够的维护者吗?该数字是随着时间的推移而上升还是下降?

      • 指标:维护者数量。
    • 改变速度如何随时间变化?

      • 指标:代码随时间的变化百分比。
      • 指标:拉取请求、代码审查和合并之间的时间。
  • 我的项目的多样化 & 包容性如何?

    • 我们是否拥有有效的公开行为准则(CoC)?

      • 度量标准: 检查存储库中的 CoC 文件。
    • 与我的项目相关的活动是否积极包容?

      • 指标:关于活动的票务政策和活动包容性行为的手动报告。
    • 我们的项目在可访问性上做的好不好?

      • 指标:验证发布的文字会议纪要。
      • 指标:验证会议期间使用的隐藏式字幕。
      • 指标:验证在演示文稿和项目前端设计中色盲可访问的素材。
  • 我的项目代表了多少价值

    • 我如何帮助组织了解使用我们的项目将节省多少时间和金钱(劳动力投资)

      • 指标:仓库的议题、提交、拉取请求的数量和估计人工费率。
    • 我如何理解项目创建的下游价值的数量,以及维护我的项目对更广泛的社区的重要性(或不重要)?

      • 指标:依赖我的项目的其他项目数。
    • 为我的项目做出贡献的人有多少机会使用他们学到的东西来找到合适的工作岗位,以及在哪些组织(即生活工资)?

      • 指标:使用或贡献此库的组织数量。
      • 指标:使用此类项目的开发人员的平均工资。
      • 指标:与该项目匹配的关键字的职位发布计数。

项目维护者

作为项目维护者,我关心:

  • 我是高效的维护者吗?

    • 指标:拉取请求在代码审查之前等待的时间。
    • 指标:代码审查和后续拉取请求之间的时间。
    • 指标:我的代码审核中有多少被批准?
    • 指标:我的代码评论中有多少被拒绝或返工?
    • 指标:代码审查的评论的情感分析。
  • 我如何让更多人帮助我维护这件事?

    • 指标:项目贡献者的社交覆盖面数量。
  • 我们的代码质量随着时间的推移变得越来越好吗?

    • 指标:计算随着时间的推移引入的回归数量。
    • 指标:计算随着时间推移引入的错误数量。
    • 指标:错误归档、拉取请求、代码审查、合并和发布之间的时间。

项目开发者和贡献者

作为项目开发者或贡献者,我关心:

  • 我可以从为这个项目做出贡献中获得哪些有价值的东西,以及实现这个价值需要多长时间?

    • 指标:下游价值。
    • 指标:提交、代码审查和合并之间的时间。
  • 通过使用我在贡献中学到的东西来增加工作机是否有良好的前景?

    • 指标:生活工资。
  • 这个项目有多受欢迎?

    • 指标:社交媒体帖子、分享和收藏的数量。
  • 社区有影响力的人知道我的项目吗?

    • 指标:创始人、维护者和贡献者的社交范围。

通过创建这个列表,我们开始让 CHAOSS 更加丰满了,并且在今年夏天项目中首次发布该指标时,我迫不及待地想看看广泛的开源社区可能有什么其他伟大的想法,以及我们还可以从这些贡献中学到什么(并衡量!)。

其它角色

接下来,你需要了解有关其他角色(例如基金会、企业开源计划办公室、业务风险和法律团队、人力资源等)以及最终用户的目标问题度量集的更多信息。他们关心开源的不同事物。

如果你是开源贡献者或组成分子,我们邀请你来看看这个项目并参与社区活动!


via: https://opensource.com/article/19/8/measure-project

作者:Jon Lawrence 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

今天的消息,又挣扎了两年的《Linux Journal》,宣布倒闭了。他们宣布

2019 年 8 月 7 日,Linux Journal 关闭了大门。所有员工都被解雇了,公司没有任何经营资金可以继续以任何身份持续下去了。这个网站在接下来的几个星期内将继续维持,如果可以的话,希望可以保持更长时间的存档。

—— Linux Journal,LLC

这不是 Linux Journal 第一次发出悲呼。在一年半前,他们就宣布了停刊,但幸而在宣布停刊之后得到了社区的援手,得以复活,又持续了一年多。他们甚至对新的希望报以了很大的信心,在他们庆祝 25 周年的时候,还写了一篇文章来分析发生了什么,以及将来的想法。而且,确实,他们也在努力做出了新的改变。

但是,不管什么原因吧,这份创刊于 1994 的 Linux 杂志,在放弃了纸质杂志、电子杂志之后,可能要变成一个历史遗迹了。他们在网站上,用一张血红的纸张上扯破露出“TIME TO SAY GOODBYE”表达了对这份持续了 25 年的努力的不甘和哀伤——我是真能感受到这背后的哀伤。

说起来,Linux Journal 真是一个非常有价值的杂志/门户/社区,与之相比,我们的 Linux 中国社区就逊色多了,但是正是同一时刻,我也面临了 Linux 中国是否能继续下去的一些风刀雪箭,莫非天意?

说起来,Linux 中国也持续性的走了至少 6 年了 —— 如果从 2013 年 9 月 10 日 LCTT 成立算起的话。刚刚我在朋友圈发了一条消息,询问大家觉得 Linux 中国有无商业价值,不敢太严肃的问,怕引来各种联想。当然,有很多开玩笑的回答,也有一些感性的估计,也有一些用心的感激。其实,何必问呢,答案我心里有啊。

或许,Linux 中国有一些社会价值,也许帮到过许多人,也有很多人在这里付出了很多、很多的努力,但是,我们这 6 年没有尺寸进益,这说明了什么,我们究竟有没有商业价值?

很多人都知道,我一直坚持 Linux 中国的公益性、非商业性,也主张 Linux 中国是大家的,而不是我的或谁的。可是如果连起码的商业平衡也不能积累,是不是从一开始就是一个乌托邦式的空中楼阁?

Linux Journal 就倒在我的身侧,我遥望远方……

老王写于昆明,2019/8/8