This is a problem with all tokenizers, people have to guess and might not know all the options. In most cases, people generally know what they are looking for.

The See All as the last option is about as decent a choice as any. Do we already have a page that lists all the projects? How are projects managed from the larger scope (admin?)?

https://secure.phabricator.com/project/ is the Project tool.

There's currently the notion of "active" versus "archived" where active means it still shows up in typeaheads, etc. The project itself has permissions now re: who can or can not edit it. I think instance admins can always edit. (Woot!)

In practice, we see projects made by Evan or I for real things. Other people come in and make fake projects to test. Every few weeks I go and "archive" a bunch of the trash.

T390 ends up being interesting here. I don't think the total number of projects will go up, but I do think they'll get more use as a result of this.

Given most people generally know what they are looking for, do you think its best to just not fix this or make a change here? I think we can do better "NUX" in general and maybe understanding the active projects on this instance should be part of that?

Admins don't have any special powers as far as Policies go. I want to make the UI call out exceptions at some point, but they're basically all application-specific and just prevent us from getting into impossible/goofy/nonsense situations. For example, members of a project can always view it even if the view policy is set to "No One".

I imagine the UI eventually calling this out explicitly, e.g.:

 Visible To: No One
             (Project members can always view a project.)
Joinable By: No One
             (Users who can edit a project can always join it.)
Editable By: Administrators

I imagine we'll eventually add a flag that allows administrators to bypass policies if an install wants or something, but I want to wait for (a lot of) pushback before we do that and dialog/log them when they do; I generally like keeping administrators accountable and making their role strictly administrative.

So it's currently quite plausible that users are creating projects (and a few other types of objects) that we do not have permission to see or edit.

On this issue in particular:

My gut is that this is probably nice to have but arises fairly rarely in the wild. I know a couple of installs are using Projects/Maniphest and asked for "Add New Project" after like 5 seconds of use but haven't wanted "find project". In common cases I think the people associating projects are the ones managing the project set so they're familiar with it. We could pop an object selector dialog or something, although that's also search-oriented rather than browse-oriented. Maybe search is a better solution to this problem than browsing though? If we rebuild subprojects for T390 that might entail a hierarchical view which I suppose we could dialog in elsewhere.

A possibly-related use case is people-browsing, which is also currently more or less impossible. We could conceivably build a people browser that organizes them by project or along other dimensions (Owners projects?). I'm not sure that this would really be useful, though.

Dropbox touched on this tangentially with this request:

The ability to have easily-discoverable “subprojects” or “categories” with separate lists of projects/categories for each project, accessible in both the bug filing UI and the query UI. For example, right now our iOS team wants to identify bugs by product category, so they can say that “this bug is related to viewing PDFs” or “this bug is related to authentication” or whatever and they want to be able to query by those fields so we can see how many bugs are left in each part of the release. The project is iOS, but there’s no easy way to say “this is an iOS PDF bug”. What we do now is to create a “ios-PDF” project for the bug and use it like a tag, along with an ios project, but the problem is that since projects are only discoverable via autocomplete, bug filers can’t know that there *is* a PDF project to begin with -- there is some prefilling, but you still have to guess the tag name right, and the iOS team has about 40 product categories, whereas the prefill will only show about four or five results when you type in ios-. (We also have the problem that each team is creating their own project tags and because there’s no hierarchy, you can get two projects that would appear to mean the same thing, but are owned by different teams.) At the same time, we want different subprojects/categories for each project, so that the Client team doesn’t have to deal with sorting through the iOS team’s 40 tags when they file or query client bugs. We also want to able to add an arbitrary number of projects and subprojects to a task.

In theory if they had a list of projects this would be mitigated somewhat. Otherwise though this is tangential.

For what is worth, I also thought in my first 5 minutes of Phabricator that I would need a list of projects at sight when creating a new task. Then, a few days later I created my first task here without having any idea of your taxonomy and... type-ahead was just enough. I still don't know about your list of projects, and I couldn't care less as long as I find at least an obvious choice typing ahead.

My slightly longer report: http://fab.wmflabs.org/T52#14 , where I'm basically saying that Wontfix would work for me.

I do think we should provide a browse interface here eventually, but it probably isn't worth designing or building until we have more concrete plan around subprojects (T3670), since I think that is likely to affect the UI a lot. We also don't really have a similar interface already built that we could repurpose easily, beyond just throwing up a list of projects in a dialog or something (which probably wouldn't be too useful, and we haven't seen too many requests for this).

Although I think the typeahead isn't too bad, I suspect this install has unusually consistent organization and an unusually low total amount of project management happening, mostly because we're a small project without too many regular contributors, and it might be a bit harder to get oriented on a larger install.