Fuse issues and merge requests

Description

Why do GitLab, GitHub, and other Git web-apps distinguish between issues and merge/pull requests?

I found only one other instance of this question, so the following may be a naive questioning of a proven optimum, and/or an astonishing revelation about an unquestioned assumption.

Proposal

Links / references

https://docs.gitlab.com/ce/workflow/gitlab_flow.html#merge-pull-requests-with-gitlab-flow

Documentation blurb

Overview

What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?

To me as a power-user, beta tester, documentation proof-reader, bug hunter, but only novice programmer, they appear in those web-apps as fundamentally the same thing: top-to-bottom discussion spaces with a unique number. The significant difference is the degree to which they are sprinkled with metadata:

  • labels, assignees, etc. in both cases
  • in case of MRs: code-related metadata like reviewers, of course commits, therefore necessary diffs, thereby enabled line-by-line comments

A WIP-MR without commits is basically an issue. A fully-grown MR is basically an issue in which the discussion can expand into the diff, no? However, MRs currently need to be linked back to an issue. Or, commit message keywords like closes # have to be used in order to link them to issues and to facilitate automations.

So, why maintain similar structures, plus the connections between them? Why not do away with the distinction and have only a single entity (maybe “topic”)?

Use cases

Who is this for? Provide one or more use cases.

Imagine: to start discussing anything within a repository, you start such a topic. If you can contribute code to that discussion, you push commits. Ideally not to a branch in a forked repo you have to create first, but directly to the topic #, which GitLab automatically turns into a branch like topic-#-username. That way, someone else can push as well. In any case, the topic is now enriched with diffs, within which the discussion can become more specific and review-y.

The intention to merge such a “topic branch” (Heard that before 🤔) would need to be moved from the action of opening an MR, to a specific button click within that topic, or a commit message keyword.

IMHO, this idea leaves the GitFlow model intact for expert users, only reducing the need to cross-reference issues, MRs and commits with each other.

Also, this feature proposal potentially eases the introduction of newbies to GitLab, because the cognitive load like "announce/discuss in issues" vs. "review code in MRs, although the GUI is basically the same". could be reduced.

Mock up (pencil-grey means same as currently, blue are the changes proposed here)

GitLab-CE-35433-fuse-issues-MRs

  • A) The Create Merge Request button could be replaced by like Start work, and moved to a sticky position at the bottom of the discussion/comments.
  • B) That button would open a pop-up with command line instructions similar to those on a new project's Overview/Details page. Or, those instructions could be visible at that sticky position, in case no active "I will start working on this" indication is needed.
  • C) Once that local branch gets published to the server (commits getting pushed "into the topic", so to speak), the mr-state-widget would appear, either at this bottom position, or at the "topic's" original post, with the comments maybe folded together.
  • D) The merge-request-tabs-holder would remain just where it is currently MRs, with the notes-tab present. I simply forgot to draw it there :-/ Also, that could be renamed from "Discussion" to "Review", and the previously separate comments (notes-list, right) could be folded into a tab like "Discussion leading up to this work".

Feature checklist

Make sure these are completed before closing the issue, with a link to the relevant commit.

Edited by 🤖 GitLab Bot 🤖