If we were just doing personal notification sounds, I think there'd be a good argument for making this a Settings panel.

And if we were just doing global install sounds, I think there'd be a good argument for making this a Config panel.

However, I'd like to accommodate both personal and global use cases, e.g.:

• an administrator adds sounds for everyone, like the CEO saying "Yee-Haw" or whatever (very motivational!);
• individual users add arbitrary sounds and use them as personal notification sounds or in contexts they control (so you can have Conpherence play the Game of Thrones theme when you get a message or whatever);
• you install a "Reasonable, Professional Sounds for Phabricator 1.0" extension and get a sensible default set of beeps and boops that are generally unobjectionable in a serious business environment.

I think this motivates making "Sounds" a separate application.

Then we maybe have a bit of weirdness around the permissions model. If I upload my 900 favorite Spongebob quotes for personal use they probably shouldn't show up in the typeahead, but if you edit a trigger that uses one of my Spongebob quotes you should be able to see it, and when you drop a task into that column you should be able to hear Spongebob make a squishy sponge sound or whatever.

So probably we put a nullable ownerPHID on each sound and let you view any sound, but the typeahead only browses through (null, viewerPHID) by default.

For builtins we have a builtinKey sort of thing that we can model on various pre-existing cases (Edit form configurations, repository URIs).

I don't think sounds need a view policy (always most-open-policy) or an edit policy (always owner for owned sounds and "administrators" for global sounds). For now, we can reserve "make sound a global sound" for Administrators and maybe specialize that with an application permission eventually if necessary.

We could have "Copy Sound" or something but realistically we aren't building some kind of cutting edge revolutionary toolkit here, just smoothing some edges off the weird hacky non-modular way we're currently doing sound management/reuse.

THEN:

• We can make the "Play Sound" tokenizer accept multiple tokens.
• When the tokenizer has more than one token, we select a sound at random.
• GREAT feature.