Nuances of Gitlab MR threads and comments - how to use for our advantage (proposal)

[Tymon Dąbrowski]

Hi,

I've noticed windragon using the mailing list for similar purpose so I
thought maybe I'll use it too :)

Please note that I don't mean that this is a *must do* kind of thing, but
more like how I use them and why in that particular way. I only write this
because maybe someone doesn't know the details or didn't think of it, and
maybe would like this kind of workflow too.

---

** TL;DR: ** There are Comments and Threads, in my opinion it's best to use
Comments for short things that don't need answers, and Threads for
discussions and pointing out issues in the MR/code. To create a Thread,
just click on the little arrow next to the "Comment" button. To answer a
Comment, click on the little "speech bubble" icon on the top right of the
comment. But do whatever you find most convenient.

-----

Gitlab's Merge Requests have two basic ways to post a message.
A. comments
B. threads
They look very similar but they have important differences.

A. Comments
- default type (that's what is posted if you press the big blue button)
- there is no "unresolved/resolved" state
- doesn't block merging
- it doesn't show a text box to answer, unless the user clicks on the
"Answer" button (little speech bubble icon on the top right of the Comment).

B. Threads
- you need to click the little arrow next to "Comment" to change the type
to "Start Thread"
- has the text box to answer available by default, so it's easy to answer to
- does have "unresolved/resolved" state (you can change at will)
- for the Merge Request to be merged, all Threads needs to be in "resolved"
state (otherwise the Merge button is greyed out) - so it blocks merging
until all of the Threads has been addressed

I usually use Comments for things like "good job!" or to ping specific
people or add notes on my own MR. Only for things that don't need an answer.

I usually use Threads to point out issues in the MR. That way I can be sure
that until they are all addressed properly (and set to "resolved" state),
the MR won't be merged (so it gives me extra safety). I also use it to
start a discussion, because the text box being visible encourages other
users to use the Thread to answer the topic, so the full topic is inside
one Thread, which makes it easier to manage (and you can fold the contents
when it's resolved and you don't need to look at the discussion any more).

Using Comments for discussions is less ideal, because people often answer
in a new comment instead of answering directly to the comment (because it's
only possible if you click that little button). That makes it less
convenient because (1) you cannot fold it to skip easily, (2) it's less
clear visibly that it's one discussion (unlike in a Thread) because there
are big gaps between Comments. (Using one Comment for one discussion would
be fine but the fact that textbox is hidden really discourages people to
use it that way. Probably especially people less accustomed to Gitlab, like
newcommers).

Note that if you add comments or suggestions to the code (by going to the
code area and clicking the little "Discussion" icon next to the code line),
they work like Threads but give a bit more functionality (adding
suggestions and applying them to the code).

---

Note that this is only a bit of information and a proposal, I don't mean to
enforce this as a rule. Any usage of a tool should make your job easier,
not harder, so choose whatever suits you.

I do hope that this email maybe helped someone.

You are welcome to answer this email to share your thoughts about this.


Regards,
Tiar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20220110/71d612f1/attachment.htm>