Labels need a new approach

[jace]

The current spec and implementation of labels (#313 and #392) defines labels within a project. However, when used for workflow there is a recurring need to treat labels as being cross-project or even site-wide concepts. The current implementation makes comparison of labels across projects hard because each label is actually four distinct bits: the label itself, the optional parent label that it derives part of its identity from, the emoji icon, and the restricted use flag. To be comparable, all four must match.

Labels can be simplified by reducing them to a single variable, the title, and replacing the make_name based URL stubs with the stable output variant (hasgeek/coaster#301).

Label usage should be restricted to project editors, so the “restricted” flag becomes redundant. This is currently a source of confusion.

User-selectable labels should not be labels at all and can be replaced with hashtags (defined in text body) or tags (a new model with new UI; less intuitive than hashtags but allowing for controls such as use limits, controlled vocabulary, and custom presentation based on screen).

Site editors can annotate certain labels (and hashtags/tags) as being of particular interest, assigning them an icon (as on Twitter). This icon will then show up wherever the label is used, across the website. (This assumes labels are not comparable across languages as it is a plain text match, but one workaround is that when a site editor approves a label, they can specify the text per language, thereby grouping all of them.)

Since mutual exclusivity (i.e., a radio group) is still a desirable feature, the : character (or /) can be special-cased. No two labels with the same prefix can be used together, and in UI they’ll appear as a radio list.

When the prefix needs to be change (for example, from “Status: whatever” to “State: whatever”), all labels with that prefix must be edited. Bulk-edit can be offered if we find an intuitive way to place it in the edit flow.