Pods: GitHub 标签

~"Needs Changelog" 作为标签或许可以去。 我一直在将更新日志更新作为合并过程的一部分，并没有使用那个短暂的标签。~
完毕

我还没有时间用细齿梳子仔细检查，但在第一次浏览时我没有看到任何立即刺眼的东西。 我可能会发现一些调整、遗漏、删除，但我的直觉是这将是对当前标签系统的巨大改进。

“补丁”是我从未在我的工作流程中使用过的，因为它对我来说似乎是多余的。 如果它是一个 PR，那么它就是一个补丁。 但@sc0ttkclark传统上使用该标签，因此它可能对他有一些工作流程价值。

~ Component: Multi-site将是一个很好的补充，这是另一个领域，如 REST API，以及有助于开始标记过滤目的的模板。~

完毕

重点：向后兼容
重点：兼容性/弃用
重点：兼容性

对于这三个，或许精炼：

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

编辑：这就完成了

除了到目前为止的那些小东西，我都在做这件事。 分类要好得多，我想在 2.7.7 中使用它。

我也想首先从@jimtrue和@sc0ttkclark得到明确的赞许。

Discussion和Team Discussion什么区别？ 它们可以替换为Needs: Developer Feedback吗？

什么是Integration ？

这是我的第二遍。 一些新的添加/更改。 如果不使用，那些带有前导问号的可能会被删除：

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

讨论和团队讨论有什么区别？ 它们可以被需求：开发者反馈所取代吗？

不多，讨论将向全世界开放，而团队讨论将在内部进行。 我认为我们不需要那么细粒度的，一个单一的通用讨论标签就可以了（重复可能是无意的）。 开发反馈通常用作状态，通常是持有用户反馈并得到所述反馈的票证。

什么是集成？

主要是涉及与其他插件、库、主题等集成的功能请求。我认为现有集成中的错误可能属于这一范畴，但一旦我们进行了集成，这些错误通常更适合作为“兼容性”。 （所以集成可能是一种类型，尽管可能像你所做的那样在 Focus 中更有意义）

我不确定“需求：”部分是否更好......我喜欢将它们作为“状态：”的一部分的想法，因为我认为这通常是它们的使用方式。

编辑：这一切都已解决

~我认为以下关键字实际上可能是类型：发布、支持和工具。~

〜那些似乎是其他任何人都没有很好描述的门票类型。〜

完毕

另外，为了滚动起见，我想知道我们是否应该保持初始消息中的列表是最新的，而不是随时发布新版本？

完毕。

我喜欢这个想法：

需求：开发者反馈
需求：研究
需求：任务清单
需求：测试
需求：用户反馈
需求：验证/复制
需求：投票

但是“用户反馈”和“验证/复制”实际上是上面@pglewis提到的“状态/工作流程”，或者我们可以将它们作为状态：阻止者，需求是阻止者的“原因”。

理想情况下，状态工作流应该细化到项目中的泳道。 看看这个标签列表，我不知道我们有这么多，但我猜你们创造了更多。

support.pods.io和docs.pods.io根本不应该在这里（我们有这两个网站的存储库），除非我们计划使用 GitHub 进行支持和文档更新。 如果我们要这样做（我完全赞成），那么我们为 Docs: 和 Support: 添加前缀，并在此存储库中的 GitHub 中为支持和文档创建两个项目。 由于有时支持问题可能会变成实际的代码增强/功能或错误修复，因此我们使用相同的界面确实有意义。 当然我们会有更多，但我们也将确保我们得到我们需要的支持问题和文档更新。

我查看了这个，我希望看到以下更改：

• 类型：添加Support和Docs Update （从Keyword删除Support Keyword ）
• 组件：我们不需要support.pods.i o 或doc.pods.io Component 。 这两个 repo 有自己的项目。 组件应该完全针对 Pods 核心领域。
• 优先级：将Focus从关键字移动到Priority 。 Blocker只要我们知道原因就可以了，这应该来自Needs 。

