We have several problems which seem well-suited to formalizing the idea of a quorum: for something to happen, it must be approved by M of N users (which may be "exactly one specific user" in some use cases).

• (T7639) Allowing users who have lost their MFA tokens to regain access to accounts by asking peers to verify them. This isn't a perfect fit because we probably (?) don't want to push these requests out? But maybe this is fine and the actual workflow can just have huge piles of warnings on it.
• (T7148) Exporting data from Phacility is an extremely high-risk operation. In the case of larger installs, requiring multiple administrators to approve a request can limit the amount of damage a single compromised account can cause.
• (T8629) A set of use cases where we ask users to make a profile update. These are simple use cases and not security concerns, but well suited to the same kind of UI and storage that I'd expect to put on the other requests.
• (T182) I think there's a low chance that we actually pursue this, but there may be some use case for multiple approvers on merges.
• This might make sense for some application configuration stuff. Broadly, we could consider this as an alternative to locking configuration in at least some cases, because the primary driver for most config locks is preventing compromise of the install by a single rogue administrator. Mandating a quorum could defuse this threat. (Some configuration is locked because it can break an install, so it's very unlikely that we want to unlock this.) Even in non-security cases, installs might reasonably want a lightweight review workflow on config changes (i.e., get a second admin to confirm any changes).
• This seems like a relatively flexible workflow, so I suspect there are more emergent use cases. For example, we could implement "Suggest Badge Award" which let anyone suggest that someone receive a badge award, to be approved by one of the owners of that badge. "Request to join group" and "Request to join room" also seem plausible, or even "Request to activate Global Herald rule", "request to invite user", etc. I don't imagine attaching quorum requests to every single operation in every application, but I think we'll probably find reasonable motivating use cases for at least a few of these.

I think it probably makes sense to implement this as part of Notifications, and treat these like "super notifications". T8629 has some UI discussion in the simple case. I'd imagine these sticking to the top of the notification menu.

See PHI1443. Here, an install has a regulatory/compliance process requirement that certain objects receive signoff somewhere in their lifecycle.

Although I'm hesitant to implement full "Review" workflows into every application and object type, we could reasonably imagine that this could fit into the "Quorum" pattern (propose a change -> votes -> apply the change). Here, it would look something like the object author suggesting a state change to "Approved", then doing a Quorum workflow on it with M = N so everyone has to sign off; once they do, the state changes.

See T13420. This is kind of the opposite of T8629. In some cases, users would like to make edits to their account (like changing their username) that they don't have permission to make. Today, you have to go hunt down someone who can handle this request and ask them. A cleaner workflow would be to let the user suggest a change to their own profile, then have an administrator simply approve it.