Possible that the hashtag/shortname has precedence in autocomplete too?

Would this hashtag let you access projects via some uri that uses the hashtag like /projects/hashtag ?

Howsabout some remarkup usage of these tags?

What other ways could this be used?

I assume it to work like people autocomplete does

Would be glorious if these worked (easier to remember/type):

#shortProj {#shortProj}

vs

#silly_long_team_group_project

Broadly, projects already have a hashtag (the phrictionSlug) but it's auto-generated and often cumbersome. For example, the project "Quality Assurance" will get the autogenerated slug quality_assurance. This is fine for /w/projects/quality_assurance/, but referencing the project by typing #quality_assurance is fairly painful.

Allowing projects to have an alternate name (or maybe set of names) seems like the best solution here, so "Quality Assurance" could have #qa and #qassurance or whatever. Roughly, this means:

• Create a table with <projectPHID, slug, UNIQUE KEY (slug)>.
• Copy the existing slugs into it.
• Add some UI for adding new slugs (a comma-separated text list is probably fine?).
• Handle all the error cases where you try to add a name that another project has.
• Add support to withPhrictionSlugs() or whatever (maybe call this withSlugs() now?)

We still need to have one of them be canonical, for Phriction URIs and writing project hashtags into text (for example, if Herald adds a project as a reviewer and then a user runs "arc amend", we need to render #project). I think the easiest approach by far is to just leave the full slug as the canonical one. If we let you designate an alternate canonical tag after creating the project, we should ideally move all the wiki pages. The UI to select a canonical slug might be a bit involved, too.

One thought here is that the way the Wiki pages are stored might be kind of dumb right now. We denormalize the project slug into them, and store:

projects/quality_assurance/welcome/

This means that when a project is renamed or you want to change the canonical slug, we have to go move all the pages, which we sort of do now but which probably does not work terribly well and could take a long time. Instead, we could store something like:

projects/?{PHID-PROJ-asbdcdf}/welcome/

I think it would be very easy to do the lookup and canonicalize this at runtime, and we'd get project renames and canonicalization adjustments for free. We could also keep the old URIs in service easily (with a "moved" notice, maybe).

To step even further back, I wonder if we should namespace all of Phriction. Right now, there's one big wiki and it has these sort of weird "project" sections which are kind of magical. The advantage of this is that /w/banana/ is a valid place to put the "Banana" page. However, it's kind of funky and starts to create issues with Policies in some cases. An alternative would be to let you create separate wikis and give an entire wiki policies/settings/etc, and then implement the Project magic by using those instead of hardcoding things. @chad, I know you had some thoughts about taking Phriction in a more CMS-ey direction -- anything concrete?

Finally, a related issue is that the Remarkup rule is more strict than the slugifying rule right now. A project slug can include characters like :, but the Remarkup rule never matches these, so these projects are impossible to type.

Another note here (see also D7394) is that phrictionSlug is currently stored with a trailing slash, which is cumbersome for all callers. We should get rid of that and store slugs like "qa", not "qa/", and then remove all the trim() gymnastics we have going on elsewhere.

• I think T4021#10 and T4021#11 are mostly still pretty accurate.
• I think we should just do away with project wiki pages in the long run. The integration is not especially useful and creates a lot of weird problems (e.g., when projects are renamed). We've also seen several reqeusts to put project wiki pages in other/logical groupings (e.g., put engineering projects under engineering). Instead, we would do this to resolve that:
  1. Implement per-page policies (T4029)
  2. Migrate existing project pages to have consistent policies.
  3. Remove all the automatic/magical stuff.
  4. When users want to add wikis to projects, they just create the page and then put a link in the project description.
  5. If you rename a project, you deal with renaming the wiki if you want.
  6. Dashboards can obsolete this further.
  7. So, don't implement any of the "dig us a deeper hole in Wikis" stuff.