英语原文共 4 页，剩余内容已隐藏，支付完成后下载完整资料

GitHub上的协作写作：一个图书项目的案例研究

作者：Ei Pa Pa Pe-Than 、James D. Herbsleb 、Laura Dabbish

摘要

GitHub这个软件代码的托管环境正在日益成为用于生产协作式软件及非软件数字项目的数字工作区。由于GitHub提供的功能不同于传统的协作写作方式，因此研究GitHub的功能如何用于此类目的是一件很有趣的事情。

在本文中，我们介绍了在一个GitHub的图书项目中对协作实践进行一种混合方法的研究的初步发现。我们发现GitHub的使用取决于任务的相互依赖性和受众的参与。 GitHub的直接推送方法用于协调松散耦合和紧密耦合的工作，后者要求合作者遵循社会认可的惯例。该项目向公众发布后，便采用了基于拉动的方法。尽管面对面和在线会议在早期阶段很重要，但GitHub的问题追踪手段（issue）却在后期阶段成为交流和项目管理的主要方式。我们以上的发现将会对协作写作工具的设计产生影响。

关键字：

共创；合作； 协调； 合作写作；混合方法研究；社会科学

介绍

随着网络通信技术在社交方面的最新发展，从网络软件开发到文本文档创建等等越来越多的工作正转而在网络数字环境中完成。传统上，人们使用不同的工具集来共同创建不同的软件。但是，随着社交编码工具或用于GitHub[2] 的软件开发工具的日益普及，人们开始采用这些工具来共同创建非软件项目，例如书籍和政策[6，7， 9]。

GitHub是用于项目的私有和公共存储库的托管环境，它使用名为Git的分布式版本控制工具来管理项目。 Git允许人们独立工作，但与此同时，也可以通过以后将其工作与协作者的工作进行整合来与他人合作[4]。 GitHub已被开源软件开发社区广泛采用，2017年有超过2400万开发人员在6700万存储库中工作[3]。

迄今为止，许多研究都只是集中在GitHub所采用的技术和所拥有的社交功能对软件开发中的协作的影响上[2，4]。这些研究表明，GitHub提供了一个开放透明的开发环境，从而提高了彼此的工作意识，并减少了额外交流的需求[2]。但是很少有研究以其他形式的非软件数字项目或文本文档为中心来检查GitHub的项目。

GitHub平台与其他用于编写文本的工具（例如Wiki）有着很大的不同，在Wiki这种工具中，用户可以通过对“文章”或内容页面本身进行直接编辑，并在“对话”页面上通过创建评论来同步所做出贡献[5]。相比之下，GitHub允许协作者通过复制（“分叉”）项目存储库，在其本地环境中进行更改，然后在准备好后，将其这段时间内所做的更改直接提交到集中的共享存储库，或进行“拉取请求”来将远端的改动拉取下来依旧进行孤立地工作。而且，GitHub用户可以创建一个问题（即 issue ）和相关的请求来讨论主要文章的某特定部分，这使协作者可以更轻松地在讨论和实际更改之间导航[2]。

了解GitHub的功能对促进文档编写时我们所需求的某些特定方式非常重要，因为这种理解可能有助于我们开发更多功能集，这些功能集可以应用于我们平常更熟悉的协作编写工具。更重要的是，研究GitHub在软件和非代码项目中的使用方式的异同将使我们了解在诸如GitHub之类的数字环境中，可以在多种项目上进行协作的各种方式。

我们采用了一种混合方式的研究方法（有关详细信息，请参见段落末）（将半结构化访谈和档案分析相结合），以研究GitHub的图书项目HoTT Book（有关同型类型理论的教科书）中的协作。在本文中，我们提供了与HoTT Book的四位合作者进行访谈的初步结果。我们的访谈重点在于关注核心团队成员为何决定将其项目放置在GitHub上、他们采取了哪些具体措施将其放置在GitHub上、使用了哪些GitHub功能以及如何使用GitHub的特定功能，以及，他们觉得在项目中使用GitHub的好处和挑战是什么。

方法
我们采用了混合方法-半结构化访谈和项目工件的档案分析相结合的方法来研究相关问题。

具体方式

我们选定要研究的GitHub的图书项目所使用的方法是通过关键字搜索以及相关研究中的参考文献确定的。这些项目是根据两个标准选择的：

（1）贡献类型（即协作或收藏）；

（2）根据星星（即喜爱度或热度），合作者，评论和问题的数量来确定受欢迎程度。

