Wikimedia ran a vote to find which problems are the most annoying to developers (not limited to problems with Phabricator) and this one was the most voted by far, with over one third of the participants voting on it.

Can we please add the keyword subscribe or subscribers in this task title? I looked through 2 pages of subscribers search before filing a dup. I know now I was searching the wrong term, mention would have given it to me instead. But they are related.

We would also like this behaviour, and currently use a workaround to accomplish it (which is why we never came here looking for a fix). We created a custom Create Task form that sets the default view policy to include subscribers.

No easy way to apply a policy to a group of repos.

In T5000#176440, @epriestley wrote:

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

Finding version information seems non-trivial if you're not an administrator of the Phabricator installation. We appear to be running 0426ce73f0e63f1900f1cc285cfa1465ea72317e.

Please read and follow Contributing Bug Reports. This isn't a valid bug report and won't currently be accepted as is. Specifically we require version information of the install and steps we can follow locally to reproduce the issue.

Although I earlier (in T6630#85282) felt like it was reasonable to consider separating Audit and Diffusion, there are now more existing or planned integration points and I think this approach is significantly less reasonable than the "merge them" approach. It also doesn't seem to be causing any problems on real installs.

For T5214 / T12074, I am moving forward with an API query model where columns are associated with another, different object as a boardPHID (currently, always a project), and boards do not have their own objects or PHIDs.

This one is fine, I'm still going to fiddle with "in" too.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Thank you! The new dialog looks excellent, it would have prevented my error.

Here's the revised dialog after D16956:

I don't think that edit is always invalid: offhand, one reason you might want to make such an edit is so that you can add a tag to all events in a series, allowing you to query them so they can be exported to another calendar. Another case I could imagine is wanting to correct a mistake in the description of an event when you know nothing will be lost by editing future events (e.g., because you are the only user who can edit the event).

Maybe it would also be sensible to not allow mass-edits to be triggered by past events. While it may be useful to tweak a single past event, I don't see much of a use case of updating all events starting from some past date. I'd argue that that is nearly always unintended.

Thanks @epriestley for the reply. Seems like my mental model of "prototypes" along with the misleading wording of "future" threw me off.

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

Hi @epriestley, thank you for your explanation.

This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)

Generally, our behavior here is approximately the same as Calendar.app and Google Calendar. T11804 documents how various edge cases behave in those applications. I believe our behavior is no more spooky in any case I'm aware of.

Maybe this is a misinterpretation of "All Future Events"? That means "All events which start after this event starts", not "all events which have not yet occurred, considering the current time".

I'm still having trouble figuring out which past events were edited. Downstream has this query:

Oh, sorry, E66 would have been disconnected from past events by the edit. Let me look through the downstream task.

Assuming that's just a miscommunication, I can't immediately reproduce this locally:

E66 is the first event in the series, so I would expect editing E66 "All Future Events" to edit every event in the series: there are no past instances. Am I misunderstanding? What's an example of a past instance?

Yeah, I tend to agree. I don't really see any approaches we can take here that don't make things a little worse for experienced users who already know what they're looking for, and I'm not sure there's too much of a use case left for less-experienced users.

The main concern for me would be typeaheads are for knowing what you're looking for already, and making that faster / easier. Browse interfaces are for discovery.

This is sort of what I was thinking about for the "Search Description" / "Usage Hint" (descriptions / projects are random examples):

(You could write some similar rules if you want to try something in that vein, although it's a pretty big pain to fork JS/CSS right now.)

I should make a Herald rule to auto-resign.

Okay well @chad resigned from D16893 as soon as he saw animation in a CSS file so I don't think that one's going anywhere.

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Ah, thanks! I've asked downstream if anyone still runs into any issues, but so far I also believe this is now resolved.

Alright, I'm going to try this:

The most-likely-to-work secret magic for "Not in: Wikidata" is not(wikidata):

phabricator.wikimedia.org is running a version including these changes plus D16886 on top. So far it looks like a great improvement!

+1 to what 20after4 wrote. The approach is definitely helpful, and to make this look less cluttered and inconsistent ("are projects with longer descriptions which take up more vertical space somehow more important?"), cutting off project descriptions seems like a good compromise.

I caught another case of this: here, "Phacility" should be first, but is not.

FWIW: I believe @paladox means well, he's just young/inexperienced and overly enthusiastic. The decision to ban him is entirely reasonable for upstream though, given the circumstances.

In T11034#199653, @epriestley wrote:

---

Now that this has been deployed for a while, I'm curious if there's any feedback about it? Specifically:

• Does this approach generally seem like it's a reasonable solution to the problem (if not in its current form, in some similar form which handles these issues more gracefully)? Or are we not really in the right ballpark?

I suppose an alternate path is to enable Dashboards on Project homepages, and you can embed your project wiki or text panel for a really cool long description and information.

Would you fill out at least, like, 5 of them?

Hovercards, Search, Browse, etc. It could get used.

We could call it "Search Description" so it feels clear that it only displays in some UIs.

Yeah, I think it's pretty reasonable if people would actually fill it out. We could surface it in a few other places too (e.g., /projects/) without fallback. It just seems like there's a decent chance no one will ever fill it out and it will sort of just be cluttering up the UI. But the cost on our side is pretty small, so if some people claim that they'd probably want to fill it out I'm happy to move forward with it.

Provide an alternate, text-only field for "Project summary in typehaead results." which users only enter text into, so we don't have to worry about remarkup.

For reference, here's the current state of "discovery" downstream:

I believe this is now resolved, in the sense that I expect all specific, reproducible examples I'm aware of function in a way consistent with user expectation. In particular:

I have some possible approaches for cheating on the "more than 100 results" case, but I think we ultimately need to put the prefix paging rule on the server side, so we return all prefix matches and then all content matches. That's kind of a big mess, but all the ways we can cheat will break down at some point (e.g., when you have 100 "wikidata" projects that are alphabetically earlier than "wikidata") so I think it's not avoidable.

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works:

T11747 wants a more advanced version of this (reviewing diffs between rendered documents), although the specific document type it wants (IPython notebooks) is likely very complex to render.