Page MenuHomePhabricator

Default Phabricator search criteria confuses new users mixing commits and tasks
Closed, DuplicatePublic

Description

Spin-off from T7266#96398

Many users are confused by the default Phabricator search, which provides tasks and commits mixed in the results. This confusion is aggravated by the fact that it takes a while for an average user to discover that they can change the default behavior of the default search. Once they figure out, they usually set the default to 'Open tasks' and forget about the problem. Still, new users register and get confused about the search results.

Possible solutions to this problem:

  • Tweak the search engine to prioritize tasks over commits.
  • Allow administrators to define the default search query for their users (i.e. Open Tasks).
  • Default to Open Tasks.
  • ... ?

Event Timeline

qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added a project: Search.
qgil added a subscriber: qgil.

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?

We aren't going to change the default in the upstream or prioritize document types within it -- it's not some weird mishmash like "commits and tasks", it's "all documents". I think this is the only reasonable default. Some installs do not use Maniphest at all, for example.

T4103 discusses allowing administrators to change default queries, home page applications, settings, dashboards, etc., for groups of users.

I think the patch @aklapper mentions should have the desired effect until then.

Even more confusing than mixed tasks and commits, I find mixed tasks and codereviews, since they will have the same title, and just use a different callsign. The texts "Commit" and "Revision" below the callsign do not help much, since many people use the terms interchangeably.

I'm going to merge this into T4103, although D12509 partially obsoletes it. Hopefully, the explicit control surfaced in D12509 resolves the confusion here on its own.