对于每个被选定作为研究对象的图书项目，我们都会与中央人员（核心项目团队的成员或者是前五名的贡献者）和外围人员（至少具有过一次提交的贡献者）进行一些访谈。除此之外，我们还收集了项目存档，例如这些项目成员在博客文章，Wiki和GitHub上的活动。

结果

最终，我们总共收集了四个访谈，其中三个访谈来自于中央贡献者。每次的采访持续44 到85分钟不定。在这个过程中，我们使用了牢靠的理论程序[1]对所收集的数据进行了详细的分析，以揭示在编写HoTT书过程中他们所采用的主要协作实践的手段和收获。

图1说明了HoTT Book GitHub协作工作流程。

第一阶段：在将项目放到GitHub之前

通过和图书项目被访谈者的交流，我们发现，在此阶段主要采用“小组协作模式”，因为这个方式会方便项目团队成员之间执行紧密耦合的工作，同时又可以立即反馈给其他人[8]。这个阶段会涉及到对本书的内容和组织，分工以及关于工作协调的讨论。该团队会使用Wiki来记录从这些讨论中所产生的想法，并会使用分发邮件来在成员之间传播信息并进行组织活动。

在这之后，他们决定使用GitHub的决定主要是取决于两个因素：

（1）虽然整个团队由对GitHub熟悉程度不同的人员组成，但是他们的团队中至少有两名成员是GitHub专家；

（2）团队有着一起通过使用GitHub用于基于代码的项目，即证明辅助代码的先前经验。除了为其他成员提供GitHub帮助外，一位团队中的 Github 专家还通过创建用于书中使用的数学公式或符号（即宏）的命令集合，来承担“技术独裁者”这个角色，而另一位 Github 专家则通过确保整本书中术语和宏的一致性，充当了“技术编辑”的角色。HoTT书中每个章节或主题的所有者分配为一或两个团队成员。

第二阶段：将项目放到GitHub后

将项目部署在 Github 上之后，在实际的写作过程中，HoTT团队采用了“个人协调模式”来进行书籍的后续协作协同写作，在此过程中，团队成员依靠生成的松散耦合的任务（或具有合并依赖项的任务[8]）进行独立工作，从而为本书的不同章节或会话各自进行内容的创作。其中每个章的所有者通过使用“推送方法”将其贡献直接提交到GitHub上的项目存储库。除此之外， GitHub的 issue管理也被用作了本图书项目的管理工具。例如，团队创建了任务列表，并分配给具有相关技能的成员或自愿者。这提高了人们对成员正在执行的任务的认识，从而确保了同时由一个人编辑本书的特定部分，我们称之为“社交锁定”。

第三阶段：项目公开后

图书公开发行后，HoTT 团队采用了“基于拉取的方法” [4]来进行后续的管理，这意味着每个针对图书的更改请求都必须经过严格的审核过程。例如核心团队成员之一审核了建议的更改，然后另一位成员合并了批准的更改。在这方面，在此阶段执行的任务会具有顺序的依赖性[8]。在这个过程中，大多数交流是通过GitHub的问题和评论完成的。在团队成员的子集之间偶尔会通过使用电子邮件进行需要私下讨论的事情。

除去以上之外，我们也了解到了，团队将项目放到GitHub上的主要原因是将众人的想法或他们不知道的事情（例如错别字和格式问题）给集中起来。

团队开始意识到，由于公众贡献了与数学相关的内容，例如练习题，特定定理的改进以及数学证明的错误，收益超出了他们的期望。此外，一些不属于核心项目团队的贡献者已成为常规贡献者，这表明GitHub促进了围绕该项目的社区的形成。

结论

我们的初步研究发现表明，GitHub可能是进行协同共创文本文档的一项有用工具，这是因为它所使用的技术和拥有的社交功能能够很好地支持松散耦合和紧密耦合的工作。但是，重要的是要注意，尤其是在将该项目放到GitHub上并公开之后，必须有社会认可的惯例和实践（例如，社交锁定，强制性审查）才能进行有效的协作。我们建议在制定此类社会习俗和做法时应考虑任务的相互依赖性和目标受众的参与。

综上所述，GitHub不仅可以促进核心团队成员之间的开放式协作，而且还可以提供公众参与的可能性，这反过来可以为项目带来收益，实现需要改进的地方。

参考文献

1.朱丽叶·柯宾（Juliet Corbin）和安瑟姆·斯特劳斯（Anselm Strauss）。 2014。“定性研究的基础：发展扎根理论的技术和程序”。

