Comments API: resolved/unresolved comments

[laurentlb]

The comments API doesn't have the concept of resolved/unresolved threads, although most code review tools distinguish them. The current API allows us to surface this to the users, see #122243

However, this seems pretty limited. I find it difficult to identify all my unresolved comments. It's very easy to miss some of them. If the API had a boolean for unresolved comments, we could surface them in multiple ways:

• In the Comments panel, surface the number of unresolved comments, similar to what is done with Problems:
• In the Comments panel, highlight the unresolved comments (or put them in bold), so that it's obvious to the user what comments they still have to go through.
• In the Comments panel, have a way to hide/filter the resolved comments.
• In the Editor, consider consider using a different background color for unresolved comments. I currently use a different label for unresolved comments, but this is very subtle.
• In the gutter, use a different symbol for unresolved comments (e.g. or a diamond of another color).
• In the Editor, provide a way to go to the next unresolved comment (an alternative to Go to Next Comment Thread).

[laurentlb]

Let's discuss the API change.

IMO, the information should be part of a CommentThread.

On many levels, Comments seem similar to Diagnostics. A diagnostic is a comment provided by a tool such as a compiler. A comment is typically provided by a human. Diagnostics have a severity field, which indicates how important is the problem. We need an equivalent for Comments, something that tells the user if an action is expected (e.g. they need to resolve it) or not. Once the user addresses the comment, the importance is reduced.

1. A simplistic solution is to add a boolean, e.g. isResolved: boolean.
2. Similar to collapsibleState, we can go for a two-state enum instead: resolvedState: resolved | unresolved
3. Or to be more general: importance: high | low.

We might consider having more fields here. In a code review, multiple users interact with the comments. The current VSCode user is not necessarily the person who needs to do something. For example, the user has just updated the comment and they wait for a response. So the third value could be used to mean "it's not my turn" or "acknowledged, I'll come back later". The benefit is that the user can use the list of "unresolved" issues as a TODO-list and publish the comments once it's empty.

4. resolvedState: resolved | pending | unresolved

[isidorn]

@laurentlb Thank you very much for your proposal.
@rebornix, @alexr00 and me have quickly discussed this and we believe this proposal makes good sense.
We plan to start looking into it next milestone. Though no promises yet when this will land, we will know more in December when we start our investigation.