I like it! Thanks for listening, looking forward to this (and top level namespaces so we can stop overloading the Projects field). :)

Our general flow:

• We have multiple teams and multiple projects in the same installation.
• Each team is responsible for triaging and managing the bugs for their projects.
• We file bugs with a priority of "Needs Triage".
• We try to encourage good bug writing (including enough content to provide context about where you're seeing the issue), but you still sometimes get a trace and a one-liner of "we hit an exception". Sucks, but it happens.
• We use projects both as categories and as tags:
  • Each team has a particular general project they use as a "bucket" to catch bugs related to their team.
  • Triage assigns priority, assign to someone to work on it, and tag with additional project tags as appropriate.
  • By having these "catchall" projects for each team, we're able to easily narrow searches to just bugs relevant to a particular product.

The smartest, awesomest people in the world still sometimes make mistakes, and not having a way to catch these mistakes is a problem. When you're running many projects across dozens of teams and hundreds of people from within the same installation, mistakes can easily end up piling up. Having an optional config setting for flagging specific fields we want to make sure get filled out is no more proscriptive than a code linter (which you support).