StoryBoard 与众不同的地方¶
StoryBoard 经过定制设计,旨在支持具有以下特征的开放社区内的协作
- 社区管理着大量的项目,有些倡议将跨越多个项目。
- 有多种赞助者;没有单一组织或个人控制社区的方向。
- 每个人都有平等的能力做出贡献。
- 有许多利益相关者,他们需要跟踪每个项目的各种需求集。
- 即使需求重叠,优先级也可能差异很大。
因此,StoryBoard 具有一些专门针对这些需求的功能。
如果您一直在您的项目中使用 Launchpad,那么您可能已经了解它的规范和怪癖。在考虑 Launchpad 中可能实现的事情时,很难设想以不同的方式完成相同的任务,因此本文档旨在概述 StoryBoard 中的一些有趣的新功能,这些功能在 Launchpad 中没有等效功能。
超越通用优先级¶
在 StoryBoard 中,不同的人可以表示“这对我们来说是优先事项”,因此任务可以具有不同的优先级,针对不同的受众进行定制。
那么,为什么这很有用?
传统的错误/任务跟踪器通常将优先级建模为单个共享属性字段。例如,任何人都可以更改任务的优先级,并且所有查看该任务的人都可以看到此更改。通常,没有办法说“只有在您在 IRC 上讨论过此事并经项目团队同意后,您才能更改此优先级”,等等。这意味着没有上下文的人可以更改任务的全局优先级。此外,两个不同的组可能会以不同的方式确定任务的优先级,这可能导致冗长的优先级排序会议,而真正的问题是“谁的优先级最重要?”(而且答案通常是“取决于受众是谁”,因此这些争论将陷入僵局)。
因此,StoryBoard 提供了一种说“此任务对我很重要”或“此任务对我的团队很重要”的方式,而无需试图将这种观点强加给其他人。我们使用工作列表来表达优先级:如果您手动将任务添加到工作列表,您可以拖放它们以按优先级排序。副作用是,您可以查看优先排序一个任务如何影响其他任务的优先级;您只能有一个项目位于顶部,并且将任何内容置于列表顶部都会将其他内容向下推。其他人可以订阅那些他们关心其优先级的人或团队的工作列表;然后,每当他们浏览优先排序的故事时,他们将看到任何任务是否在这些列表中,以及任务在列表中的位置。
工作列表具有权限,因此可以设置一个项目团队列表,只有核心评审人员选择的贡献者才能移动其中的项目。这可以防止每个人在没有讨论的情况下更改任务的优先级。
这仍然相对较新,我们很高兴看到人们如何使用它。我们牺牲了一些分配优先级的便利性,以换取对优先级进行更细粒度的表示。过去,StoryBoard 确实显示了许多不同人的优先级,但它没有提供任何跟踪谁的优先级属于谁的方式。因此,这使得事情更加开放和明确。我们希望根据用户反馈调整实施,这些是第一步!:)
工作列表和看板¶
StoryBoard 引入了一些新的数据模型来满足 OpenStack 的复杂需求。
工作列表是故事和/或任务的任意分组,标题由用户自行决定。每个“项目”(故事或任务)都放置在工作列表上的“卡片”上。这是一个例子
工作列表可以作为个人待办事项列表。任何人都可以创建工作列表,并且创建者可以决定谁(如果有的话)可以查看和编辑它。可以手动填充工作列表,也可以根据某些标准自动填充它(例如:“分配给 Alice”。以下是一些自动工作列表的示例筛选标准
有关如何创建和编辑工作列表的更多信息,请参阅此文档。
我们还有看板,类似于工作列表的集合。这是一个例子
您可以根据需要命名看板中的“泳道”(列表),并且可以像工作列表一样,通过满足某些标准(例如:“分配给 Alice”)自动填充它们,或者手动将卡片移动到自动泳道和非自动泳道。这意味着您可以使用看板来可视化数据,或者如果您愿意,可以使用它们进行类似看板的工作流程。例如,您可以根据标准将各种故事分组到不同的泳道中,然后看板将充当“史诗”,跟踪多个故事的状态。您可以为看板提供 markdown 描述,以便提供更多背景信息。您甚至可以编写自定义脚本来根据某些条件移动卡片。
看板的权限与工作列表权限相同。公共看板或工作列表对所有人可见,并且用户和所有者可以对其进行编辑。私有看板或工作列表仅对其用户和所有者可见。用户可以移动和删除卡片,但只有所有者才能删除泳道或更改看板本身的元数据(例如:其标题或描述)。
有关如何创建看板、添加用户/所有者等的信息,请参阅此处可以找到该文档。
REST API¶
StoryBoard 采用 API 优先的方法进行开发。这意味着什么?嗯,在核心上,StoryBoard 具有一个 python API。然后,它连接到数据库,并可以从中获取信息(或向其传输信息)。然后,StoryBoard API 可以从各种客户端访问,以便用户可以与给定的数据库进行交互。
这意味着 StoryBoard 的功能首先是在 API 端构建的,然后才在各种客户端中表达。由于 UI 只是表达 API,因此您可以在 API 中执行比任何给定 UI 更多的操作。
为什么这很重要?
自定义脚本!自定义 UI!如果您可以在脚本中表达它,您可以从 StoryBoard 获取数据。如果您有特定的请求,您不必依赖于任何当前 UI 中的功能,并且如果您愿意,可以构建自己的新 UI(或仪表板)。您还可以使用 curl 等工具从命令行实时获取信息。
这里有一些文档来说明用法
https://docs.openstack.org/infra/storyboard/webapi/v1.html
此外,由于 API 通常是 RESTful 的,因此很容易猜到如何操作,并且与许多其他工具兼容,只需进行少量调整。以下是一些示例,带有大量注释的脚本,用于一个简单的示例(命令行)界面,一个 python 客户端
https://review.openstack.org/#/c/371620/
还有另一个功能更全面、更具交互性的命令行 StoryBoard 界面,名为boartty,由 Jim Blair 编写
简而言之,如果您知道如何显示来自 REST API 的数据,您就可以显示来自 StoryBoard 实例的数据。
您可以做一些有趣的事情。例如,如果您想将故事描绘成移动平台或类似的东西,可以使用 pygame。说到这,如果您觉得想动手尝试一下,StoryBoard 团队很乐意与您交流!请在 Freenode IRC 的#storyboard 频道上打个招呼。