所以如果我正确地遵循这一点，一切都应该有：
类型：定义它是什么类型的票证。
状态：定义它在工作流中的位置。 如果我们需要用户反馈或验证/复制，很少讨论什么状态应该是“阻止”或“待办事项”或“保留”。 不确定需要投票的功能/增强请求的状态是什么。 也许那些遵循典型看板的相同格式，并且它们的状态是 BackLog，直到它被积极工作。 拦截器表示在处理需求之前无法工作。
Component : 为 Feature/Enhance/Bug 确定 Pods Core 的区域
关键字和焦点只是为了额外说明？

我删除了 WaffleBot，因此不应再自动添加这些状态。

拦截器表示在处理需求之前无法工作。

这是我们没有使用具有相同意图的标签的情况。 我一直使用 Blocker（我认为 Scott 也是如此）来解决阻止发布（或者可能是另一张票）并且必须完成的问题； 不能下注。

在我的工作流程中，我没有理由通过“拦截器”将某物标记为持有某物……当前的状态标签应该暗示这一点。 我不需要“需要用户反馈”加上“拦截器”，因为第一个已经告诉我它正在拦截以及为什么。

我的投票是我们以这种方式使用它并将其保留在“优先级：*”下，因为这对我来说是一个完美的描述。

~我认为“焦点”也应该从关键词转向优先级。~ 留下关键词

我喜欢这个想法：

需求：开发者反馈
需求：研究
需求：任务清单
需求：测试
需求：用户反馈
需求：验证/复制
需求：投票

这些对我来说主要是票证状态，所以我建议现在将它们保留在那里。 如果关注长度，我们可能会缩写一些（“状态：需要开发 FB”，“状态：需要验证/复制”）。

我觉得“Needs Tasklist”可以去。 我认为这不足以保证贴上标签。 我不确定我是否曾经使用过它，如果有的话，很少使用。 可能与“需求测试”相同。 其余的都非常适合我在“状态：*”下。

另外，这个列表对我来说很好，我们可能应该讨论配色方案。

还有一些可能可以从状态以及“需要任务列表”中删除：

• ~"Pulled for Review" 可能只是无意中重复了 "Ready for Review"~ 留下
• “单元测试”不是一种状态（至少还不是），更多的是杂项......所以可能转移到关键字？

这让状态列表对我来说看起来不错。

“Pulled for Review”可能只是无意中重复了“Ready for Review”

不同意。 如果我创建了一个 PR，那么当它准备好时，我会添加 Ready for Review。 但是您可能没有时间在稍后进行审核 - 但到那时，Scott 不确定您是否已经开始审核。 简而言之，这是两个不同的人群添加准备审查和拉动审查。

可能与“需求测试”相同。

为了想要更多的代码覆盖率（虽然我还没有亲自研究过这个领域），这个标签可能是为了说“修复是好的，但我们希望看到单元测试覆盖边缘/验证特定的错误修复，因此不会引入回归”。

我认为“焦点”也应该从关键字转向优先级。

优先级通常是 - 低、中、高、关键、阻滞剂 - 它们与 Focus 具有不同的语义（至少在我看来）。 Keyword: Focus标签本身没有相关性，除非有一个里程碑说明该问题是哪个版本的焦点_for_。 而优先级是没有上下文的，因为它适用于整个项目。 我不一定认为添加其他优先级是个好主意，但同样，不要认为 Focus 是优先级。 也许我们想说的是“这张票是里程碑式的亮点 - 在下一个版本中大喊大叫的好东西”，如果是这样，与 Focus 不同的词可能会更好地表明意图。

拦截器表示在处理需求之前无法工作。

我在这里同意 Phil 的观点 - 我理解这意味着具有此标签的问题是 _release_ 的障碍。 也许吉姆的解释更适合Status: Is Blocked标签或类似标签，尽管Needs: *表示相同。

顺便说一句，在这里删除临时列表可以吗：#5016（评论）？

@pglewis继续删除（或隐藏在<details>...</details>以供历史参考）您想要的任何内容。

support.pods.io 和 docs.pods.io 根本不应该在这里

