= Overview = NUance (previously Pebkac) is the codename for the human work item application (e.g. customer support tickets, machine failure remediation) within Phabricator, with the initial feature set focused around customer support. Its name is an acronym which stands for "problem exists between keyboard and chair." Despite this goofy name, pebkac takes customer support very seriously, enabling users to track customer issues all over the Internet and respond as closely to the source of the complaint as possible. And of course, we'll pick a better actual product name that doesn't imply the problem is with the requestor. = Object Overview = - `Source` - User-defined "source" of items - Example 1 (pull) - Twitter posts with #phabricator in them - Example 2 (push) - Emails to 'helpme@example.com' - Daemons periodically do pulls for `Source` objects that need them - `Item` - Identified by a `Source`. - Further communication resides within Phabricator *and* medium defined by `Source` - Daemons periodically do pulls for `Item` objects that need them. - Content is also pulled at view time for `Item` objects that need updates - `Queue` - Grouping of `Item` objects. - `Source` objects can specify which queues to put `Item` objects in - 1:1 or based on additional conditionals, Herald-style - Each `Queue` specifies the `Action`s that are appropriate to take against any `Item` in the `Queue` - Workers pull items from these queues to work - `Requestor` - Actor - typically a person - that was picked up by a `Source` to make an `Item` - `Requestor` may not exist - `ItemSource` - Mapping object of `Item`s and `Source`s - `ItemQueue` - Mapping object of `Item`s and `Queue`s - `RequestorSource` - Mapping object of `Requestor`s and `Source`s - `Action` - A given `Source` has a set of `Action`s that can be taken against any `Item` from that source. - A given `Queue` has a set of `Action`s that can be taken against any `Item` in the queue. - A given `Action` has permissions associated with it; not all workers will be able to take all `Actions`. - These are all "hard coded" - for example, the code to reply with a tweet - with configuration such as what Twitter account to use to reply to a tweet. - An `Action` is always displayed, and if it cannot be taken explains why. For example, "`Requestor` twitter handle is unknown." = Product Overview = Pebkac has - worker home page - shows `Item` the worker owns that are "open" - shows recent `Item`s from `Queue`s the worker cares about - shows stats on all `Queue`s worker can see - shows stats on worker's throughput - `Requestor` home page - shows `Item`s the `Requestor` created that are "open" - shows `Item`s the `Requestor` created that are "closed" - `Item` view for worker - 3 columns - left column for transactions and writing - most recent transactions first - composer text area appears above most recent transaction - mid column for actions - right column for requestor data / other data. - `Item` view for `Requestor` - 3 columns - left column as for worker - mid column has less actions - right column - statistics about turn around time, etc for `Queue`s this `Item` is in - list of any other `Item`s for the `Requestor` - `Queue` view - shows recent `Item`s that are open - shows list of automation rules that run on this `Queue` - `Queue` create / edit / delete - metadata - automation rules - `Source` view - shows recent `Item`s that are open - shows list of creation rules that run as part of this `Source` - shows list of queue routing rules that run on `Items` made via this `Source` - `Source` create / edit / delete - metadata - silly data and creation rules - UI will differ based on `Source` type (e.g. twitter vs email) - queue routing rules - default to 1:1 Workers operate on the `Item` object primarily. When workers interact, communication "automagically" happens as close to the `Source` as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days. The `Item` view should - surface all known communication for the `Item` - surface pertinent information about the `Requestor`(s) facing the problem - be designed for both throughput and accuracy The `Item` view should also be viewable by the `Requestor`(s) though with pertinent information and abilities stripped out and new ones added. `Requestors` should also have a list of their other `Item`s handy on any `Item` view page. If a `Requestor` contacts again on the same via the same `Source`, if there is any open `Item` the communication is added there. This serves to aggregate `Items` from zealous customers. `Items` benefit from an organization mechanism known as `Queues`. These can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group `Items` for processing based on the `Source` and other criteria. The worker home page should show the various `Queues` and the status they have. = New User Experience = - Administrator can configure who can create `Queue`s and `Source`s. - Defaults to Administrator only on basic install - If no `Queue`s or `Source`s and no permission to create them, standard permission error. - If no `Queue`s or `Source`s and permission to create them... - Explanatory "workflow" - Page 1 - explain product in brief - Page 2 - create `Queue` IFF none exists - Page 3 - create `Source` IFF none exists - Suggest email by default - Page 4 - instructions on how to generate an `Item` using `Source` - If `Queue`s and `Source`s, standard home page. = Desired Source Types = - twitter - facebook - quora - stack overflow - email - web form on Phabricator - Phabricator applications (Maniphest, Ponder, etc) - IRC = Desired Actions = - Phabricator support - password reset - username change - name change - foreach `Source` type, ability to reply directly to `Source` = Corner Cases = - N `Source`s could create N `Item`s for the same actual communication (example - user tweets "I hate #phabricator btrahan!" and there are two sources for twitter - one for #phabricator and one for btrahan) - Only one `Item` is created... - ...but it is in multiple queues... - ...and has multiple sources...

