Summary

A use case for Nuance is as a bulk editor for objects in other applications (like Maniphest Tasks) where you want to make changes to a list of items but the particular change requires human decision making. For example:

• You have a large number of untriaged tasks which you want to triage.
• You have a large number of similar audits you want to work through.

Nuance can make these use cases easier by putting the objects into a queue, letting you keep track of addressed and unaddressed objects, see how much progress you've made, and (in some cases) make and apply decisions more quickly.

Example Workflow

A workflow might look like this:

• You have 85 "Needs Triage" tasks tagged with #smelting and want to triage them.
• You run a query in Maniphest for "Tasks in 'Needs Triage' tagged with #smelting".
• You select Use Results... → New Nuance Queue to create a new queue from these items in Nuance.
• In Nuance, you can work through these items one-by-one. Nuance keeps track of how far you've made it and which items are addressed or unaddressed.
• To some degree, Nuance may also provide tools to make some operations more efficient. For example, a single keystroke for common actions against an object type (like "Close as invalid + move to next item in queue"). Or a way to save common actions and re-apply them. Or a way to quickly repeat the last few actions you took. Not all actions will necessarily be "compressible" like this: if you're writing a unique custom response for each ticket, we obviously can't build a "Write Unique, Appropriate Response + Move to Next Item in Queue" action.
• When Nuance is used like this, it may also integrate into the UI more broadly. For example, we might imagine an element which works like this:
  • You can click a button to "activate" the queue and jump to the first object's detail page.
  • While you have an active queue and are on the page of an item in the queue, a new persistent element appears in the UI (maybe in the header, or in an element next to persistent chat).
  • This element gives you access to queue status/position and actions like "next item".
  • This element also installs keyboard shortcuts like "jump to next", "jump to previous", etc.
  • This might be a better way to work through complex objects, like reviews and audits, where we are less able to pull and present the pertinent details in Nuance itself or provide relevant actions in a generic way.

Use Cases

From tasks connected to T5815, some actual use cases are:

• (T8443) As a bulk bug triager. I see this as the primary use case where Nuance can be the most valuable (but: would it be better to just send all new reports to Nuance in the first place, as a help desk, and then only let triaged things through into Maniphest)?
• (T8030) As a bulk user-approver. I think this is reasonable, but the original request didn't actually mention any decisions being made. It's possible that this was not really a "bulk decision" issue, and that Bulk Edit Users or just Approve All would resolve it.
• (T5815, T8571, T8493, ...) As a bulk auditor. These requests generally seem to suggest that the users don't actually want to perform audit (or want to perform only 1-2 seconds of audit) and just want to bulk-delete audits, so I'm not sure if this is actually a tool that solves these problems. Bringing the bulk editor to all applications (T10005) might be a better fix, so you could just Use Results... → Bulk Edit Selected Audits → Accept without even having to look at them. Obviously, this defeats the purpose of audit, but maybe we should be comfortable with giving users enough rope to shoot themselves if that's what they want.
• (T10215) As a moderation queue. If we eventually build formal abuse tools, I believe they will largely take the form of an "Under Moderation" status on every object (e.g., task, comment) where objects are held in limbo until approved by a human moderator or moderation bot. Nuance could work be used to work through moderation queues.

Upstream Temperament

This is a complex change and many of the driving use cases seem very weak: in many cases, they save a tiny amount of annoyance. Often, it also feels like we are not tackling a root problem. Finally, it sometimes feels like these use cases don't actually require a decision.

Very Little Time Savings: A lot of the issues were filed before the era of modern feature request guidelines and don't really describe the problems users are encountering, but at least some of the discussion explicitly frames the time savings as a few seconds per day. I think that perhaps only T8443 describes a task where improved automation tools may lead to a substantial time savings.

Few Root Problems: I suspect a lot of this discussion has really been too focused on a specific solution, too, when the real problem is that audit (or the approval queue, or whatever else, but I'll discuss audits here) is not configured well and is generating large numbers of extraneous audits.

If you are sincerely reviewing 100 commits which each represent a meaningful change, the 2-3 extra seconds it takes to "Accept" each of them should be insignificant compared to the amount of time it takes to read the commit message, consider the change, and then make a decision.

Perhaps if 95 of those commits are named "fix a typo", have a one-line change, and the only decision you're making is to confirm that the change really just fixes a typo, this might represent a significant fraction of the cost per commit. But I think this is a structural problem, and that there is little reason to publish and audit large numbers of "fix a typo" commits. If you face this situation and step back and ask whether "fix a typo" commits are a net positive or net negative, I suspect they will be judged harshly.

No Decisions: In other cases, it seems like no decision is being made, or a decision is being made based only on the object name/title or metadata (like which branch an audit appears on). In these cases, while we could make it easier to "Accept", we don't need to require you to go to the detail page at all. Operations like Approve All, Delete Every Audit I Have To Do, I Don't Want To Do Them or Use Results... → Bulk Edit are likely better fits.

Related Work

• I plan to complete T12738: Nuance: As a Helpdesk, for Phabricator/Phacility support before this, enabling Nuance to be used as a help desk for things like support requests.
• I plan to complete T10005: Implement an ApplicationEditor-based Bulk Editor before this, expanding the Maniphest bulk editor so it is available in all applications.

Feedback

We can use feedback about use cases here if you have a use case which satisfies ALL of these requirements:

• The value is high: users would regularly save a large amount of time, like a bug triager whose job is primarily to wrangle inbound bug queues. If users would save a few clicks per day and be a little less annoyed you may benefit from tooling here, but we don't want to shape the tool's design around these less-valuable use cases.
• The work requires real human decisions based on object content: if you are not making decisions on each object, or are making snap decisions based only on object metadata, T10005 ("apply the exact same edit to all these objects") is likely a much better fit for your use case.
• The decisions are meaningful and valuable, and require human expertise to make: for example, paying engineers to decide whether a particular change labeled "typo fix" is really a typo fix or not may be a process problem, not a tooling problem. You may benefit from tooling if your process is hard to change, but we don't want to design the tool around process problems.