由于对现有“文档改进”标签（vs Docs：内联）的不确定性，我将它们添加进来 - 如果它们在其他地方处理，它们可以被删除。

文档改进可能更好地写为“文档：内联”“文档：示例”“文档：工具提示”等等。 除非我们在 GitHub 中处理文档（即 docs.pods.io 网站中的书面文档）工作流程，否则这里没有理由。 我们代码中的任何文档改进意味着文档_in_我们的代码或在我们的代码中管理，或者像被解析并推送到 WordPress.org 插件存储库的自述文件。

我喜欢Status: Is Blocked因为它非常有用，但是如果你做这种性质的事情，它确实需要一个需求：*

就像我说的，所有东西都有一个Type和一个Status 。 在我们使用 GitHub 进行完整的敏捷项目管理之前，不需要在那里定义优先级，实际上可以更好地由完成“故事”所需的工作单元来表示。 我们一直使用 Focus 来区分需要在下一个维护版本中关注的 100 个问题中的项目。

我唯一的想法是关于 UI/CSS 标签，因为这些是我处理最多的那些......似乎只是将 CSS 作为一个组件删除并且只依赖 UI 对我来说最有意义。 不确定你们是否有任何想法，但 CSS 是结果，而不是需要修复的有形事物......如果这有意义的话。 UI 将是需要处理或改进的有形事物，css 将是结果或如何修复它。 不然我喜欢👍

我唯一的想法是关于 UI/CSS 标签，因为这些是我处理最多的那些......似乎只是将 CSS 作为一个组件删除并且只依赖 UI 对我来说最有意义。 不确定你们是否有任何想法，但 CSS 是结果，而不是需要修复的有形事物......如果这有意义的话。 UI 将是需要处理或改进的有形事物，css 将是结果或如何修复它。

是的，那里需要改进。 我主要使用 CSS 标签作为你和/或 Jory 的 Bat-signal 来过滤，因为你一直是那个方向的首选。

我会投票决定暂时保留 CSS 和 UI，但我们当然可以在第一阶段之后继续完善它。

RE：需要测试

为了想要更多的代码覆盖率（虽然我还没有亲自研究过这个领域），这个标签可能是为了说“修复是好的，但我们希望看到单元测试覆盖边缘/验证特定的错误修复，因此不会引入回归”。

现实是我们需要跟上维护修复，在发布分支上工作，即使是简单的事情，编写新测试的障碍也相当高。 我们可以将标签留在那里，但在完成更多重构、引入实际单元测试和/或有更多资源用于它之前，它不太可能被大量使用。

“类型：测试”将是一个很好的补充，因为现在添加的测试可能最适合作为他们自己的问题/PR 对。

我喜欢状态：被阻止，因为它提供了非常丰富的信息，但是如果你做这种性质的事情，它也需要一个需求：*

我可以离开它，但我主要是跟踪状态，而且我从来不需要将任何“被阻止”标记为状态。 任何我遇到的模糊方向的东西都可以更好地覆盖“Holding”。

如果它有助于澄清任何事情，这是我在平均错误上使用的典型工作流程：

• 分类：过滤掉无效、支持、功能/增强； 将类型设置为错误
• 通常状态会立即变为“需要验证/重现”
• 在整个生命周期中，可能会在“需要用户反馈”和“需要开发人员反馈”之间来回切换
• 验证/转载
• 需要研究：既然我们知道如何让它发生，找出并理解为什么
• 研究：我可能是唯一一个使用它的人。 表明在某个时候已经进行了深入研究，我可能已经将内部细节存储在我的脑海中
• 固定/需要测试

不同意。 如果我创建了一个 PR，那么当它准备好时，我会添加 Ready for Review。 但是您可能没有时间在稍后进行审核 - 但到那时，Scott 不确定您是否已经开始审核。 简而言之，这是两个不同的人群添加准备审查和拉动审查。

我认为在这些情况下，Hold 标签历来比 Pulled for Review 更好。

