Multiple choice reply
What
Within a comment, at mention another user. And at the same time, specify a few responses. This can be via some special markdown or a dedicated UI/modal.
As the responder, you can select one of the responses provided, and GitLab adds a comment for you.
Why
There are a lot of communications at GitLab. Often times, there is not clear expectation of what is required by someone responding to a message. Sometimes people ask for a specific question and expect a response. Sometimes they just cc
. Sometimes they fyi
. Sometimes they just at mention with no context at all.
I think in most cases, it should fall on the initiator of the conversation to drive the conversation and provide context and be intentional in what information they want. This is "pull-based" model of conversation and I think is what makes GitLab as a company successful. We have so many initiatives going on, it's hard to expect everyone to participate in everything. So we should trust the people who are leading the initiatives to make the best decisions, and thus, drive the conversation. A feature like this precisely encourages this behavior, because it makes it a lot easier for an initiator to describe what they want. Furthermore, the responder may only have to just simply click a response (instead of typing), which further makes it easier and less friction for everyone to contribute.
This feature will not discourage collaboration and contribution. At GitLab, there are a few ways to leverage your communications (and move things along). Roughly, these include:
- Your manager pings you for something. So you should respond.
- A co-worker that is part of your "regular team" and pings you for something, and their work directly is blocked by you. You should unblock them because since they are part of your "regular team", their work is very likely related to your work.
- A co-worker that is not part of your "regular team" pings you, and it's a nonblocking initiative. You may not respond.
In the first case, you are likely to respond, and so this proposed feature is less useful because you are already incented to respond. The quick response UI would be helpful however. The latter two cases are helpful because they reduce the friction of responding and help the initiator frame the discussion and set up structured collaboration. In the last case, the initiator of the conversation really needs to leverage "excitement" to get the responder to engage. At GitLab, this has been very successful to get parties across departments collaborating on initiatives that are not part of their job description. But because they are personally passionate about something, they add value. This is great. A passionate individual would continue to use existing mechanisms of GitLab to communicate, so this feature is not for them specifically, but it would not block them!
Opportunity
Typical messaging technologies and designs in business apps have learned a lot from consumer apps over the years. This is an interesting problem space because we are focused specifically on a business communications problem. I think this would be really interesting to explore and see how it differentiates from the consumer space more broadly.