2. Laura Dabbish，Colleen Stuart，Jason Tsay和Jim Herbsleb。 2012年。GitHub中的社交编码：开放软件存储库中的透明度和协作。在ACM 2012年计算机支持合作工作会议（CSCW 12）的会议记录中收录，1277-1286。

3. GitHub. https://octoverse.github.com.

4. Georgios Gousios，Andy Zaidman，Margaret-Anne Storey和Arie van Deursen。 2015年。基于拉动式开发的工作实践和挑战：集成商的观点。在第37届软件工程国际会议（ICSE 15）的会议论文集中收录。 1，358-368。

5. Aniket Kittur和Robert E. Kraut。 2010年：超越维基百科：在线中的协调与冲突，在2010年ACM计算机支持合作社会议论文集中收录。

6. Justin Longo和Kelley M. Tanya。 2016年。GitHub在加拿大的公共管理中的使用：使用新协作工具的早期经验。

7.贾斯汀·隆戈（Justin Longo）和Tanya M. Kelley。 2015年。使用GitHub作为文本文档开放式协作平台。在第十一届国际公开研讨会论文集中

协作，第22条，共2页。

8. Andrew H Van de Ven，Andre L. Delbecq，and Richard Koenig Jr.1976。组织内部协调模式的决定因素。美国社会学评论322-338。

9. Alexey Zagalsky，Joseph Feliciano，Margaret-Anne Storey，Zhao Yiyun和Weiwei Wang。 2015年，GitHub作为教育协作平台的出现。在1906-1917年第18届ACM计算机支持的协作工作和社会计算会议（CSCW 15）的会议记录中。

这篇文章对我的帮助

我所设计的系统，一款支持在线多人协同创作书籍的软件，旨在能够解决作者在协同创作方便的需求，而所基于的手段也是类 git 的管理方式，在这一点上，与本篇文章中所研究的对象：基于 Github 的一个图书项目的协同过程，是很相似的，我也通过对本文的阅读翻译，收获了一些新的设计创意点，也发现了之前预想设计上的一些不足。

首先，很明确的一点，Github 并不是一个以图书协同创作为目的而搭建的平台，它的核心功能，正如上文所说，是作为软件代码的托管环境，而它的使用，也并不是无门槛的，它是基于 git 这一分布式版本控制工具来进行管理的。所以 HoTT 书籍的创作团队，是在有两名团队成员是 Github 专家的基础上才会考虑到将书籍在 Github 上进行部署创作的。

我从 Github 上学到的是它对项目的管理方式，而要避免的是它的门槛，毕竟作为一款针对于作者，不了解编程的人群而言，git 是他们所不易于理解和操作的工具，我所要考虑的，是将这个工具的思想运用于简易的可视化操作中，降低整个系统的门槛，能够使得实现项目协同管理的同时实现单人写作一样的体验。

第二点，在将书籍放到 Github 上进行共同编写之前，第一阶段 HoTT 书籍创作团队他们还是在线下进行的，或者说是脱离 Github 系统的基础上进行的讨论，因为这个过程是对整个书籍的内容组织、分工、大纲等的讨论过程，而 Github 是没有这一项功能来能够很好的支持团队成员之间的沟通的。（issue 等情况是针对于书籍问题而言的），但这一项功能确实是多人创作过程中所必不可少的，作者之间需要对整个书籍的走向等问题进行“面对面”的讨论，所以一个沟通的平台是必不可少的，这也是我所需要添加入我的系统中的一个功能点，这样，这个系统的功能才算是完整的，能够让创作人员不脱离系统就能完成所有流程；

第三点，问题管理跟进；Github 的 issue 管理方式对 HoTT 团队起到了很大的帮助，帮助他们进行了“社交锁定”，能够将每个章节分发给特定成员，方便了管理，并且在之后的书籍完成，开放给公众之后，对于反馈的问题也能够有一个跟进的记录。对于这一点，我预想在系统中针对于每本书籍的管理添加一个任务分配的功能以及一个问题反馈的平台；

第四点，对公众的开放以及强制性审查；Github 对于公开项目是开源的，人人可看可浏览的基础上，人人也都能够像项目提出自己的更改请求，如果项目管理人员同意，就能够使得自己的改动在这个项目中应用。我认为这是最吸引人的一点，我们都有着喜欢的书籍，也有

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[234092]，资料为PDF文档或Word文档，PDF文档可免费转换为Word