Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Issue Management #1526

Open
gregsdennis opened this issue Jun 21, 2024 · 3 comments
Open

Simplify Issue Management #1526

gregsdennis opened this issue Jun 21, 2024 · 3 comments
Assignees

Comments

@gregsdennis
Copy link
Member

gregsdennis commented Jun 21, 2024

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.

@gregsdennis gregsdennis changed the title Simpler Issue Management Simplify Issue Management Jun 21, 2024
@gregsdennis gregsdennis added the agenda For the OCWM agenda label Jun 21, 2024
@Relequestual Relequestual self-assigned this Jun 24, 2024
@Relequestual
Copy link
Member

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

@gregsdennis gregsdennis removed the agenda For the OCWM agenda label Jun 24, 2024
@gregsdennis
Copy link
Member Author

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
Copy link
Member Author

Maybe one to identify implementation-specific issues as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants