openSUSE:Openfate 上游项目
上游项目如何从 Fate 中受益，以 KDE 为例
功能跟踪是许多公司/项目必须处理的任务。通常使用 Bugzilla，严重程度为“增强”，这实际上并不适合。Fate（及其 Web 前端 openFATE）是专门为功能跟踪设计的，因此具有一些使其成为更好选择的功能
- 能够为每个功能跟踪多个产品，并具有各自的优先级和状态
- 带有富文本支持的线程讨论，以实现更好、更高效的沟通
- 基于角色的优先级（例如，对于请求者、经理等）
- 功能树，用于可视化功能之间的依赖关系
- 可定制的流程定义，以确保数据完整性、应用流程策略等
- ...
Fate 作为整个系统以开源软件（GPL）发布，以便其他人可以从中受益。以下是它如何在大型开源项目（例如 KDE）中使用的一个建议。
KDE Fate
使命
Fate 是一种通信工具，可以增强用户和开发人员之间的透明度并改善协作，也可以增强推广人员和下游之间的协作。它不是关于强迫开发人员跟踪他们的工作或催促他们实现他们不想实现的功能。
基础设施
有一个 Web 客户端（参见 openFATE），供 KDE“用户”使用（例如，将其链接到 bugzilla 帐户），以请求和讨论需求。只有具有 KDE 写入权限的人（=svn 帐户）才能直接访问数据库，例如使用 KDE fat 客户端。
设置
Fate 产品可能是
- KDE 4.3
- KDE 4.4
- 推广
- 打包
- 基础设施
- ...
我们可能希望将组件（=KDE x.x 中的应用程序）分配给这些产品中的每一个，以便更容易（自动）找到与功能相关的维护者（见下文）。我认为我们不需要里程碑，对吗？
定义了以下角色
- 请求者：请求该功能的个人（或代表分发版的情况）
- 维护者：所提应用程序的维护者……
- 开发人员：正在进行工作的人
- 感兴趣者：关注该功能开发的人
- 质量保证经理：检查实施质量的人
- 文档经理：寻找文档影响并应用它们的人
公司里所说的“产品管理”呢？我认为 KDE 缺乏这一点——回答“为了使 KDE 4.3 成为一个良好、有用的版本，需要哪些功能？”这个问题的人。在公司中，产品经理负责产品设计及其在市场上的成功。我们没有在社区中这样做，因为我们无法真正分配资源给工作。我们如何建设性地应对这种情况？我认为在工具中创建 PM 角色以简单地让他们了解情况将是一个很好的开端，我相信 KDE-Promo 中活跃的人会对它感兴趣。
一个功能处于以下状态之一（每个产品）
- 未确认：新功能进入系统时处于未确认状态。它们尚未经过筛选（重复、无意义等）
- 新建：经过筛选的功能进入新建状态。在此阶段，确保它不是重复的，并且应该已分配维护者。
- 已接受（或已排队或任何其他）：维护者已决定这是一个有效请求，应该考虑实施。
- 实施中：请求正在进行中。
- 完成：完成了：)
- 重复：它是另一个功能的重复
- 已拒绝：由于……（有一个“拒绝原因”字段，其中包含详细信息）
功能的利益相关者指定请求来自哪里。所有来自社区的请求都将有一个“社区”利益相关者，每个希望为 KDE 请求功能的发行版都有一个利益相关者。也许一个“核心团队”利益相关者也会很有用，例如用于处理核心 KDE 开发内部的请求。
一个功能具有请求者优先级和维护者优先级（同样，对于每个产品）。请注意，一个功能通常在多个产品中具有这些值。这反映了现实世界的情况，即一个功能在版本 n 中可能很好，但在 n+1 中绝对是强制性的。
因此，功能的具体生命周期是
- 社区成员或分发联系人输入该功能。它处于未确认状态。
- 筛选团队或相应的维护者查找有效性并将其设置为新建状态。
- 一旦决定是否应该完成该功能，它将被设置为已接受状态。
- 当开发人员开始实际处理该功能时，他们将其设置为实施中。
- 完成时，他们将其设置为完成。