仅供参考，过去我曾使用 Blocker 来指出阻止发布的问题。

我们可以删除“补丁”，当 GitHub 在 PR 和问题之间有更多令人困惑的 UX 时，我开始使用它，使用补丁更容易看到“发布”视图，主要是为了回顾更改日志的内容。 我们不需要它。

原始问题描述中的列表是否与我们讨论过的更改保持同步？

原始问题描述中的列表是否与我们讨论过的更改保持同步？

可能不完全，如果你愿意，可以随意改进一些。 一旦我们完全赞成并梳理我们认为尚未更新的任何内容，我就会完成。

无论我们在这里做出什么决定，我们都需要使用https://github.com/dwyl/labels 之类的工具将它们应用于所有其他 Pod 存储库以同步它们。

将“回归”从类型移动到关键字。 Bug 仍然是回归问题的类型。

这现在几乎已经实施了。 一些杂项我现在只是停留在“关键字”下。

在这一点上，颜色是主要的工作。

?关闭：无效

我建议至少保留这个，可能也不会修复。 它们是其他错误跟踪器上相当标准的分辨率。

在这一点上，颜色是主要的工作。

颜色在这一点上是次要的 - 实施标签，然后决定配色方案。

我建议至少保留这个 [Invalid]，也可能是 Won't Fix。 它们是其他错误跟踪器上相当标准的分辨率。

我将添加无效，我只是将其标记为提醒，因为我们还没有它。

“不会修复”是我讨厌的语气之一。 另外，我的态度是我们应该有一个标签，上面有比“不会修复”更好的不修复原因。

颜色在这一点上是次要的 - 实施标签，然后决定配色方案。

标签几乎已实现。

我们需要“类型：GitHub”或类似的东西吗？ 这个问题没有类型。

Type: Project ?

如果我们使用“保持原样”或类似的东西而不是“不会修复”怎么办？

如果我们使用“保持原样”或类似的东西而不是“不会修复”怎么办？

这是一种不常见的情况，因此我们已经做了这么长时间而不需要类似的东西。 我投票等待在那里添加任何内容，直到出现特定示例。

此外，我为某些组做出了一些随意的颜色决定。 那里没有什么是一成不变的。

我认为我们现在可以结束这个问题，并通过 Slack 讨论任何进一步的改进。

What if instead of "Won't Fix" we used "Leave as is" or something like that?

这是一种不常见的情况，因此我们已经做了这么长时间而不需要类似的东西。 我投票等待在那里添加任何内容，直到出现特定示例。

我同意。 并非 WordPress 核心所做的一切都需要复制

我同意。 并非 WordPress 核心所做的一切都需要复制

它也是在 GH 上设置新存储库时的默认标签之一 - 请参阅具有默认标签的https://github.com/GaryJones/daterange/labels 。

I agree. Not everything that WordPress core does needs to be duplicated

它也是在 GH 上设置新存储库时的默认标签之一 - 请参阅具有默认标签的https://github.com/GaryJones/daterange/labels 。

我不记得它何时成为 GitHub 的默认设置，但将其附加到来自志愿者贡献者的票证上总是一个糟糕的标签。 我在 GitHub 上很少看到带有该标签的问题，但在 WordPress 世界中，大多数无法修复的问题都被另一个问题所涵盖，需要更多信息来证明修复的合理性，或者只是希望没有人回来抱怨（通常是这种情况） .

我会坚持我的不喜欢。 我关于“​​不会修复”的直接问题是“为什么我们会拒绝修复某些东西？” 如果有人在机票上给了我一个很好的简洁答案，我会说_那_是标签应该读的内容，而不是“不会修复”。

无论如何，我认为Out of Scope是更好的答案。 不会修复只是暗示并向打开问题的人提供“无”。

也许它可以朝着这个方向发展 - 随意提交一个“解决方案”，但团队没有足够的资源来做到这一点 :D 也许有人对它有一个简短的缩写 ^^

用例可能是某些功能中的错误或 CS 违规，无论如何，都会在下一个版本中大量重写和发布。

随意离开它。