Herald! Thank you Evan.
Yes I had forgotten about that. (Wondering how I could have found out though.)
I've disabled the personal rule.
I'm closing this task as invalid and will adjust the task summary to describe what was the PEBKAC here.

AFAICS this is not Spaces specific but also applies to e.g. setting an initial custom task policy when creating a task: Foobar changed the visibility from "Public (No Login Required)" to "Custom Policy".
So far I'm aware of two WM Phab users who contacted me, concerned that the tasks they created were public for a short moment and might have created public notifications.

In T6707#98607, @epriestley wrote:

The way the logic actually works, I think the fix is really in PhabricatorAuthLoginController near line 117:
[...]

Re accessibility/contrast: Alright, so I'd forward users with limited eyesight and their statements to T4213. Thanks! (Side note: You probably meant the Wikimedia community when you wrote "WMF".)

Potential accessibility issue:

• .phui-timeline-title text has color: #6B748C.
• body has background: #F7F7F7.

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

• I assume this would also supersede how disabled user accounts are currently displayed ("handle-disabled" CSS adding a black bullet in front of user name). Not mentioned in the task summary; just pointing out for completeness.
• I assume this would also be the way to go to indicate new Phabricator users (e.g. dateCreated within last 60 days) to be treated even friendlier / with more patience? Mozilla's Bugzilla has such a visual indicator. See their background discussions why this could be useful in communities, but could also discriminate new users.

@pearlcode: I'd say that keywords, tags, <random-other-term> are projects in Phabricator. You can define any kind of projects as "keywords" (e.g. by using a specific icon and a color). Filtering by projects is already possible.

@ostraaten: This looks like a support question, not like a valid bug report or enhancement request to me?
Or do you want to see the aspect more stressed in documentation / dialogs that the admin is supposed to sort out authentication in their first login? If so, feel free to rephrase the task summary.

Ahem, you were right. I'm sorry for the noise. :(

It looks like changing the order of items in getBuiltinQueryNames() in src/applications/search/query/PhabricatorSearchApplicationSearchEngine.php works for those accounts that still have the initial default order of searches and does not reset any custom orders set by existing account owners?

In T4768#59424, @epriestley wrote:

We can probably do conflict detection fairly easily, but conflict resolution is more difficult.

In T7284#96783, @epriestley wrote:

I'm not exactly sure what the factors are that lead to the dash policy and all the related tasks look like they have a minimum of 2,000 comments on them, but if there are specific concerns around fragility/breaking things we may be able to remedy them technically.

Also sorry if my reopening of this task created part of the frustration. My action wasn't intentional; looks like Phabricator does not warn me if another user changes the status in the meantime. :-/

Awesome! Thank you, as usual!

If I get the original poster correctly:

@hcordero: As Maniphest is for tasks and as this seems to be a support request, please refer to support channels for any further followup questions.

Sorry to repeat this question (as it has remained unanswered so far), but a reply would help us a lot when it comes to acceptance among teams and further planning ahead:

I'll just paste the public IRC conversation:

Nov 24 23:44:28 <valhallasw`cloud> twentyafterfour: mm, though it would be in https://github.com/phacility/phabricator/blob/21dca29c5f2929064cfe969cfd4bd417df5621bf/src/applications/project/typeahead/PhabricatorProjectDatasource.php, but apparently not
Nov 24 23:45:58 <valhallasw`cloud> it's parent object https://github.com/phacility/phabricator/blob/21dca29c5f2929064cfe969cfd4bd417df5621bf/src/applications/typeahead/datasource/PhabricatorTypeaheadDatasource.php#L11 has a setLimit, though
Nov 25 01:05:14 <epriestley> twentyafterfour: this is the controlling limit for most typeheads/tokenizers:
Nov 25 01:05:14 <epriestley> https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadSource.js;37d14a85b38f80e9c0c8b54ef208baffc7b910de$79
Nov 25 01:05:28 <epriestley> There's no way to globally bump it up, though. You could set that to 10 and nearly everything will respect it.
Nov 25 01:05:39 <epriestley> (A few override the default to set a different limit.)
Nov 25 01:11:30 <twentyafterfour> epriestley: Thanks! It's one specific instance that I'm mostly interested in but a global bump might be good
Nov 25 01:13:09 <twentyafterfour> wouldn't there be server-side limit? It doesn't look like the javelin code passes the result count to the server in the request...
Nov 25 01:23:23 <epriestley> I thiink it's derived from that display limit.
Nov 25 01:24:17 <epriestley> (There's also a second limit (which valhallasw`cloud linked earlier) but that's the limit on the number of tokens which are allowed in a field like "Subscribers:" -- some like a task "Assignee" permit only a single user, while others like "Subscribers" allow an unlimited number.)

...or what I had just written up, with an added aspect of different levels of information being revealed between web vs mail:

Thanks for elaborating. Makes a lot of sense, as usual.

Ugly, but as I spot

.phabricator-nav-column-background {
  width: 204px; }

for the sidebar, one could set

.phabricator-standard-page-footer {
  padding: 8px 0px 8px 205px; }

maybe?

Another usecase: For tickets imported from previous tracking systems into Phabricator, we drop the IDs from the previous system into a custom field (and use that for URL redirects to Phabricator).
In theory that custom field should not be edited.

@chase.mp told me on Sep 07 "there is no email broadcast, I had to write one" but I don't know any details either.

Status: https://secure.phabricator.com/D9203 needs review; https://secure.phabricator.com/D9202 needs revision.

Sounds very reasonible. Thanks for explaining!

In T5008#14, @epriestley wrote:

It works in practice, but there are a couple of TODOs still around the notifications being too broad.

Unbelievably fast as usual. Thank you so much!

How complicated would it be to fix this? Any guesstimation or pointers?

In T4788#12, @epriestley wrote:

(The infrastructure work on this is further along than I'd thought, although there's a fair bit of technical work remaining.)

Uhm, sorry. I still don't get why moving to certain columns on certain project workboards automatically influences the priority of the task in an often unwanted way. (Anyway that's offtopic here.)

This was also requested in http://fab.wmflabs.org/T414 (as Bugzilla has a not-very-obvious Voting functionality which never convinced me, but obviously it's used by some folks).

<epriestley> qgil: the ALLCAPS one is runtime-generated. We only have English other than that (src/infrastructure/internationalization/translation/PhabricatorEnglishTranslation.php). You can run bin/i18n extract to extract strings from the codebase, but it doesn't dump them out in a common format yet.