You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issues in this repo have been left unattended for a while, and it's time to clean house.
Several attempts at this have occurred previously, and many of them were fine, but they failed in that:
they didn't address historical issues, leaving that mess alone
no one kept it up
While the second can only be addressed by active effort, I think the first we can address by a good old-fashioned overhaul.
Feature Proposals
Since we're handling the feature proposals using the Feature Life Cycle and committed proposal documents, it makes sense that several issues could be opened against that feature. Thus we need a way to group all such issues and track them through their life cycle.
I think a project would do nicely for that as it can handle both needs (grouping and issue life cycle).
Currently, for the stable spec development effort, I have the following stages:
In discussion
Awaiting PR
PR available
Done
This is simple and does the job.
I don't want to use labels for this because labels in GitHub are really designed to be an unchanging set. Since proposals come and go, it doesn't make sense to have a dedicated label created for each one.
Specification Clarifications
We do receive reports and suggestions for clarifying aspects of the current specification. These typically are one-off and aren't really tied to other issues.
Here I think a clarification label will be good. Maybe we can also have a perpetual project for this with similar issue life cycle stages as for feature proposals.
I generally prefer the way projects manage issue status over trying to use labels.
Questions
We also receive general questions from users and implementers.
I think a label here would be fine, but maybe we should move/convert such issues to discussions and answer them there?
Admin
For admin things I think a label is fine. Probably don't need to track issue status.
Legacy
I don't think that it's right to completely remove labels from everything in order to fit what I've described above, but maybe we can do some reorganizing.
We have 42 labels currently.
Label
Open
Closed
Recommendation
$data
0
10
Move to new "data" project. Keep open. Remove label.
[ノಠ益ಠ]ノ彡┻━┻
0
3
Remove label.
administrative
2
45
(Well 3 open now with this issue.)
agenda
2
0
This is managed by the OCWM bot. Needs to stay.
annotation
1
64
Move to "annotation" project. Remove label.
core
21
199
dependencies
0
8
These are from dependabot, not the keyword. Remove label.
duplicate
0
1
Remove label. No need to recall duplicates.
errata
0
4
Replace with "clarification" label.
feedback
2
23
Replace with "clarification" label.
format
1
40
Move to "format" project. Remove label.
hypermedia
0
111
Move to "hypermedia" project and close.* Remove label.
javascript
0
2
Remove label.
I18n
1
0
Move to "localization" project. Remove label.
output
4
24
Move to "output" project. Remove label.
pr-available
0
5
Remove label.
pr-merged
0
13
Remove label.
pr-rejected
0
1
Remove label.
Priority: Critical
0
5
Priority: High
1
91
Priority: Low
2
26
Priority: Medium
6
79
proposal
17
0
Recently added to identify proposals. These need to be moved into appropriate projects. Then the label can be removed.
re-use / addlProps
0
12
Not sure here.
referencing
5
5
Move into "referencing" project. Remove label.
rel json pointer
3
2
Move into "rel json pointer" project. Remove label.
reminder
0
2
Remove label.
sdlc
1
10
Most of these became irrelevant. Move into "sdlc" project and mark completed. Remove label.
Status: Abandoned
0
1
Remove label.
Status: Blocked
0
4
Remove label.
Status: Consensus
1
24
Remove label.
Status: In Progress
0
8
Remove label.
Status: On Hold
2
12
Remove label.
triage
0
2
Should be added by default to every issue, then removed manually when the issue is addressed.
Type: Bug
2
70
Do we have bugs on a specification? Maybe rename to / merge with "clarification"?
Type: Enhancement
10
124
Type: Maintenance
2
154
This seems the same as what "Type: Bug" is. I say combine them.
Type: Question
1
72
Type: Security
2
6
validation
1
69
vocabulary
4
29
Move to "vocabularies" project. Remove label.
¯\_[ツ]_/¯
0
8
Remove label.
Not sure what to do with the blank ones. Some of them seem good to keep.
I think it might also be good to document this or whatever process we settle on.
The text was updated successfully, but these errors were encountered:
The issues in this repo have been left unattended for a while, and it's time to clean house.
Several attempts at this have occurred previously, and many of them were fine, but they failed in that:
While the second can only be addressed by active effort, I think the first we can address by a good old-fashioned overhaul.
Feature Proposals
Since we're handling the feature proposals using the Feature Life Cycle and committed proposal documents, it makes sense that several issues could be opened against that feature. Thus we need a way to group all such issues and track them through their life cycle.
I think a project would do nicely for that as it can handle both needs (grouping and issue life cycle).
Currently, for the stable spec development effort, I have the following stages:
This is simple and does the job.
I don't want to use labels for this because labels in GitHub are really designed to be an unchanging set. Since proposals come and go, it doesn't make sense to have a dedicated label created for each one.
Specification Clarifications
We do receive reports and suggestions for clarifying aspects of the current specification. These typically are one-off and aren't really tied to other issues.
Here I think a
clarification
label will be good. Maybe we can also have a perpetual project for this with similar issue life cycle stages as for feature proposals.I generally prefer the way projects manage issue status over trying to use labels.
Questions
We also receive general questions from users and implementers.
I think a label here would be fine, but maybe we should move/convert such issues to discussions and answer them there?
Admin
For admin things I think a label is fine. Probably don't need to track issue status.
Legacy
I don't think that it's right to completely remove labels from everything in order to fit what I've described above, but maybe we can do some reorganizing.
We have 42 labels currently.
$data
[ノಠ益ಠ]ノ彡┻━┻
administrative
agenda
annotation
core
dependencies
duplicate
errata
feedback
format
hypermedia
javascript
I18n
output
pr-available
pr-merged
pr-rejected
Priority: Critical
Priority: High
Priority: Low
Priority: Medium
proposal
re-use / addlProps
referencing
rel json pointer
reminder
sdlc
Status: Abandoned
Status: Blocked
Status: Consensus
Status: In Progress
Status: On Hold
triage
Type: Bug
Type: Enhancement
Type: Maintenance
Type: Question
Type: Security
validation
vocabulary
¯\_[ツ]_/¯
Not sure what to do with the blank ones. Some of them seem good to keep.
I think it might also be good to document this or whatever process we settle on.
The text was updated successfully, but these errors were encountered: