(I marked D15981 as fixing this but I'm going to leave it open for confirmation since I'm not completely sure there weren't more cases that I missed.)

T6102 and the downstream also contain discussion of a second case which does center around exact matches -- searching for "Wikidata" -- but I can't reproduce it at HEAD:

D15981 doesn't, strictly speaking, prioritize exact matches. However, it should fix the underlying issue.

My tentative plan here is:

A sub-problem here is that if daemons discover commits but those commits are deleted before they can be processed, the tasks fail forever. This is normally unusual (git won't GC the commits for a few weeks, which often gives the daemons enough time to process them) but cases like fiddling with tracking, re-cloning a repository, everyone going on vacation for a couple weeks, or clustering an observed repository can exacerbate them.

You can test with "Discovery" at https://phabricator.wikimedia.org/

Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:

Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).

The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:

I can remember trying to file a bug against Safari when I worked at Apple, seems like a simple task. But typing "Safari" came back with 50-100 tags... I had no clue as a first time filer what to fill out. A short description might have helped, perhaps. But overall I guess I'd like to understand what users are ending up at the browse dialog to begin with. In the Safari case, having something like Nuance is better for the novice user than asking them to wade through 50 results and guess the correct one. I want to basically make sure we understand which user we're helping here.

I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.

I worry overall that this will compound the issue when installs have too many projects. That is, if they already have hundreds/thousands of projects, doubling the information makes the UI twice as large and difficult to navigate through. Maybe one idea would be to only show additional information optionally (via a checkbox) or only after results start to get filtered?

My plan is to put an on-hover (always available on mobile) edit icon on top of the thumbs on the edit UI, similar to how the interaction works on workboard cards:

It should probably go under T10978, I believe. I imagine it would get it for free, but worth mentioning over there nonetheless.

I thought I tried that too, but perhaps I'm confused between differential and diffusion (such very confusing terminology for people new to phabricator!). I'm making inline comments against the commits, not against code reviews.

This task is for inline comments on a diff in Differential.

This feature is very important to me, so I've been following along. However perhaps I'm missing something and cannot get the new functionality to work as I expect.

On the "public preview" use case I do think "--plan-changes + [DRAFT] in title + just let Herald triggers fire, if users configured them they can deal with knowing about your not-quite-perfect-yet changes" is fairly reasonable, which is part of why I've resisted pursuing this until now.

(not that adding the feature would harm us, just my 2 cents)

We have a particularly opinionated set of developers here (when I say "opinionated", I mean roughly, nobody ever agrees on anything) and we've managed to successfully argue in favor of just using "plan changes" rather than opting for some other intermediary or distinct state. It correctly communicates to reviewers what you should want them to know: you're not done with the revision yet. Far and away the largest reason why this is our accepted workflow, rather than pushing on upstream to implement a "Not Yet Ready for Review" state is very tightly coupled to the entire concept of why Phabricator does review the way it does:

to avoid accidentally forgetting to pass an additional option in cases where you did intend it

Another possibility is:

We've never seen any real interest from other installs in a default preview-before-publish mode, and I'm not aware of any class of mistakes that users routinely make or wish to correct which this mode would aid in (if I was, we'd try to detect/fix them in arc diff so users didn't need to go to the browser). We've also never seen other interest in the annotate-before-publish use case. T949 is the only task in this vein that I was able to dig up, and focused on previewing the diff only. I'm not really sure what problems this mode solves outside easing adoption when coming from another tool which works like this.

For localization, I'd expect to customize timezone and Time format (24/12 hours), and maybe "Week Starts On".

In the "final look before publishing" use case, the best value for "Reviewers" is probably the final, effective set of reviewers (i.e., including reviewers from Herald and Owners), so you can see exactly who the revision will be published to. In the competing "share with a few people" use case, the best value for "Reviewers" is only explicit reviewers (you don't want to notify or involve others).

+1 to what Eitan said. The first two of those for sure. The first means we have this horrendous patch in place today in order to make it happen so we don't flood everyone with email :)

We want to be able to set

• email settings. We handle specific types of email OOB of phabricator. For example "X is committed" and "X reverted Y" (audit-commit and audit-other mailtags).
• default time zone. Most, but not all of our engineers are in P[DS]T instead of UTC. We'd like to set this as a default without making it a server-wide mandated value
• Default "Pinned Applications".

Current "Homepage" in general is not long for this world. We'll get rid of current hardcoded homepage, and build stuff from Dashboards / PanelNavs I imagine.

Being able to change the default set of applications shown on the side panel would be really useful for us. Not sure if this was split off though.

As a sanity check here before I actually build it, is anyone who is interested in configuring global default settings interested in configuring any settings other than mail-related settings? Or is this just T9161 in an alternate form, practically speaking?

This appears to be stable and working properly, at least for the most part.

@joshuaspence, see T11010, I think. Not sure why nginx was 502'ing there, but should be fixed in HEAD.

We can also use weird implicit magic to try to resolve this. Here's a ruleset that will make everyone equally confused and unhappy:

That's a lot more clear, thanks!

I think that that creates some tension that I'm not immediately sure how to resolve:

The user story most important to us is:

In T10855#172123, @chad wrote:

A Phriction Panel which we talked about briefly would provide this automagically without wiring Dashboards to Conduit.

We would be okay with this too.

We aren't really sold on this as a specific use case, but can give you a modern dashboard.panel.edit which will let you implement it. If there are weird followups arising from this (like difficulty managing the 300,000 transactions on the panel detail a year from now) we may be somewhat less sympathetic to them than we would be to a more on-label use case.

This is about two hours of work.

There were ultimately two sort of related requests here, although some of the discussion happened off-thread. Let's call them arc diff --draft and arc diff --try:

unfortumately

The time zone selected below has been auto-detected based on your browser settings

I tried it out. One thing I realized was that without having the context of this ticket, during the pop-up after you click the notification, it's not obvious whether the timezone being shown is the *current* setting or the *new setting based on your browser*. That could cause confusion, so would suggest a slight phrasing change there.

General question: Why is the owners option "Add as reviewer (blocking)" if an owner uploads a revision? I know that this is expected, but why? For example at Wikimedia we currently have the system, that every change needs a review from an "owner" before the patch gets merged, so it's not useful, if an owner of the package uploads a change, and no reviewers get added. Maybe the a compromise may be a setting, where you can choose, if a package gets added as reviewer too, if the author of the revision is an owner too? I think that would help all.

I don't know how to reproduce the issue, but figured I'd let you know that I'm seeing this in our error logs:

These changes are live on this install:

These changes are now live on this install.

D15962 attempts to guess the user's timezone by using the Intl API. This appears to be very accurate in Chrome on OSX, but useless in Safari/Firefox.

D15961 adds a timezone correction workflow, including a temporary "ignore conflict" option. This flag is cleared after the next timezone change.

After D15959, user.search should support "find all non-disabled human users", likely with parameters in this vein:

I think T5953 is a better fit for that in the upstream.