**aklapper** wrote on `2014-07-28 19:35:14 (UTC)`

Would love to get feedback from more parties on this:

There have been discussions on project naming schemes with good and valid arguments by all involved parties in T457 but those discussions seems to fit better here to keep T457 focused on //documenting//.

The three main aspects I see mentioned which are intermingled:
* allowing spaces in project names,
* expressing hierarchy in project names,
* "discoverability" of existing projects when using type-ahead to make Phabricator list project proposals for matching strings in the "Projects" field.

For the fourth and minor aspect of //enforcing lower case names// for projects: Currently, not using a lower case project name would break URL redirecting from e.g. http://fab.wmflabs.org/tag/trusted_user_tool/ to http://fab.wmflabs.org/project/view/40/ . Treating lower and upper case the same way //should be fixed upstream// in https://secure.phabricator.com/T5728 and IMHO we as downstream should not really bother about this.

In order to understand "discoverability", here is the current behavior of type-ahead in Phabricator's "Projects" field: Type-ahead is not restricted to the very beginning of a project name but to words (tokens). We have a project named "Wikimedia Phabricator Maintenance (after Day 1)" in fab.wmflabs.org. If you go to http://fab.wmflabs.org/maniphest/task/create/ and enter "after" or "Day" in the "Projects" field, it will be proposed. It does not match random substrings though - entering "fter" does not propose "after".

=== Hierarchy or Categories ===

It seems we all agree that we do need some level of organization and rules in that flat Projects namespace, otherwise things will get messy, ambigious, colliding in the long run.

Question is whether we want to express //hierarchy// like "MediaWiki extension: VisualEditor: Data Model" or "MediawikiExtension-VisualEditor-DataModel" or instead //categorization// like "VisualEditor: Data Model (extension)".

The latter feels more readable for the human eye but not sure if that's reason enough.

=== Spaces in Project Names ===

If we did //not// allow spaces in project names, like in "mediawikiextensions-visualeditor-datamodel", entering "datamodel" in the "Projects" field would currently not propose the given project via type-ahead. I consider this problematic as reporters should be able to try entering and finding the correct project, and the first thing they'd try is the actual name, if aware of. On a related note, Chase proposed treating hyphens/dashes the same way as spaces for type-ahead proposals in upstream https://secure.phabricator.com/T5727 (and Evan was in favor on IRC).

If we did allow using spaces in project names, referencing a "#project name" in text via the # suffix will not work for these projects, as Chase brought up in http://fab.wmflabs.org/T457#17 , plus entering a URL replacing spaces by %20 HTML entities (instead of underscores) like in http://fab.wmflabs.org/tag/Trusted%20User%20Tool/ will not work.