= Overview = Nuance (previously Pebkac) is the codename for the human work item application (e.g. customer support tickets, machine failure remediation) within Phabricator, with the initial feature set focused around customer support. Its name is an acronym which stands for "problem exists between keyboard and chair." Despite this goofy name, pebkac takes customer support very seriously, enabling users to track customer issues all over the Internet and respond as closely to the source of the complaint as possible. And of course, we'll pick a better actual product name that doesn't imply the problem is with the requestor. = Object Overview = - `Source` - User-defined "source" of items - Example 1 (pull) - Twitter posts with #phabricator in them - Example 2 (push) - Emails to 'helpme@example.com' - Daemons periodically do pulls for `Source` objects that need them - `Item` - Identified by a `Source`. - Further communication resides within Phabricator *and* medium defined by `Source` - Daemons periodically do pulls for `Item` objects that need them. - Content is also pulled at view time for `Item` objects that need updates - `Queue` - Grouping of `Item` objects. - `Source` objects can specify which queues to put `Item` objects in - 1:1 or based on additional conditionals, Herald-style - Each `Queue` specifies the `Action`s that are appropriate to take against any `Item` in the `Queue` - Workers pull items from these queues to work - `Requestor` - Actor - typically a person - that was picked up by a `Source` to make an `Item` - `Requestor` may not exist - `ItemSource` - Mapping object of `Item`s and `Source`s - `ItemQueue` - Mapping object of `Item`s and `Queue`s - `RequestorSource` - Mapping object of `Requestor`s and `Source`s - `Action` - A given `Source` has a set of `Action`s that can be taken against any `Item` from that source. - A given `Queue` has a set of `Action`s that can be taken against any `Item` in the queue. - A given `Action` has permissions associated with it; not all workers will be able to take all `Actions`. - These are all "hard coded" - for example, the code to reply with a tweet - with configuration such as what Twitter account to use to reply to a tweet. - An `Action` is always displayed, and if it cannot be taken explains why. For example, "`Requestor` twitter handle is unknown." = Product Overview = Pebkac has - worker home page - shows `Item` the worker owns that are "open" - shows recent `Item`s from `Queue`s the worker cares about - shows stats on all `Queue`s worker can see - shows stats on worker's throughput - `Requestor` home page - shows `Item`s the `Requestor` created that are "open" - shows `Item`s the `Requestor` created that are "closed" - `Item` view for worker - 3 columns - left column for transactions and writing - most recent transactions first - composer text area appears above most recent transaction - mid column for actions - right column for requestor data / other data. - `Item` view for `Requestor` - 3 columns - left column as for worker - mid column has less actions - right column - statistics about turn around time, etc for `Queue`s this `Item` is in - list of any other `Item`s for the `Requestor` - `Queue` view - shows recent `Item`s that are open - shows list of automation rules that run on this `Queue` - `Queue` create / edit / delete - metadata - automation rules - `Source` view - shows recent `Item`s that are open - shows list of creation rules that run as part of this `Source` - shows list of queue routing rules that run on `Items` made via this `Source` - `Source` create / edit / delete - metadata - silly data and creation rules - UI will differ based on `Source` type (e.g. twitter vs email) - queue routing rules - default to 1:1 Workers operate on the `Item` object primarily. When workers interact, communication "automagically" happens as close to the `Source` as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days. The `Item` view should - surface all known communication for the `Item` - surface pertinent information about the `Requestor`(s) facing the problem - be designed for both throughput and accuracy The `Item` view should also be viewable by the `Requestor`(s) though with pertinent information and abilities stripped out and new ones added. `Requestors` should also have a list of their other `Item`s handy on any `Item` view page. If a `Requestor` contacts again on the same via the same `Source`, if there is any open `Item` the communication is added there. This serves to aggregate `Items` from zealous customers. `Items` benefit from an organization mechanism known as `Queues`. These can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group `Items` for processing based on the `Source` and other criteria. The worker home page should show the various `Queues` and the status they have. = New User Experience = - Administrator can configure who can create `Queue`s and `Source`s. - Defaults to Administrator only on basic install - If no `Queue`s or `Source`s and no permission to create them, standard permission error. - If no `Queue`s or `Source`s and permission to create them... - Explanatory "workflow" - Page 1 - explain product in brief - Page 2 - create `Queue` IFF none exists - Page 3 - create `Source` IFF none exists - Suggest email by default - Page 4 - instructions on how to generate an `Item` using `Source` - If `Queue`s and `Source`s, standard home page. = Desired Source Types = - twitter - facebook - quora - stack overflow - email - web form on Phabricator - Phabricator applications (Maniphest, Ponder, etc) - IRC = Desired Actions = - Phabricator support - password reset - username change - name change - foreach `Source` type, ability to reply directly to `Source` = Corner Cases = - N `Source`s could create N `Item`s for the same actual communication (example - user tweets "I hate #phabricator btrahan!" and there are two sources for twitter - one for #phabricator and one for btrahan) - Only one `Item` is created... - ...but it is in multiple queues... - ...and has multiple sources...

