Indicating status of closed issues or merge requests

• Currently the status of closed issues and merge requests are shown as #1369 (closed).

• There are arguments for readability to put the (closed) before the issue number, https://gitlab.com/gitlab-org/gitlab-ce/issues/1369#note_27461481.

I think the existing implementation is totally fine with putting the status after the issue number.

I understand that that is not how that is read. However, in the majority of cases, issue numbers/linked are placed inside lists, or short sentences. In those cases, having the status afterward is easier to navigate the content.

I appreciate that it is a bit jarring to read. But to me (at least personally), I don't think it's a huge nuisance. I like to be jarred into knowing that an issue is closed. It is not just a casual adjective for me.

So I don't think we need to change anything. But I wanted to document this issue for further discussion so that we don't lose it.

mentioned in issue #1369 (closed)

Original argument:

It is kind of awkward to read the status after the issuable number. The status is an adjective, which normally comes before the subject in English.

"See #123 (closed) for more info" which is read as "See issue 123 closed for more info"

vs

"See (closed) #123 for more info" which is read as "See closed issue 123 for more info"

---

in the majority of cases, issue numbers/linked are placed inside lists, or short sentences.

@victorwu I would argue that it make short sentences more difficult to read. I keep reading "closed" as a verb which changes the meaning of the sentence.

Both options are equally readable in lists, but one is more readable in sentences, which is an important use case.

---

Another argument is that everywhere else on the site, the status is placed before the reference in the UI.

@deckar01 : I don't find it hard to read at all. The status is enclosed in parentheses and the whole thing is a link, which calls my attention to it that it is it's own object. It doesn't disturb my reading and I like to know when something is closed. Strikethough was a previous design. I found that very disruptive. I don't like the badges.

But this is all fairly subjective. I'd leave it up to design to make a call here, and they can consider if it deserves any user research.

cc @tauriedavis @dimitrieh

Why not mark closed issues and merge requests with strike through line? This will make it simpler to understand and won't require any additional reading. For merge requests text color can be different between merged and closed requests.

I am totally lost in all the issues and proposals about this. It seems the proposal in gitlab-org/gitlab-ce#20934 was too visually bloated. While I think the current implementation disrupts me when reading a sentence mentioning a closed issue. So I would like something in between.

But I am gonna leave this to more UX -savvy people to decide.

I prefer https://gitlab.com/gitlab-org/gitlab-ce/issues/23177, because it lets the user opt into additional information, but as far as I know nothing is scheduled to replace the current implementation.

The status here is meant as secondary information - which is why it is presented after the ID. On issue pages, the status is primary information which is why it holds more visual weight and comes first.

When you are on an issuable page, it is not necessary to know the issue ID - the status is more important. When referencing issuables, you are commonly not referencing the status, but the actual issue - the ID is more important.

The status here is meant as secondary information - which is why it is presented after the ID.

The problem is, in the context of a sentence, word order does not denote importance. English has rules about where modifiers are supposed to go. Adjectives come before the nouns they are modifying. My brain keeps trying to apply "merged" and "closed" to the sentence as a verb instead of an adjective.

Parenthesis are used to separate off information that isn’t essential to the meaning of the rest of the sentence. If you removed the material within the parenthesis, the sentence would still read correctly. This doesn't mean that you also read the sentence as if there are no parenthesis at all. Information within parenthesis can be an aside, clarative information, or descriptive.

closed

Thanks @tauriedavis and @deckar01 .

Let's proceed with the current design/implementation as @tauriedavis has closed this. In the future if there is more clear feedback that we need to make any changes, let's revisit. Thanks!

@SeanPackham also feel free to disprove me

I wish the closed issues were striked out as well. Having "(closed)" after an issue number is still not visually clear enough.