Improve handling of Duplicate issues

Description

In software with long history, new reported issues are a higher percentage of duplicates than actual new issues. For that reason, software like Bugzilla etc. makes duplicates a first class citizen.

Proposal

To have UI/UX for duplicates handling. For example in Bugzilla duplicates UI handling is mostly part of the UI of the generic relationships between issues. There it's possible to:

• Create duplicates from the UI (look at the bottom of the images):

• There are hints about the duplicate relationship between the bugs:

• and lately, you can filter them out in search so we don't end up looking at possible unrelated duplicates.

I guess the UI/UX for GitLab will be different, but I hope the pictures are clear enough for how it's used in Bugzilla.

Feature checklist

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

• Feature assurance
• Documentation
• Added to features.yml

mentioned in issue #35287 (closed)

changed the description

changed the description

changed the description

@csoriano It's already possible to mark an issue as a duplicate of another using the /duplicate quick action:

• https://docs.gitlab.com/ee/user/project/quick_actions.html#gitlab-quick-actions

This quick action will mention the duplicate in the original issue to create a cross reference and close the duplicate down. So all duplicates closed down that make a reference to the original issue, will be listed there in a system note.

For example the following issue was marked as a duplicate:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/39736#note_45553006

of the original issue here:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/21859#note_45553007

added Plan [DEPRECATED] awaiting feedback issues labels

Hey @markglenfletcher, you are right, that's why I mentioned "improving UI/UX" with the missing pieces. This issue was requested to be filed by @smcgivern for https://gitlab.com/gitlab-org/gitlab-ce/issues/35287#note_45531211, that might give you more context.

Let me try to enumerate the issues, I realized I didn't mention them properly:

• There is no UI for creating duplicates, like a button or so, but rather is semi-hidden with slash commands.
• There is not clear UI that shows the duplicate status of the bug report when browsing or searching bug reports, neither indication for to which report is duplicated to.
• It's not possible to filter out duplicated bug reports when searching and/or listing.
• There is not clear UI that lists the duplicated bugs linked to a single report in order for the maintainer and bug triaging team to have a single source where to look for more comments and cases about that issue.
• There is no duplicate creation prevention, as Bugzilla does providing possible duplicates when the user tries to create a bug report.

Providing some solution for any of those would be a nice addition.

Thanks @csoriano, that's very helpful!

@victorwu - see above

added ~14213 and removed awaiting feedback labels

changed title from Improve duplicates handling to Improve handling of Duplicate issues

@csoriano : As @markglenfletcher mentioned in https://gitlab.com/gitlab-org/gitlab-ce/issues/39751#note_45572146, we have a feature (related issues) that links two issues together. I am thinking we could expand on that so that we have another type of connection between any two issues, i.e. the duplicate relationship between any two issues.

So when you see a given issue, you could have a list of duplicates. You would need to make these associations pair-wise manually in the first iteration of the feature. But I can see a quick second iteration where given that: A <-dupe-> B, and then you mark an issue C as a dupe of B, automatically the system establishes that all three issues are pair-wise dupes, and if you visit any of those issues, you will see that relationship. I think that may be the smallest step in improving our dupe-related features. And would that satisfy your last point in https://gitlab.com/gitlab-org/gitlab-ce/issues/39751#note_45596819?

cc @smcgivern @sarrahvesselov on more comments.

@victorwu sounds excellent. Indeed, it would address my last point.

@smcgivern @sarrahvesselov : Let me know if that high-level design I sketched out in https://gitlab.com/gitlab-org/gitlab-ce/issues/39751#note_45675102 makes sense to you. I'll create another issue and we can track it there if yes.

@victorwu does that mean you want to move related issues from EES to CE, then?

@victorwu yes, that high-level design sounds excellent. Thanks!

@smcgivern : Thanks for the reminder. I was thinking the duplicate functionality I described earlier would be at least in EES. But I forgot that @csoriano and GNOME are using CE. Let's continue considering what is possible for CE.

Let me know if that high-level design I sketched out in https://gitlab.com/gitlab-org/gitlab-ce/issues/39751#note_45675102 makes sense to you. I'll create another issue and we can track it there if yes.

Makes sense @victorwu!

Just figure out I could give an example with a real case, this an issue on one of my projects:

You can see most of the activity is to mark as duplicated and to deal with duplicates in general, which is pretty common for long lived projects and it's quite time consuming for these kinds of projects where we have millions of users but only one project maintainer.

mentioned in issue #43566 (moved)

mentioned in issue #53004 (moved)

mentioned in issue #53561 (moved)

mentioned in issue #45891 (moved)

marked this issue as related to #53561 (moved)

marked this issue as related to #45891 (moved)

I proposed a solution to this in this comment with rough mockups https://gitlab.com/gitlab-org/gitlab-ce/issues/45891#note_115866386

• Expand and iterate on existing related issues modal for issue # input.
• Represent both related and duplicated relationship in the same table.
• Additional button to add duplicate relationship.

@meks: I like your mockup! In what program did you create it?

I like the concept but would prefer 2 separate tables (suggested in #53561 (moved)).
This makes for a clearer distinction between related and duplicate issues.
Why mix them together ?

Bugzilla also has them separated:

@chrizilla I use https://sketch.io/sketchpad/ But its probably not as good as the professional ones that our UX team uses. Its ok for quick sketches to convey the message across.

I like the suggestion of using 2 separate boxes, it actually fits better with our MVC methodology. We can just have 2 boxes one for Related and one for Duplicated issues.

Like this:

@meks: I like the suggestion of using 2 separate boxes, it actually fits better with our MVC methodology. We can just have 2 boxes one for Related and one for Duplicated issues.

Like this:

this is PERFECT !

mentioned in issue #53555 (closed)

mentioned in issue #55039 (moved)

mentioned in issue #57783 (moved)

added devopsplan label

added [deprecated] Accepting merge requests label

added groupproject management label

removed [deprecated] Accepting merge requests label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

removed the relation with gitlab#3963 (closed)