43、科研协作与软件许可：全面指南

科研协作与软件许可：全面指南

1. 科研问题讨论方式

在科研工作中，部分研究小组倾向于通过电子邮件讨论问题，而非使用问题跟踪器。然而，这种策略看似等效，实则不然。直接在问题页面进行讨论，在保留上下文、透明度和来源方面更具优势。不过，非常开放性的讨论通常更适合采用电子邮件形式，因为问题最终是要被关闭的。

2. 关闭问题

当 bug 修复或新功能实现完成后，问题应予以关闭。协作的文化规范、专业知识分布、领导层级以及验证和确认要求等，都会影响问题被判定为完成的过程。
- 简单项目 ：在撰写研究论文、构建研究网站或快速实现创意原型的仓库中，更改可能不需要严格的质量保证方法。在这些情况下，问题可以在没有太多宣传或监督的情况下关闭。
- 科学软件项目 ：科学界期望科学软件具有较高的健壮性和质量。为确保质量和准确性，科学软件项目的新更改可能需要经过验证、确认和同行评审。在这样的项目中，关闭问题可能涉及多位研究人员的努力和共识、纳入自动化测试套件、遵循风格指南以及提供适当的文档。

3. 拉取请求与代码审查

3.1 拉取请求的起源与优势

过去，软件开发人员通过电子邮件传递补丁来共享、删除和提交更改。拉取请求是该技术的高度进化产物，其核心仍包含补丁。拉取请求为协作软件开发带来了巨大的进步，它是一种合理且能追溯来源的接口，可对提议的补丁进行同行评审。

3.2 提交拉取请求的步骤

以 Lise Meitner 为例，假设项目仓库中有一份概述项目工作理论和实验描述的文本文档。为进行更改，Lise 首先以 kaiserwi