X-lab
Replies: 0 comments 3 replies
-
|
图例补充：
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
你是怎么上图的？ @zhicheng-ning 我看你的图是： 我是直接拷贝过去，是： |
Beta Was this translation helpful? Give feedback.
1 reply
-
我图片都是存在 GitHub 一个仓库的图床上的，知道图片的链接后按照 markdown 的语法来引用就可以了。 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
前言
最近阅读了《What Makes a Great Maintainer of Open Source Projects》这篇论文，论文中主要提到了「优秀的开源项目维护者可能具有的属性」、「这些属性之间如何相互关联」以及「贡献者如何看待这些属性的重要性」这三个研究问题。在每周的论文分享会上我们就这些话题进行了交流探讨，因此我写下这篇文章作为此次论文分享会的一些总结心得，如有错误，可以直接在 https://github.com/X-lab2017/open-research 下面提 issue 。
背景
在传统的软件工程的背景下，有些研究者进行了开创性的实证研究，试图了解优秀的软件工程师和优秀的软件工程师管理者都分别拥有哪些属性。这些研究结果对于帮助在这个要求越来越高的软件行业中培养更优秀的软件工程师和管理者而言是至关重要的。然而，因为开源软件开发与传统软件开发的不同，所以这些研究结果可能无法直接应用到开源软件的背景下。于是作者为了揭示一组非常有价值的属性，这些属性能帮助开源软件维护者在他们的职业生涯中大放光彩，从而设计了三个研究问题。
研究问题
● RQ1：优秀的开源软件维护者拥有哪些特质/属性？
● RQ2：这些属性相互之间如何联系的？
● RQ3：贡献者如何看待这些属性的重要性？
研究方法
同样的，作者针对三个不同的研究问题采取了不同的研究方法，它们分别是：
● RM1：分析了与经验丰富的 OSS （Open Source Software）维护者的 33 次访谈中提到的 172 个属性。
● RM2：创建了一个概念性的框架，在更高级别的抽象级别上理解这些属性之间的关系。
● RM3：对 90 名维护者和贡献者进行了属性的评级问卷调查，目的是了解他们如何对这些属性进行优先级排序。
问题一：优秀的开源维护者拥有哪些属性
问题一的研究过程，具体来说就是采用半结构化的访谈方式，对 33 名参与者进行访谈，并将访谈内容记录下来，以及将收集到的 172 个原始属性进行更高层次的抽象，形成了22 个属性，这些属性所属于 4 个高级类别，这 4 个类别是：管理(Management)、社交(Social)、技术(Technical)和个性(Personality)。
访谈内容是什么？
整个访谈是由五个部分组成：
● 第一部分，询问了维护者的背景和群体特征问题（标准的问题有，性别、年龄、种族、地址、教育、婚姻状态）。
● 第二部分，询问了他们作为维护者的工作，例如他们做什么以及他们是如何做的，他们如何找到新功能，以及他们在 OSS 上投入了多少时间。
● 第三部分，专门讨论了与「什么是优秀的维护者」相关的话题。为了指导这部分采访，在发送给参与者的电子邮件中，参与者被要求回复他们认为对优秀维护者最重要的五个属性。只关注五个属性将有如下优点：（1）避免参与者匆忙回答（2）要求他们提供有针对性的回答，丢弃不太相关的属性（3）减少回忆过去特定经历的认知负担。
● 第四部分，询问参与者是否记得他们过去合作过的其他优秀的维护者，并描述为什么他们认为那个人很擅长维护 OSS 项目。
● 最后部分，通过感谢参与者来结束采访，并询问他们是否可以推荐其他可以接受采访的维护者。
访谈分析
首先从维护者在访谈前发送过来的 172 个原始属性开始，因为一些受访者提到了超过 5 个属性，所以这个数字高于 165（5 个属性 × 33 个受访者）。为了将属性分组到高级类别中，两位作者采用了卡片分类方法。经过多位作者多次持续讨论直到达到共识，最终经过近 15 个小时的讨论，出现了 22 个属性，分为四个高级类别。这四个类别是：管理(Management)、社交(Social)、技术(Technical)和个性(Personality)。关于类别中的每一个属性的介绍如表 II 所示。
下面简要介绍下四个大类别中的比较重要的属性。
一、Management
这一类别指的是有助于管理 OSS 项目的属性，从理解项目愿景、建立和传达项目目标、提出时间表、管理文档质量等方面来说。下面重点介绍三个管理属性。
● Availability（可用性/有空）
○ 此属性指的是回答问题或向补丁建议提供反馈的响应时间。这是该类别中最常被提及的属性（33个人中有15个人引用）
○ 当维护者可以帮助另一个人，支持那些新手，避免他们走错方向和浪费时间时，Avaibility 是有用的
○ 长时间的响应等待会令贡献者产生不满
● Discipline（规章纪律）
○ 维护者需要确保流程和指导方针得到遵守。有 6 个人提到了这个属性
○ 维护者可能“有一个明确的时间表，知道该做什么以避免任务处于打开状态”
○ 为贡献者定义任务是建立他们对项目承担义务的一种策略
● Vision（愿景）
○ 对项目未来要实现的目标有一个全局的看法，这可能有助于维护者定义优先级。4 名参与者提到了这个属性
○ 需要与利益相关者密切合作，制定长期愿景
二、Social
在这个类别中，我们将把维护者如何与其他贡献者打交道相关的属性进行分组，这些贡献者可能说不同的语言或者不知道如何开始贡献。
● Communication（交流）
○ 33 位受访者中有 18 位提到了「Communication」是一种以明智的方式交换信息的能力
○ 在项目发生任何重大变化后，寻求外部反馈是很重要的
○ 与其他维护者进行良好的沟通非常重要
● Empathy（共情）
○ 非常小心地对待你的写作和说话方式，这样你就不会看起来咄咄逼人或不礼貌
○ 我们应该讨论想法，而不是判断是谁提出的
● Community building（社区建设）
○ 帮助新手加入社区，并激励现有的贡献者完成他们的任务
○ 没有什么事比创造一个欢迎新成员的环境对该项目的未来更重要了
○ 一些维护者忘记了许多贡献者都是志愿者，如果一个人已经对代码的某个部分做出了贡献，为什么不让这个人在其他部分做出贡献呢？
三、Technical
这是关于用于运行 OSS 项目的技术能力（例如，修复错误或添加新功能）。这一类别只有三个属性。
● Technical excellence（技术卓越）
○ 在 33 名受访者中，有 24 人提到了这一点，这是提到最多的属性
○ 如果你没有很高的技术知识，你该如何要求贡献者做有质量的事情？
○ 维护者还应该执行代码审查，以发现错误并提供反馈
○ 技术知识储备越多，就越容易做出决定
● Quality assurance（质量保证）
○ 维护者负责确保一切工作正常，也就是说，确保
○ pull request 遵循贡献准则
○ 测试通过
○ 确保贡献者没有“破坏”任何东西，防止他们发布一个不合格的版本
○ 良好的文档也是一个强有力的质量指标
● Domain experience（领域经验）
○ 具有领域经验可能有助于维护者理解代码库中的特性
○ P12 报告说“了解问题领域让我更投入到项目中”，这在某种程度上与“自己抓痒痒”的原理是一致的
四、Personality
当维护者在与社区的互动中表达他们的想法、感受和行为时，他们指的是个性方面。个性特征如下：
● Motivation（动力）
○ 这与鼓励维护者热情地做事情的因素有关
○ 热情在于相信项目的人，也相信有能力改变事情，让事情运转起来，他们有一种感觉就是可以用微小的变化来改变世界
○ 积极进取是一切事情的基础：“如果你参与得很好，你也会感染社区中的其他人，并创造一种感觉，即我们在一个社区里，我们正在一起做一些事情“
● Open minded（思想开放）
○ 维护者需要在社区中具有创新性。创新者有一个开放的心态，必须放下自我，重新成为学徒……。敞开心扉，讨论你认为是“真理”的事情，听取与你不同的意见
○ 某人提出了一些你以前没有考虑过的建议时，与其进行防御和试图批评，不如认为这个人正在试图帮助你
● Patience（耐心）
○ 耐心使 [维护者] 能够评估情况，了解需要什么，并等待他们建立采取适当和有效行动的能力
○ 耐心使项目的未来变得清晰，它可以让维护者更清楚地看到问题的根源
问题二：这些属性之间如何相互关联
问题二的研究过程，具体来说就是通过设计一个概念框架来描述属性之间的关系，属性与属性之间是通过概念进行连接的。
如何进行概念框架的设计？
概念框架的设计涉及三个阶段，分别是概念识别，概念设计和概念细化。
● 1）概念识别
在采访中，作者要求受访者解释「为什么提到的属性对她/他很重要」。受访者对特定属性的理解就是这里所说的「概念」。
● 2）概念设计
在确定好概念后，随后开始分析概念，在分析概念的时候，进一步寻找概念之间的关系，于是得出图 1 中的关系。属性用粗体大写文本表示，而概念用较小的大写文本表示。我们使用箭头来说明关系，并使用粗体蓝色文本来描述提到这些概念的参与者。当一位受访者在描述一个属性时提到多个概念时，概念之间就会产生关系
● 3）概念细化
作者为每个类别创建了一个概念框架，在问题一中，已经发掘出四个大类，因此一共有四个概念框架。一位作者创建了每个概念框架的第一个版本，其他几名作者合作进行了细化，一共迭代了三个版本。在审查框架时，作者们试图达到一个粒度级别，既不会太粗粒度以致于读者无法获得任何新见解，也不会太细粒度以致于读者可能对类似概念感到困惑。
概念框架概述
图 3 列出了所有类别的概念框架。每个概念框架都有一个核心概念，用黄色突出显示。核心概念是与至少三个不同属性相关的概念，用粗体加下划线突出显示出现在多个类别中的概念。
图 3 中一共有四幅小图，每一幅小图都表示一个概念框架，并且阐述了一种关系。下面我将简要介绍下每个概念框架以及其所表达的属性之间的关系。
$%Essential=100\times \frac{Essential}{Essential+Worthwhile+Unimportant+Unwise}$
$%Good=100\times \frac{Essential+Worthwhile}{Essential+Worthwhile+Unimportant+Unwise}$
$%No good=100\times \frac{Unimportant + Unwisw}{Essential+Worthwhile+Unimportant+Unwise}$
一、Management
图 3(a) 说明了「Management」类别的概念框架及其属性：纪律、项目管理、可用性、文档、透明度、可持续性和愿景。一共确定了 18 个概念以及它们与属性之间的关系（注：每一个概念就是「一段几个单词的描述」）。
关系1：为了维持项目的长期愿景，维护者最终应该定义路线图，委派任务，并处理文档。在以志愿者为基础的工作中，必须仔细考虑这些活动，以免影响工作和生活的平衡。
二、Social
图 3(b) 说明了「Social」类别的概念框架及其属性：同理心、领导力、沟通、教育学、社区建设和人际关系。一共有 17 个概念。在这些概念中，出现了三个核心概念。
关系2：极其细心/礼貌似乎是鼓励和指导新贡献者的基石。为了建立信心，维护者应该愿意倾听和交谈，这反过来又会让他们从另一个人的角度思考。
三、Technical
图 3(c) 说明了「Technical」类别的概念框架及其属性：技术卓越、质量保证和领域经验。
关系3：为了拥有支持决策的高技术知识，维护员应该了解应用领域，了解项目的技术，并具有实施质量过程的经验，以执行代码审查并遵循项目质量标准
四、Personality
图 3(d) 说明了「Personality」类别的概念框架，以及它的属性：耐心、动力、责任心、思想开放、勤奋和自信。
关系4：为了促进开放式创新，保持对项目目标的关注，并在社区中建立真理，维护人员应该突出奉献精神，具有长期合作的坚持性，并确保一个没有敌意的环境。
五、Intra- (and inter-) relationships
上面所说的「概念」和「关系」是类别内的，因为它们连接相同类别内的属性。然而，我们也发现了类别间的关系：即「概念」连接不同类别之间的属性。在图 3 中以粗体和下划线突出显示了连接不同类别中的属性的 「概念」。「Perform good code review」的概念是最全面的一个：它是所有四个类别的一部分：「Social」、「Management」、「Technical」和「Personality」。横跨两个类别的另外两个概念是「Find consensus」和「mentor new contributors 」，这两个概念出现在「Management」和「Social」 类别中。
问题三：贡献者如何看待这些属性的重要性
问题三的研究过程，具体来说就是通过问卷调查，要求每个参与者对每个类别中最常见的 3 个属性（ 共 12 个属性）进行评级，其中包括以下选项：1) Essential，2) Worthwhile，3) Unimportant，4) unwise，5) I don't know，再根据对每个属性的评级计算不同的指标，从而可以得到贡献者对于这些属性的看法。
有哪些指标？
作者使用了三个指标来分析调查结果：
第一个指标旨在捕获（大多数）调查受访者认为最重要的属性。它是给定属性的所有响应中认为”必要“的百分比：
第二个指标反映了受访者对这些属性的总体良好倾向。它计算认为每个属性都是重要或有价值的受访者的百分比：
第三个指标考察了受访者认为不太重要甚至是负面的最低等级属性。它计算认为每个属性不重要或不明智的受访者的百分比：
作者再根据指标的值对属性进行排名。作者们还试图辨别受访者在 OSS 开发方面的经验是否与他们认为某个属性是必要的有关。根据经验（9年以上的开放源码软件经验）和没有经验（0-5年）将受访者分为两类。因为经验可能会给贡献者带来不同的感知，从而影响他们对属性的看法。
为了了解「受访者的经历」和「一个属性被评为基本属性」之间的关联强度，作者还计算了优势比。优势比确定在特定暴露条件下(本文指「被调查者的经验水平」)结果发生的几率(本文指「一个属性被认为是基本属性」)。
问卷的分析结果
表 III 列出了根据问卷调查计算出的三个指标的值。
● 「Communication」属性的 %Essential 指标 明显高于其他属性 。76.67% 的受访者认为这一属性至关重要，认为“不重要”或“不明智”的没有一票。得票率第二高的属性是「Quality Assurance」(57.78%)，其次是「Comm unity Building」(50.00%)。
● 所有属性的 %Good指标 均显示出较高的值，那么 %NoGood指标 的百分比必然很低。
● 「Availability」属性是 %Essential 的最低值。这个是 %Essential 和 %NoGood 之间差异最小的属性
作者计算了优势比，以量化「受访者经验」和「某个属性被评为必要属性」之间的关联的强度。
● 对于「Patience」来说，优势比是 0.232，例如，没有经验的受访者认为此属性是必要的可能性是有经验的受访者的 4.3 倍。95% 置信水平的置信区间为 (0.083,0.645) 的，p 值为 0.005。该置信区间表明，在 95% 的置信度下，没有经验的受访者认为此属性是必要的可能性是有经验的受访者的 1.55 到 12.05 倍之间（1/1.55=0.645，1/12.05=0.0829）。应用 邦费罗尼校正（注：如果在同一数据集上同时检验n个独立的假设，那么用于每一假设的统计显著水平，应为仅检验一个假设时的显著水平的 1/n），即将目标显著性水平 0.05 除以 12（我们执行的统计检验次数），我们得到显著性水平 0.004167。由于 p 值等于 0.005126且大于 0.004167，因此我们无法确定统计显著性。
● 对于「Communication」 来说，优势比是0.533，也就是说，一个没有经验的受访者认为它很重要的可能性几乎是前者的两倍。在 95% 的置信水平下，置信区间为 (0.182, 1.562)，尽管 p 值不表示统计显著性。
● 这两个属性的优势比表明，经验不足的开发人员认为其他项目贡献者更需要沟通和耐心。
另一方面，对于「Motivation」和「Domain Experience」属性，优势比分别为 2.154 和 1.75。根据作者收到的回复，该证据意味着有经验的受访者认为「Motivation」必不可少的可能性是没有经验的受访者的两倍多，而认为「Domain Experience」必不可少的可能性大约是 1.75 倍。置信区间为 (0.828, 5.599) 和 (0.660, 4.639)，强化了这一结果，尽管无法确定统计显著性。
讨论
以下是论文分享会中的讨论过程，视频链接：https://www.bilibili.com/video/BV1r3411J7YD?t=2683.6
娄博：我看到最后他说到自己的挑战，局限性的时候，他为什么收集了这些参与者的项目经验，有没有说明收集了这些参与者的项目经验之后要干啥
我：就是说他们采访的这些人，都是在开源项目上有多年经验的维护者，那么采访这些经验丰富的开源项目维护者，所获得的采访结果可能就是更为准确一点的
娄博：我的意思是说这边论文不是都有局限性和应对措施嘛，前面两个局限性的应对措施确实是比较合理的，但最后这个局限性的应对措施，我看不出来为什么会做出这个应对措施
我：噢噢噢，第三个的话，其实就是说作者采访的大多数受访者都是在基础设施（操作系统，浏览器，编程语言）上工作，但是你这个维护者不一定只参与了这个基础设施项目，可能还会参与其他非基础设置的项目，所以作者要求参与者报告他们所参与过的所有项目，就可以让这个访谈涉及到更多类型的项目。我理解是这样子的。
娄博：噢噢，就是在这篇文章上应该是体现不出来吧。
我：这篇文章中的采访部分确实是这么做了的
娄博：噢，行行。大家还有其他的问题吗？
娄博：那我再提一个问题吧，就是他说这个属性和概念的时候，有没有说在整理概念的时候是怎么整理的？
我：有说的，这些概念是从这些受访者的发言中提炼出来的，就比如说 Define a roadmap 这个概念，它是由 P23 和 P30 这两个受访者，以及 P23，P28 这个两个受访者在访谈的时候提出来的。这个概念又分别归属于 DISCIPLINE 和 PROJECT 这两个属性。他这些概念其实都是从受访者的采访记录中提炼出来的。
娄博：就是概念基本上都是受访者的原意思，这些加粗的属性是作者他们自己分的类
我：嗯，是的，在前面提到了一个卡片分类法，就是将这 172 个原始属性，进行更高层次的抽象，就形成了 22 个属性，然后再进行更高层次的抽象，就形成了 4 个大的类别。
娄博：噢噢，好的好的，谢谢
王老师：哎，我觉得这块是不是可以请邱博士说一下
我：嗯，那邱博有什么看法
邱博：我刚刚看了整个这个研究，因为我其实更多的在公司做的确实和这个比较类似，只是领域不一样。然后我觉得这里面是有一个信度检验，你可以再讲一下这个过程他是怎么做的吗
邱博：就是他在正式调查问卷之前，会先找一部分人做试点。因为之前和跟另外一家咨询公司合作的时候，他们就很喜欢做这个，但是不知道为什么在我们公司就很不屑于去做这个。就是可以再讲一下这个过程吗？就是还做了一个显著性分析，我们在作报告的时候，客户就会看这个显著性分析，所以是蛮重要的。
我：他这边是这样的，在问卷设计好之后，在正式开始调查之前，他们是采取了一个小范围测试，做这个小范围测试的目的就是为了最终确定这个问卷上有哪些问题，以及对某些问题的描述或者理解，进行一些简化或者加深，从而使得问题更加清晰。然后他这边举了一个例子就是说，有一个试点人员建议在性别问题中加入“不想说”这一选项。可能就是考虑到个人的隐私，就是说不太想说自己的性别之类的。
邱博：嗯，那它这个里面有没有一些就是比如说开放型的，就是问卷里面一般是选择题，还有一种，他就是说，其实你从问卷里面还可以得到一些非结构化的一些问题。当然他也做了那个访谈，然后访谈的过程当中，就你刚刚有提到他那个一些工具是吧，然后他他是怎么去提炼这些问题的，你刚刚讲的是他人工分析的，就他提供了一个叫 concept 的一个 framework 嘛，就是因为我们其实如果假如要去做的，我觉得这块，其实可以展开的，就是因为在高校做科研，其实是可以把一个人工的过程，变成一个自动化的过程。就是这个它有用到一些就是比如说像 NLP的一些技术吗？
我：这边的话就是他们在对这些属性进行这个提炼，然后做成一个概念框架的时候，他这边应该是没有做那个自动化的，他们就是大家每个人都进行一些讨论，然后把它们分到一个同样的一个类别里面，然后再分到一个更高级的类别，然后就构成了这样一个概念框架。
邱博：明白，因为我为什么讲这个问题，就是说，我先分享一下，就是比如说关山他做的这个工作，就是其实他们这个行业，是面向市场做研究的。一般公司哈，他有这种需求，他并不是只做一次的，像我们做科研的话，可能写一篇 paper 就结束了，对不对，那往后的话，假设你要去做一个研究，它并不是说只做一轮的，所以其实问卷调查它会有一个概念叫轮次，因为你现在做一次的话，量其实比较少的，那比如说如果我们后续假设，我们先是要持续的去做这种跟踪，跟踪式的这种研究的，就不大可能说你就做一次研究，后面可能就不做了，其实你可以一直在一个话题上面不断的去追踪他。那等到就做到后面的时候是，那其实自动化的这个效果就越来越重要了。
邱博：同时，如果我们在后面做这个开源的研究的过程当中，假设你做了同样的这种问卷套路之外，你可以用同样的问卷不停的去优化它，不停的去分发，比如说你今天可能就是像他这个刚刚有讲到，只是通过自己的朋友圈，找了一部分人去回答，但如果你做好了这样一种问卷之后，他可以提炼为一个模板，那么其实你只要你以后接触到的开源项目，你就可以让他们填，那就是说这个量，假如我们有这个关系网的话，这种研究的实证性，其实是非常好的，就是说我的一个启发就是说，如果要真的把这个研究做得更好一些，一方面是我们可以从单个的这种，就是比如像他们现在做的一次的这个研究哈，然后我们可以提炼出来，就是说把更多的问题，然后做追踪性的这种研究，然后，在这个过程当中也可以提炼，一开始是小数据的，慢慢慢慢的，如果你后面触点式的去收集的话。它就会变成个大数据的，因为全球有很多这种开源的工作人员，对，按照这个量，然后按一个百分比去收的话，这个量就很大。否则的话就是说通常就是在公司里面的，如果只是做一期的话，通常就比较便宜，但是如果是到现在就是再做这种问卷调查，慢慢就会变成叫触点式的研究。
邱博：触点性的研究，其实就是把原来的研究问题拆成了一些小的点，但是，这个触点它会一直放在一个场景下面，那在这个场景下面的时候，就是比如说某一种场景，比如说像你刚刚讲的这个社区的维护，我们可以去跟社区的这个这个leader，让他去管理这样的一个触点，那么未来只只要是参加到这个 maintainer 的这些人，他都可能会去参与这个调研，但这个是一个慢慢的过程，可能不是说像我们做科研，一下子就能做到的，就持续的去做这种追踪的研究，最后得到的效果更加的不一样。还有一个就是说像做这种，小样本的研究，他其实不会考虑这种样本的分布的，你会发现就是说他其实很少去讨论这个项目的分布，因为更多是因为自己的社交关系或者朋友，对，然后拿了样本就很不容易，但通常在正式的这种研究里面。你在研究个问题之前，其实做了很多的假设，就是我们其实是做样本的分布，其实是个很重要的一个话题，我们要先去讨论为什么，就是比如说你 30 多个人里面，那他为什么要去做这个样本的选择，他要这样去抽样，那要去重等等，这个反而是整个数据质量里面非常关键的一个环节。从这个论文里面我看就是说就有一部分的假设检验，还有就是刚刚有一个显著性检验的一些东西，就这个是可以值得参考的，就是我这边就把我在公司的一些体会，结合这篇论文给大家做一些分享，那么在未来，如果后续我们有机会，就是说再去做一些研究的，我我其实也常想把，就是说在关山当时有一套，就是我们现在做的这种问卷调查，就把它做成触点式的。
邱博：就是说如果你能做成一个埋点，我们现在做的这种研究，就是在我们这个行话里面叫关系型的，就是你已经找到了一批样本，然后，你就对这批样本。就是去分发，你就是发问卷嘛，还有一种就是叫做 transaction 的研究，就是事务型的，我在每一个点上面去埋点，就比如说。大家应该有骑过那个共享单车，就类似这种交易，或者在淘宝上买东西，买完东西之后它就会弹出这种问题调查来，如果我们能梳理出来，那么类似你去研究这个 maintainer 的话，那你肯定就是说 maintain 一般会在什么地方出现，或者说在哪些场景下，我想去研究这个 maintainer 的这种行为，他肯定会跟软件进行交互对吧？那定性的这种研究，你做访谈是一种，还有一种就是可以让他直接从一些数字化的渠道上面，然后去做些小问卷，这种也是可以的，就是说后面我们可以再去优化的地方，或者在这个研究基础之上，我们还可以再去拓展的工作。就是把一个一个小轮次的问卷做成 routine 的，我就分享到这儿。就是因为这篇论文我其实没有细看，我后面会再去看一看，然后到时候跟我们那个公司的研究员也分享一下，然后后续我可以想想，就是说像这样的一个研究，那类似这种研究，我们可以让他们给给建议，我觉得这个是蛮好的，基本上的套路跟公司做的。就跟我们那个做问卷的方式非常相似。
王老师：可能邱博士前面并没有那个听我们前面一些系列的一个报告，其实前面我们也讲过几篇这样的文章，其实都是类似这样的一些方法，其实就是一些那个问卷调研似的，然后，用一些技术来去做一些结构化。那目前我们看到的这些，其实大部分，都是这种一次性的，一次性的意思就是他就是以那个科研问题为主，然后去做一些调研，然后得出一些结论，然后，供一些最佳实践，或者是一些模型后续使用。目前我们大概还没有怎么看到过，就是类似一些商业领域里面的这种 transaction 的这种持续性的去做这个数据收集和建模的，那我相信这个东西，如果有机会能够用进来，一定是有一个非常巨大的一个价值的，对。那我想到的其实就是，那究竟什么样的问题是需要持续去做这种不断的这种问卷去收集的，可能也是要要看问题，因为我们现在这一块，我看几个同学选的这些文章，其实都还是都还是蛮偏这一块的，那我也是觉得这块还是也很有用的。包括昨天昨天邱博士做的报告里面，其实也是提到。这块其实是可以和一些量化的东西，其实是有一个非常好的一些互补性。就是我们现在做的那个基于大数据的那些分析。他不是什么东西都能分析出来的，很多可能都做不出来，反而是如果通过这些调研能够快速的采集得到，其实还是一个特别好的，可以更全面的去把这个东西做起来。因为我是感觉到确实在商业领域里面，因为它有各种各样一些资源的支撑，所以说他可以用系统的方式去做这个东西。学术界这块，确实他可能，更多的还是围绕着一些科学问题去做，所以说他可能基本上做一次，他就发篇文章就结束了，但是他没有把它做成一个持续性的，甚至做成一个产品化的东西，那这件事情其实我们是感兴趣的，我们是还挺希望，如果我们能够找到一些好的问题，甚至是能够长期的去不断的去做这个事情，那这样的话，其实就能够更好的去把这个事儿去做好，这是我能够想得到的。对但是，就是那个我们现在其实，一方面技术可能还不是最重要的，可能我们还是在啃业务，就是我们要看究竟包括国外他们做的这些业务，是怎么去做的，包括其实这些文章的一些题目和它的最后的结论，总的来说，我觉得还是挺有意思的。
王老师：对，包括因为我前面没听到嘛。包括前面最后说的这个结论，包括那个沟通交流，这种管理协调能力可能比这些技术能力要更重要，这个，其实这个也是蛮符合我们的直觉，也是给一些特别技术的人员，其实也是可以有非常大的一些启发的，但究竟一个开源项目，开源社区里面什么东西最重要，这些事情其实还是一个蛮关键的东西，而且，我相信不同的社区或者是一个项目，不同的阶段，他的这种理想的要素其实也会不一样。那如果能够借鉴一些持续性的这些工具的话，也许能够有一些更好的这种洞察，这是我能够能够想得到的一些点。
我：好的好的，谢谢王老师，然后我想问一下，这个持续性是指时序，时序上面就是，比如说在每过几年，然后再重新给他们发一次问卷，然后看他们的那种看法有变化之类的吗？是这个意思还是什么的。
邱博：对的，通常我这边分享，就像我们一般做一个项目哈，就是公司的那种项目，比如说一家公司，他可能其实是遇到一些问题，或者他对某一个点他想去研究，就是这个甲方他就会提出来，我想做这么一个研究，然后，他就去找一家公司说，“你能帮我做一下吗？“。我目前签的合同里面基本上都是四轮以上的，比如给你举个例子，就是像我们前段时间做了一个车的研究，就是比如说像一辆电动车，第一就是说他每个月比如说回收一部分样本嘛，然后他就说，比如说每一个季度他都会去做一次，就是说追踪，那么经过几轮之后，然后最后再做一次分析，然后会把每一批的再去做个对比，那这样在实验室有什么好处哈。因为你看我们学校的话，一般不都是有学长，学姐对吧，那学长做过的工作不代表学弟们后面不能再去做。他这个东西，如果你去跟踪它的话，就会有不同的这种动静，就完全有可能的，而且样本的话，就是每一次的样本可能也会有发生这个动态的变化嘛，是不是，但同样这个问题你可能会有不同的发现。
我：好的好的，谢谢邱博
思考
● 这篇论文主要还是定性研究，而在定性工作中，「研究结果」与「数据分类的主观性」是非常有关的，那么如何才能减少个人主观性对结果有效性的影响呢？
● 这篇论文主要研究了一名优秀的开源项目维护者拥有哪些属性，对于在访谈中接受采访的那些开源项目维护者们来说，他们所维护的开源项目，所从事的领域是否能支撑研究结果的饱和度和全面性呢？
● 这篇论文中大多数受访者都是在基础设施 OSS （例如，操作系统、浏览器、编程语言）上工作。那么本论文的研究结果可能不适用于在其他开源项目工作的维护者？
● 对于我们 xlab 实验室来说，这篇论文中的访谈部分是否能为实验室在做的播客节目提供一定的经验？
结论
● 维护者无疑是社区成功和长期可持续发展的核心工作人员。这些贡献者的职责包括一系列不同的职责，这些职责需要不同的能力。虽然可以将维护者视为负责保持高质量代码的唯一技术开发人员，但这篇论文的结果表明，优秀的维护者必须掌握多种技能。
● 事实上，「沟通」被认为是优秀维护者最重要的属性，根据 %Essential 指标，「质量保证」排在第二位。统计分析已经证实了这一点，该统计分析涉及属性收到的评级之间的成对比较。组成前五名中的三个属性与技术能力(「社区建设」、「同理心」和「远见」)无关。因此，很明显，尽管维护者通常是技术水平很高的贡献者，但社交和管理技能是在这一职位上脱颖而出的关键。
Beta Was this translation helpful? Give feedback.
All reactions