= Overview = NUNuance (previously Pebkac) is the codename for the human work item application (e.g. customer support tickets, machine failure remediation) within Phabricator, with the initial feature set focused around customer support. Its name is an acronym which stands for "problem exists between keyboard and chair." Despite this goofy name, pebkac takes customer support very seriously, enabling users to track customer issues all over the Internet and respond as closely to the source of the complaint as possible. And of course, we'll pick a better actual product name that doesn't imply the problem is with the requestor. = Object Overview = - `Source` - User-defined "source" of items - Example 1 (pull) - Twitter posts with #phabricator in them - Example 2 (push) - Emails to 'helpme@example.com' - Daemons periodically do pulls for `Source` objects that need them - `Item` - Identified by a `Source`. - Further communication resides within Phabricator *and* medium defined by `Source` - Daemons periodically do pulls for `Item` objects that need them. - Content is also pulled at view time for `Item` objects that need updates - `Queue` - Grouping of `Item` objects. - `Source` objects can specify which queues to put `Item` objects in - 1:1 or based on additional conditionals, Herald-style - Each `Queue` specifies the `Action`s that are appropriate to take against any `Item` in the `Queue` - Workers pull items from these queues to work - `Requestor` - Actor - typically a person - that was picked up by a `Source` to make an `Item` - `Requestor` may not exist - `ItemSource` - Mapping object of `Item`s and `Source`s - `ItemQueue` - Mapping object of `Item`s and `Queue`s - `RequestorSource` - Mapping object of `Requestor`s and `Source`s - `Action` - A given `Source` has a set of `Action`s that can be taken against any `Item` from that source. - A given `Queue` has a set of `Action`s that can be taken against any `Item` in the queue. - A given `Action` has permissions associated with it; not all workers will be able to take all `Actions`. - These are all "hard coded" - for example, the code to reply with a tweet - with configuration such as what Twitter account to use to reply to a tweet. - An `Action` is always displayed, and if it cannot be taken explains why. For example, "`Requestor` twitter handle is unknown." = Product Overview = Pebkac has - worker home page - shows `Item` the worker owns that are "open" - shows recent `Item`s from `Queue`s the worker cares about - shows stats on all `Queue`s worker can see - shows stats on worker's throughput - `Requestor` home page - shows `Item`s the `Requestor` created that are "open" - shows `Item`s the `Requestor` created that are "closed" - `Item` view for worker - 3 columns - left column for transactions and writing - most recent transactions first - composer text area appears above most recent transaction - mid column for actions - right column for requestor data / other data. - `Item` view for `Requestor` - 3 columns - left column as for worker - mid column has less actions - right column - statistics about turn around time, etc for `Queue`s this `Item` is in - list of any other `Item`s for the `Requestor` - `Queue` view - shows recent `Item`s that are open - shows list of automation rules that run on this `Queue` - `Queue` create / edit / delete - metadata - automation rules - `Source` view - shows recent `Item`s that are open - shows list of creation rules that run as part of this `Source` - shows list of queue routing rules that run on `Items` made via this `Source` - `Source` create / edit / delete - metadata - silly data and creation rules - UI will differ based on `Source` type (e.g. twitter vs email) - queue routing rules - default to 1:1 Workers operate on the `Item` object primarily. When workers interact, communication "automagically" happens as close to the `Source` as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days. The `Item` view should - surface all known communication for the `Item` - surface pertinent information about the `Requestor`(s) facing the problem - be designed for both throughput and accuracy The `Item` view should also be viewable by the `Requestor`(s) though with pertinent information and abilities stripped out and new ones added. `Requestors` should also have a list of their other `Item`s handy on any `Item` view page. If a `Requestor` contacts again on the same via the same `Source`, if there is any open `Item` the communication is added there. This serves to aggregate `Items` from zealous customers. `Items` benefit from an organization mechanism known as `Queues`. These can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group `Items` for processing based on the `Source` and other criteria. The worker home page should show the various `Queues` and the status they have. = New User Experience = - Administrator can configure who can create `Queue`s and `Source`s. - Defaults to Administrator only on basic install - If no `Queue`s or `Source`s and no permission to create them, standard permission error. - If no `Queue`s or `Source`s and permission to create them... - Explanatory "workflow" - Page 1 - explain product in brief - Page 2 - create `Queue` IFF none exists - Page 3 - create `Source` IFF none exists - Suggest email by default - Page 4 - instructions on how to generate an `Item` using `Source` - If `Queue`s and `Source`s, standard home page. = Desired Source Types = - twitter - facebook - quora - stack overflow - email - web form on Phabricator - Phabricator applications (Maniphest, Ponder, etc) - IRC = Desired Actions = - Phabricator support - password reset - username change - name change - foreach `Source` type, ability to reply directly to `Source` = Corner Cases = - N `Source`s could create N `Item`s for the same actual communication (example - user tweets "I hate #phabricator btrahan!" and there are two sources for twitter - one for #phabricator and one for btrahan) - Only one `Item` is created... - ...but it is in multiple queues... - ...and has multiple sources...