Page MenuHomePhabricator

Merging a duplicate doesn't import projects
Closed, WontfixPublic

Description

I've had some folks get confused because they thought merging a duplicate into a task would bring along the projects of the duplicate into the master task, and not just the subscribers. Turns out it doesn't. But it seems logical that it should?

Event Timeline

ahoffer2 raised the priority of this task from to Needs Triage.
ahoffer2 updated the task description. (Show Details)
ahoffer2 added a project: Maniphest.
ahoffer2 added subscribers: ahoffer2, epriestley.

This doesn't necessarily seem desirable to me. At least on this install, something like 95% of the tasks we close via merging are users filing bugs that already have existing tasks in the system. Sometimes this is just someone not searching, sometimes they searched but didn't find the right task, and sometimes it's because the other task treats the issue a little differently or there's some infrastructure blocker or something.

In many of these cases, the new task has worse projects (and sometimes incorrect projects), while the old task usually has correct projects. For example, the user is reporting a bug in Maniphest so they tag it "Maniphest", but the issue is really at a deeper layer of the infrastructure and the correct tag is "ApplicationTransactions" or "CustomFields" or something like that. The new task will have tags like "Maniphest" and "Phabricator" and be, like, "Comments in Maniphest should be orange", while the old task will have tags like "ApplicationTransactions" and "Design" and be like "Comments in every application should be orange".

If we brought projects over in this case, it would decrease the overall correctness and accuracy of projects on the combined task. Tasks which receive several merges would tend to accumulate multiple irrelevant tags: "Differential", "Diffusion", "Maniphest", etc., from "Comments in <each individual application> should be orange" tasks.

Overall, almost every merge we do is essentially redirecting a "bad" duplicate task to a "good" existing one that has been triaged and has context, and very rarely do merges combining two "equal" tasks. When we're closing a "bad" task, it seems correct to throw away most of the metadata.

We also throw away almost all of the metadata consistently: we don't try to, say, average the task priorities, or touch the author/assignee fields, or merge the comments or descriptions, for example. The thinking here is largely for the same reasons as above, although it would also be technically involved in some cases (we can't easily have multiple task authors, for example).

Overall, two thoughts here:

  • Is your use case different from ours (i.e., not overwhelmingly redirecting "bad" duplicate tasks to "good" ones)?
  • If your use case is similar, is any of this possibly caused by confusion over which way tasks merge? That is, you get the best results if you take the "Merge Duplicates In" action from the "good" task, but there's no corresponding "Close as Duplicate..." action you could take from the "bad" task. If you perform the merge from the bad task, you'll get not-so-great results in some cases. Is it possible some of this confusion could be dealt with by making it more obvious which task is being thrown away?

I talked with the dev who reported this, his take is:

I think our use of maniphest is sufficiently different that we prefer to retain the projects. Actually, averaging or taking the higher of the two priorities would also be good.

  • We're frequently merging two "equal weight" bugs that may reflect different aspects of the same underlying issue.
  • In any case, I think that we would prefer to over-tag rather than under-tag. This helps to prevent duplicate bug reports, and also prevents bugs from getting lost.

Personally, I don't think it's a huge deal either way and not a top priority to fix, but I think the idea that subscribers carry but projects don't is just slightly counterinuitive behavior that leads people to expect the projects to carry over.

The easiest way to think about it is we carry over nothing that is defining of the task, such as title, description, projects, or custom fields. We simply link the tasks together for reference. Subscribers don't really define an individual task, at least in most cases.

We've found first hand with Workboards, that defining things magically (like priority) are interesting in theory, but were confusing as the default and source of many complaints. So we have some concerns there as well.

chad claimed this task.

I'm going to close this as wontfix. We're feel we have the correct default here and adding additional options isn't something we're likely to pursue in the upstream.