公开 Issue 政策
GitHub Issues 是 ThreadCells 精心维护的公开待办事项，而不是警告、审计或发布调试的记录稿。
资格
公开 Issue 通常应满足以下全部条件：
- 问题或机会仍未解决；
- 可复现，或有持久证据支持；
- 对用户、项目、可靠性、文档或可维护性有实际影响；
- 公开跟踪对项目或社区有用且可执行；
- 公开披露是安全的；
- 预期行为或结果明确；并且
- 可以陈述具体的验收标准。
当确定性复现不切实际时，持久的技术证据可以替代复现步骤。
问题、故障排除和开放讨论属于 Discussions Q&A。在 Discussions Ideas 中探索以早期问题和使用场景为先的提案。只有在某项发现或提案根据本政策得到确认、具体、可安全公开且可执行后，才将其转入 Issues。
不属于公开 Issues 的内容
不要仅因以下事项创建公开 Issue：
- 仅限仓库或账户所有者的管理；
- 凭据管理或私有基础设施工作；
- 不宜披露的凭据、密钥或安全细节；
- 短暂的 CI、环境、网络或运行器噪声；
- 已解决的发现；
- 没有可复现的底层问题类别的孤立运行时标识符；
- 在安全运行、且没有已证实缺陷的警告；
- 没有明确问题和结果的推测性润色；
- 临时的发布或调试观察；或
- 来自审计或残余债务清扫的未分类笔记。
仅限所有者的操作属于仓库的运营所有者渠道，而非贡献者待办列表。一项发现只有通过资格关卡后才会成为公开 Issue。
报告内容
使用相应的 Issue 表单，并提供此结构中有用的部分：
- 问题 / 背景
- 影响
- 当前行为
- 预期行为
- 复现或证据
- 验收标准
- 非目标（如有用）
仅在影响报告时包含环境或版本信息。请删节日志和截图。绝不包含密钥、凭据、个人数据、私信、不必要的私有路径、状态数据库或终端记录。
漏洞和安全敏感发现必须使用 SECURITY.md 中的私有渠道，而不是公开 Issue。
分诊和重复项
提交前搜索公开和已关闭的 Issues。维护者将重复项链接到规范 Issue，并将其作为重复项关闭，而不是拆分讨论和证据。
使用最小的有用标签集。bug、enhancement、documentation、accessibility 和 technical-debt 描述工作；duplicate 描述分诊。维护者在决定报告是否合格前可以要求补充缺失证据。
在验收标准满足时、它重复了规范 Issue 时，或它超出范围、无法变得可执行或不再值得项目跟踪而以简短理由标记为不计划时，关闭 Issue。已解决的报告应指向解决它的证据。
贡献者标签
仅将 good first issue 用于安全、有边界、低歧义的工作，并且该工作为新贡献者提供足够的背景和验收标准。仅当确实欢迎外部贡献且任务描述足够明确时，才使用 help wanted。
关键的安全或认证边界、生命周期和恰好一次行为、破坏性安全、发布权限、提供商信任或远程代码执行边界、迁移和数据完整性，绝不自动成为适合初学者的工作。