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?
CONTRIBUTING.mdcurrently states the statuses as:PEP statuses prior art fwiw:
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:
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
statusto avoid duplicate sources of truth to keep in sync.(2) Add an additional optional
withdrawnfield in metadata.yml to encode the state of 'withdrawn' (i.e a GAPs has been withdrawn but without any superseding GAP).@benjie wdyt?