Discussion: GAP `status` field
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
调研方向
首先阅读 CONTRIBUTING.md 以及 issue 中描述的 metadata.yml 结构，然后检查网站或 deploy previews 中如何表示 GAP 状态。明确状态和撤回的语义，包括由谁接受 GAP，并更新相关指南和元数据定义，使其只有一个明确的事实来源。
由索引模型根据 Issue 内容生成。
描述
CONTRIBUTING.md currently states the statuses as:
# GAPs are never "strawman". Later we'll probably add additional statuses. If in
# doubt, choose "proposal"
status: proposal | draft | accepted
PEP statuses prior art fwiw:
Status: <Draft | Active | Accepted | Provisional | Deferred | Rejected |
Withdrawn | Final | Superseded>
We currently offer no guidance or definition for what it means for a GAP to be "accepted". Accepted by whom?
GAPs are explicitly community specs, and don't need to be "accepted" by anyone other than the initial sponsor and authors.
(The role of sponsor imo should be to check "does this GAP make sense, is it appropriate for this repo", and not "do I personally agree this is a good idea" -- and we should clarify this)
The statuses of a GAP could be considered implicitly as:
- "proposal" = GAP PR is still open
- "draft" = GAP PR has been merged with a DRAFT.md but no version directory has been created
- "accepted" = GAP PR has been merged and a version has been published.
Do we need an extra field?
To be clear, we could still display a "status" field in the frontmatter of the GAP document on the website or in deploy previews, but this can be calculated based on the above.
Proposal
(1) Remove status to avoid duplicate sources of truth to keep in sync.
(2) Add an additional optional withdrawn field in metadata.yml to encode the state of 'withdrawn' (i.e a GAPs has been withdrawn but without any superseding GAP).
related:
- <number>
replaces: <number>
-supersededBy: <number>
+withdrawn:
+ # fields in `withdrawn` are mutually exclusive
+ supersededBy: <number>
+ reason: <number>
tags:
- <string>
@benjie wdyt?
- 主要语言
- JavaScript
- 星标
- 10
- 派生
- 8
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
graphql/gaps 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 48/100
-
难度 5/5 一周以上 新手友好度 25/100
-
难度 3/5 1-2 天 新手友好度 45/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
enhancement
难度 1/5 1 小时以内 新手友好度 84/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
-
难度 2/5 1-3 小时 新手友好度 66/100
remotion-dev/remotion#13341 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
svix/svix-webhooks#2808 ·
维护者通常 1 天内回复