maybe rather than "duplicate" somethng that streamlines merging duplicates (but that's more work I presume)

I'll clarify the title.

This requires:

• Completing T7805 first.
• Writing an alternate single-select mode for the ObjectSelector dialog.
• Writing the actual selection control for the comment area; possibly this should block on T5031 because the new control will be significantly more complicated than existing controls.

This probably now also blocks on T9132.

Any updates here? This task has been open for over a year now and it's something I wish for approximately weekly.

See Planning for information on timelines and progress.

that was not a particularly helpful response

What isn't helpful about it? I believe it has a complete answer to your question, and a great deal of detail explaining why that's the answer. How could it be more helpful? Did I misunderstand what you're asking?

Perhaps helpful for context is T6027, which was open for longer than this (about 18 months).

I gave the same answer there when asked the same question, in T6027#165656. This is the answer every time anyone asks for status updates: we develop in the open and do not have secret information we're hiding from you. Self-reported importance is a very weak signal and we do very little prioritization around it. The Planning document explains how and why we prioritize, and how to affect prioritization.

This task was ultimately prioritized (T6027#168668) and live in HEAD about 8 hours later (T6027#168793).

I do not recall ever having more information to provide to a user who asked for a status update. Although we do occasionally miss a task, we're generally very consistent about developing in the open and keeping tasks up to date.

I guess I was hoping for a timeline. Or an explanation of why it's hard
and not done yet. That page seems to me to say "we'll get to it when we
feel like it" (ok not a totally fair paraphrase, but it's one way to read
it). Waiting a year for a minor feature that would drastically improve one
of my workflows just makes it feel like you guys aren't being very
responsive to feedback about how the UI could be made better. And I have
plenty of other complaints about the ui - just haven't bothered filing most
of them.

To be totally clear, this is just my perspective and I'm probably not aware
of a lot of the other improvements being made to phabrictor instead. But
it does seem like you guys prioritize code quality / infrastructure over
most user-facing UI improvements, and avoid quick hacks that would give us
the features we want sooner. (to be fair I have sympathy for this: enough
quick hacks and you'll end up with a tangled mess... but maybe there's a
better balance to find?)

we develop in the open and do not have secret information we're hiding

from you

Yeah, I guess I just don't really know my way around secure.phabricator.com
to really understand the state of phabricator development; I can easily see
individual tasks, but not really getting the bigger picture. And I'm not
sure where I'd look for current prioritization info, which is what it
sounds like I should care about.

Unfortunately we have 1,500~ish tasks between 2 developers and we do our best to build things that we think we have the largest impact (which tends to mean small quality of life stuff doesn't happen as often). We'd love to bring more people on board to help improve Phabricator faster, but that means being evil and chasing money first to make that happen.

we'll get to it when we feel like it (ok not a totally fair paraphrase, but it's one way to read it)

This is basically the answer, yeah.

Waiting a year for a minor feature that would drastically improve one of my workflows just makes it feel like you guys aren't being very responsive to feedback about how the UI could be made better.

We have thousands of open tasks, and almost all of them have at least one user who considers them very important (whoever reported them). One user (or even a number of users) saying "this is important to me" isn't a very useful signal to us, because every task is important to someone.

Even if we tried to use "does someone want this?" this as a signal, it wouldn't actually help us prioritize, because almost every task is important under this metric.

We could try to use "votes" (e.g., tokens given or comments or something like that) as a signal instead, and figure out how many total users wanted a feature. If we did, this task would still be very far down the list: there are many tasks with much more user interest than this one. For example, T5474 is probably the "most important" task on this install under this metric.

If we did any of this, we'd get through a much smaller number of total tasks, because we couldn't take advantage of efficiencies in the development pipeline we gain by doing a lot of related work at once. When we're in an area of the codebase, we can plan better and get more done by fixing related and adjacent problems: all the testing can overlap, we have more freedom to rethink interactions that are being rewritten anyway, etc. In other cases, there are technical or infrastructure sequencing issues, and fixing one infrastructure problem unblocks a lot of product work. I've tried to explain this in the Planning document under "Maximizing Throughput", but maybe it could be more clear.

For example, we recently did a product iteration on Workboards and resolved a very large number of Workboard-related tasks while building many new features (https://secure.phabricator.com/project/board/773/query/Cvm409w.Zb0G/). This would have taken much longer if we'd tackled those tasks one at a time in "number of votes" order.

A signal we have found to be extremely worthwhile in prioritizing work is "is someone willing to pay us to prioritize it?". This is very well correlated with work which is legitimately valuable. Many of the features that are worth actual money to someone aren't very sexy and have very few votes, but they stand to improve someone's experience enough that they're willing to pay to get the problem fixed immediately. This is a really strong signal of real value to us.

And I'm not sure where I'd look for current prioritization info

You can see paid prioritization on the Prioritized workboard, in the "The Queue" column. The stuff we've been working on recently is T10751 (making Phabricator highly available) and T10748 (improving Conduit access to repository management). These aren't sexy product-facing tasks, but they're important for large installs and address major pain points faced by operations staff. Both of these tasks have both a large amount of external interest, and a customer who values them enough to pay us to prioritize them. This gives me a great deal of confidence that these tasks are legitimately some of the most important things we could be working on, and that our metrics for evaluating priority are good ones.

Beyond external prioritization, you can find general information on our "natural" roadmap at Roadmap. This lists larger goals we're pursuing in a general way when nothing is externally prioritized.

Small tasks like this don't generally show up anywhere; there's no way we can create an ordered list of 1,500+ tasks by priority, and that list would change frequently as new information becomes available, even if we spent a week sorting it and producing it once. There's no answer to when we'll pursue this, because it depends on other factors which are unknowable.

There is now a Edit Related Tasks → Close as Duplicate action next to the existing Edit Related Tasks → Merge Duplicates In action in the related tasks submenu. This change is live on this install: