project-flow-ops

原文涵盖的主题

• 项目流程运营
• 使用时机
• 运营模式
• 核心工作流
• 1. 首先阅读公开信息
• 2. 对工作进行分类
• 3. 判断是否需要 Linear
• 4. 保持两个系统一致

此技能将分散的 GitHub Issue、PR 和 Linear 任务整合为一条执行流程。 当问题在于协调而非编码时使用。 梳理开放的 PR 或 Issue 积压 决定哪些应放入 Linear，哪些应保留在 GitHub 中 将活跃的 GitHub 工作与内部执行通道关联 将 PR 分类为：合并、移植/重建、关闭或搁置 审查评论、CI 失败或过时 Issue 是否阻碍执行 GitHub 是公开和社区的真实来源 Linear 是内部执行的真实来源，用于活跃的已排期工作 并非每个 GitHub Issue 都需要创建 Linear Issue 仅当工作满足以下条件时，才创建或更新 Linear： 活跃 已委派 已排期 跨职能 重要到需要内部跟踪 收集： GitHub Issue 或 PR 状态 作者和分支状态 审查评论 CI 状态 关联的 Issue 每个项目应归入以下状态之一： | 状态 | 含义 | |-------|---------| | 合并 | 独立完整、符合策略、准备就绪 | | 移植/重建 | 有用的想法，但应在 ECC 内部手动重新落地 | | 关闭 | 方向错误、过时、不安全或重复 | | 搁置 | 可能有用，但当前未排期 | 仅在以下情况下创建或更新 Linear： 执行正在积极规划中 涉及多个仓库或工作流 工作需要内部所有权或排序 该 Issue 是更大项目通道的一部分 不要机械地镜像所有内容。 当工作活跃时： GitHub Issue/PR 应说明公开进展 Linear 应在内部跟踪负责人、优先级和执行通道 当工作完成或被拒绝时： 将公开解决方案发布回 GitHub 相应地标记 Linear 任务 切勿仅凭标题、摘要或信任进行合并；需使用完整差异 当外部来源的功能有价值但不独立完整时，应在 ECC 内部重建 CI 红色表示需分类并修复或阻止；不要假装其已可合并 如果真正的阻碍是产品方向，请直接说明，而非隐藏在工具背后 返回： "审查开放的 PR 积压，告诉我哪些应合并，哪些应重建" "将 GitHub Issue 映射到我们的 ECC 1.x 和 ECC 2.0 项目通道" "检查这是否需要创建 Linear Issue，还是应保留在 GitHub 中"