Simplify Issue Management

[gregsdennis]

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:

1. they didn't address historical issues, leaving that mess alone
2. 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.

[Relequestual]

Assigned myself so I don't forget to look. No other reason.

[gregsdennis]

I think also having a "spec future" milestone or project might be good for things that we want to address but not in the next release.

We do have a draft-future milestone. Perhaps that can be renamed.

[gregsdennis]

Maybe one to identify implementation-specific issues as well.

[jdesrosiers]

I say, let's start implementing this as soon as someone is ready to take it on. We don't have to have all the details figured out before we start. This is a good place to start and we can iterate as we see what works and what doesn't.

[gregsdennis]

A nice thing about using projects (which I just discovered) is that projects are org-wide, which means they can be used to track issues from multiple repos. Really comes in handy for things like the Referencing spec concept.

[gregsdennis]

Okay. Most of this is done. I used a lot of batch operations, so there's probably still some clean-up that needs to be done. But I'm happy just addressing individual issues at this point.

Some things that weren't addressed:

• Type: Security should probably be reviewed individually
• Priority: * labels haven't been touched. Not sure what to do with these.
• Looks like dependabot adds the dependencies and language labels (e.g. python), which is annoying.
• I haven't perused the re-use / addlProps issues yet to see what these are about.
• I left the core and validation labels. They might be useful.

We're down to 16 labels now (from 42).

[gregsdennis]

I'm going to close this as the majority of the work on this is done. The rest is just maintenance going forward.