项目管理基础设施

选择了一个软件组合来支持项目的技术基础设施进行协作，即：

以下主题概述了 所需组件 和 关键功能 技术基础设施。

它包含中第2.2节的节略版本。 [SWLH11] 对术语进行细微的更改和编辑。

中提供了类似但更详细的概述。 [Foge09] （第3章）。

协作的技术基础设施

由于广泛分布的贡献者之间的协作是OTD（开放技术开发）的关键，因此项目必须建立一个具有协作所需技术基础设施的项目站点。项目站点必须支持软件、测试套件和文档（包括用户、安装、管理和设计文档）的共享开发，尽管这些开发的细节在项目之间经常有所不同。

所有潜在的贡献者和用户必须能够轻松地使用这些工具。例如，如果安全限制使人们难以参与，他们将不会参与。

项目应该更喜欢使用广泛使用的OSS协作工具，这些工具与任何标准兼容的Web浏览器都能很好地工作。不寻常的工具会造成不必要的进入障碍，因为它们要求用户学习如何使用新工具，而不是简单地贡献。（即使用户已经学会了如何使用工具，但如果工具被广泛使用，用户也会更愿意使用，因为他们的学习时间被摊销了。）

OSS工具应该是首选的；它们可以根据特殊的需求进行配置，部署成本低，而且由于它们经常被用于这一目的，所以特别擅长于OTD风格的协作。

通过符合标准的Web浏览器最大化访问，可以提高其他人与产品交互的能力，例如，他们可以在现场进行交互。

承包商必须期望这一技术基础设施意味着政府和其他承包商将能够持续获得中间进度。这种透明度是设计出来的。

关键功能

中心项目现场必须支持持续改进的协作，并应提供以下功能：

  1. 网站 . 中心项目站点必须为那些对项目感兴趣的人提供一个单一的起点，使人们能够了解项目并找到所有相关信息。这通常是一个具有简单固定URL的网站。

  2. 缺陷和特征跟踪 . 中心项目站点必须提供一种机制，让用户提交bug报告和特性请求，并让开发人员确定如何（或如果）解决它们。

    这通常通过专门的工具实现，如Bugzilla、Trac或Redmine，但也可以使用其他工具（如wiki）。可能需要一个特殊的过程来报告安全漏洞，以防止在修复可用之前泄漏。

  3. 版本控制系统 （VCS）。中心项目站点必须提供一种跟踪变更的机制，至少包括软件和通常的测试套件以及一些文档。它至少应该提供一种方法来查看和跟踪“主要开发分支”和每个主要版本。风投们必须让人们知道每一次的改变是谁，何时，以及改变是什么。

    有两种主要类型的VCS系统：集中式（例如， Subversion aka svn）和分布式（例如， Git 和 Mercurial) . 分布式系统（如 Git) 具有显著的优势，应优先用于OTD项目的风险投资。

  4. 社区互动 . 中心项目站点必须为用户和开发人员提供讨论问题的机制。邮件列表和维基往往更容易使用。一定要将讨论归档，以便以后的参与者能够找到，否则重要的讨论将丢失。

  5. 发布下载 . 中心项目站点必须提供下载主要版本的机制。

公共访问和分类控制

在可能的情况下，提前确定哪些组件可以作为OSS发布给公众，并从一开始就在公众之外建立项目。

没有法律要求等到项目“功能完成”之后，这个版本才会出现，而且如果它无论如何都是公开的，那么越早公开发布越好。

有些组件是分类的，因此它们的开发只能在授权进行分类处理的系统上进行。

在可能的情况下，根据组件的敏感性划分组件，以限制必须由安全分类控制保护的内容。

项目应该认真考虑使用分布式VCS（如“git”），其中可能存在不同级别的分类。分布式VCS软件使创建单独的外部分支变得更加容易，如果批准，则稍后将它们提供给其他人进行合并。

托管

每个项目必须确定它是基于提供预配置功能的现有协作托管服务，还是将建立自己的系统、获取必要的工具并托管项目本身。无论关于托管的决定是什么，您都必须能够竞争并改变谁来提供托管支持。不要锁定在单个供应商中。

评估托管服务的一个关键标准是确定在其他地方复制数据（例如，错误报告、源代码等）有多困难，以便如果托管服务不足，项目可以轻松移动。

小项目通常通过使用现有的协作托管服务得到很好的服务，因为它们不能证明资源可以专门配置其基础设施。

理想情况下，如果一个项目作为OSS公开可用，那么它应该在创建设计之前作为公共项目建立。

资料来源： [SWLH11]