Issue State Description

[techknowlogick]

Feature Description

Instead of using labels to describe issue states (dupe, archived, etc..), additional descriptive metadata could be added to issues.

To ensure backwards compatibility, open/closed could be kept, but then you could add search by state, etc.. We have "mentioned in issues #xyz" issue linking, and we could leverage that to be "duplicate issue #abc marked as duplicate of this issue. The subscribers to the initial ticket that is marked as dupe could be transferred to the open ticket.

type IssueState int64
const (
  Archived IssueState = iota
  Duplicate
  Draft   // Issue that is open but still being worked on, similar to draft PR. We could also use this for draft PRs.
  // ...
) 

Screenshots

[silverwind]

Do we really need to split the "not planned" state? I think it's unnecessary and by having these sub-states, migrations from GitHub will become more inaccurate too.

[delvh]

I disagree at least to some extent:
We certainly need a third issue state to distinguish between closed successfully (merged, implemented, bug fixed), and closed unsuccessfully (not planned, duplicate, stale, …).
That one is certainly needed.

However, I'm not sure if we (should) need anything on top of that.
I think GitHub made a wise decision only allowing these three states (open, closed successfully, closed without success).
Everything else complicates the UI.

What we can rather think about is offering an additional "reason" field when closing an issue, i.e. a combobox with no default.
The only difference will then be the reason for closing in the issue timeline.
But that one is not as pressing as adding a third issue state.

[silverwind]

@delvh I see no disagreement in your comment. So GitHub has:

• open
• close (completed)
• close (not planned)

With #25362 we would have:

• open
• close (resolved)
• close (archived)
• close (stale)

I think it's very unwise to picture precise reason in state. What if for example someone requests close (spam) state? Would we then make a fifth state? By being decisively unspecific with the "grey state", we avoid having to implement more odd states in the future.

[denyskon]

I can agree with the arguments: I think we shouldn't clutter the UI with too specific issue states.
I'd also say we only really need three of them, but I'm not a fan of GitHub's naming though. I'd suggest the following three:

• open
• resolved
• closed (without success)

[silverwind]

I do prefer GitHub's way because a "resolved" issue is still closed, so state (open/close) should remain a boolean, which also makes APIs easier to consume and more importantly not break by introducing the third state.

[delvh]

I mean, just because we call it resolved doesn't mean we can't treat it as closed…

[silverwind]

What we display in UI vs. what we store in DB can be different. For DB I suggest:

isClosed: true | false (unchanged)
issueState: "completed" | "notPlanned"

UI could show single string Open, Completed, Not Planned. I would suggest never extending issueState in the future unless there is a very good reason.

isClosed true = green color
issueState completed, isClosed true = purple color
issueState notPlanned, isClosed true = gray color

[BLumia]

Just link a related comment here: #14893 (comment)

We should probably keep 2 states (open/close) state and maybe add a field like closeReason.

GitHub also still keeps 2 states (open/close), the extra info is provided by an additional attribute names state_reason, with currently two possible value complete (the default one) and not-planned.

Personally, I would like to +1 for do the same instead of recommend user to fiddle with tags, since:

• Reason of closing an issue could be very, but the state_reason represent the two main type/catalog of close reason: positive and negative, or say, valid and invalid. If detailed reason needs to be provided, then tag could be useful.
• Currently issue tags cannot be modular/grouped, which results in a bunch of tags to select even if we only want to add a single dimension of data.
  • There is actually a feature request for this: [Feature Request] Modular issue label sets #18583
  • Although GitHub's issue tags also aren't modular, GitHub does have a pretty useful Project (the one currently in beta, not the old Kanban-only style one) panel allow adding extra field that's modular. Also see this.