文档团队负责跟踪、修改和改进 WordPress 项目中的文档，包括：核心Core 核心是运行 WordPress 所需的软件集合。核心开发团队负责构建 WordPress。、Codex、即将推出的手册，以及 WordPress.orgWordPress.org 这是由用户创建和共享 WordPress 代码的社区网站。你可以在这里下载 WordPress 核心、插件和主题的源代码，也是社区交流和组织活动的中心位置。 https://wordpress.org/ 和相关网站的其他部分。在整个项目中，代码和设计问题都会在 tracTrac Trac 是贡献者创建错误或功能请求问题的地方，其作用与 GitHub 类似。https://core.trac.wordpress.org/。（包括核心和 metaMeta Meta 是指一个群体内部运作方式的术语。对我们来说，这是负责内部 WordPress 网站（如 WordCamp Central 和 Make WordPress）工作的团队。 Trac）中进行跟踪，但这种方法并不是跟踪文档问题的最高效方式。因此，文档团队提出了建立文档问题跟踪器的方案。
目标
文档问题跟踪器有两个主要目标：
- 让整个项目中的问题能够轻松报告给文档团队
- 轻松跟踪已报告的问题
一个成功的文档问题跟踪器最终将改善整个项目中的文档。
利益相关者
鉴于文档团队将主要使用该跟踪器，因此文档团队是该项目的主要利益相关者。
需要指定一位负责人。
@samuelsidler 将负责项目管理，并与文档团队和负责人合作。
解决方案
文档问题跟踪器有两个主要功能：
- 报告界面
- 跟踪界面
为确保我们实现目标，将采用以下指标：
- 最终用户报告文档问题时进行用户测试（确保操作简单）
- 文档团队对跟踪功能的反馈
组成部分
如上所述，文档问题跟踪器包含两个组成部分：报告和跟踪。
报告
报告界面需要在可能的情况下自动收集一些信息，并将其提交到跟踪器。具体来说，我们将收集报告者的用户名、问题报告日期、问题类型（由用户选择）、页面链接（可能时使用引荐来源），以及由用户自定义创建的描述。用户需要登录其 wordpress.org 账户才能提交问题。如果用户未登录，我们会先将其重定向到登录页面。这里可能会出现一些交互问题，例如，如果用户必须先登录才能报告问题，引荐来源可能会丢失。
我们仍需确定该报告界面将位于何处（仅在特定页面上，还是在所有地方都提供链接？）
已完成步骤：
- 确定了需要收集哪些信息以及何时收集的更多细节
- @karmatosed 设计了报告界面
- 发布了初始模型以征求反馈
- 创建了最终模型
- @Otto42 已同意开发报告界面
下一步：
- 与文档团队和 Meta 团队合作，确定界面将位于何处
跟踪
跟踪界面主要供文档团队跟踪新收到的和活动中的问题。该界面的一部分功能包括单独查看问题以及更改问题状态。编辑者（或园丁）需要特定权限才能执行操作。更具体地说，我们要求用户拥有“编辑者”用户角色才能解决问题。
在跟踪界面中，我们希望显示以下信息：报告者的用户名、问题报告日期、问题类型、页面链接、分配给问题的人员、将问题分配给自己的按钮，以及解决复选框。用户创建的描述将会存在，并且可以通过“展开箭头”显示。
已完成步骤：
- 确定了所需的具体信息，以及能够解决问题的用户角色
- @karmatosed 设计了跟踪界面
- 发布了初始模型以征求反馈
- 创建了最终模型
- @Otto42 已同意开发跟踪界面（可能使用带有已解决文章的 P2P2 P2 或 O2 是人们用来指代 Make WordPress 博客的术语。该博客位于 https://make.wordpress.org 插件Plugin 插件是一段包含一组函数的软件，可以添加到 WordPress 网站中。它们可以扩展功能，或为 WordPress 网站添加新特性。WordPress 插件使用 PHP 编程语言编写，并与 WordPress 无缝集成。这些插件可以在 WordPress.org 插件目录中免费获取 https://wordpress.org/plugins/，也可以从第三方购买。）
下一步：
- 确定跟踪器将位于何处
注意：目前，该问题跟踪器很可能会采用适用于所有情况的统一跟踪界面，不允许进行太多跟踪定制。不过，最终我们希望能够按“组件”进行排序。