= Overview = Pebkac is the customer support application within Phabricator. 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. = Object Overview = - `PebkacContactSource` - User-defined source of contacts - Example 1 (pull) - Twitter posts with #phabricator in them - Example 2 (push) - Emails to 'helpme@example.com' - Daemons periodically do pulls for `PebkacContactSource` objects that need them - `PebkacContact` - An actual contact as defined by a `PebkacContactSource`. - Further communication resides within Phabricator *and* medium defined by `PebkacContentSource`\ - Daemons periodically do pulls for `PebkacContact` objects that need them. - Content is also pulled at view time for `PebkacContact` objects that need updates - `PebkacContactQueue` - Groupings of one or more `PebkacContactSource` - Workers pull contacts from these queues to work = Product Overview = Pebkac has three main views - user home page - shows recent `PebkacContact`s from `PebkacContactQueue`s the user cares about - contact view for user - contact view for customer Within pebkac, users operate on the contact object primarily. When users interact, communication "automagically" happens as close to the source of the complaint as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days. The contact view should - surface all known communication for the contact - surface pertinent information about the customer(s) facing the problem - be designed for both throughput and accuracy The contact view should also be viewable by the customer(s) though with pertinent information and abilities stripped out and new ones added. Customers should also have a list of their other tickets handy on any ticket single view page. If a customer contacts again on the same contact source, if there is any open contact the communication is added there. This serves to aggregate contacts from zealous customers. Contacts benefit from an organization mechanism known as queues. Queues can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group tickets for processing based on the contact source. The user home page should show the various queues and the status they have. = Desired Contact Source Types = - twitter - facebook - quora - stack overflow - email - web form on Phabricator - IRC

= Overview = Pebkac is the codename for the customer support application within Phabricator. 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 - 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 - `ItemQueue` - Mapping object of `Item`s and `Queue`s - `RequestorSource` - Mapping object of `Requestor`s and `Source`s = 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 - 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 Contact Source Types = - twitter - facebook - quora - stack overflow - email - web form on Phabricator - Phabricator applications (Maniphest, Ponder, etc) - IRC

= Overview = Pebkac is the codename for the customer support application within Phabricator. 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, enabling users to track customer issues all over the Internet and respond as closely towe'll pick a better actual product name that doesn't imply the source of the complaint as possibleproblem is with the requestor. = Object Overview = - `PebkacContactSource` - User-defined source of contactsitems - Example 1 (pull) - Twitter posts with #phabricator in them - Example 2 (push) - Emails to 'helpme@example.com' - Daemons periodically do pulls for `PebkacContact`Source` objects that need themem - `Item` - `PebkacContact` - Identified by a `Source`. - An actual contact as defined by a `PebkacContact- Further communication resides within Phabricator *and* medium defined by `Source`. - Further communication resides within Phabricator *and* medium defined by `PebkacContentSource`\- Daemons periodically do pulls for `Item` objects that need them. - Daemons periodically d- Content is also pulls for `PebkacContacted at view time for `Item` objects that need them.updates - `Queue` - Content is also pulled at view time for `PebkacContact- Grouping of `Item` objects that need updates. - `PebkacContact - `Source` objects can specify which queues to put `Item` objects in - 1:1 or based on additional conditionals, Herald-style - 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 - `ItemQueue` - Grou- Mappings object of one or more `PebkacContact`Item`s and `Queue`s - `RequestorSource` - Workers pull contacts from these queues to work- Mapping object of `Requestor`s and `Source`s = Product Overview = Pebkac has three main views - us- worker home pagee - shows `Item` the worker owns that are "open" - shows recent `Item`s from `Queue`s the worker cares about - shows recent `PebkacContact`s from `PebkacContactQueue`s the user cares aboutstats on all `Queue`s worker can see - shows stats on worker's throughput - contact view for user`Requestor` home page - shows `Item`s the `Requestor` created that are "open" - shows `Item`s the `Requestor` created that are "closed" - contact view for customer`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 Within pebkac, usWorkers operate on the contact`Item` object primarily. When usworkers interact, communication "automagically" happens as close to the s`Source of the complainte` as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days. The contact`Item` view should - surface all known communication for the contact`Item` - surface pertinent information about the customer`Requestor`(s) facing the problem - be designed for both throughput and accuracy The contact`Item` view should also be viewable by the customer(s`Requestor`(s) though with pertinent information and abilities stripped out and new ones added. Customers `Requestors` should also have a list of their other ticket`Item`s handy on any ticket single`Item` view page. If a customer`Requestor` contacts again on the same contact svia the same `Source`, if there is any open contact`Item` the communication is added there. This serves to aggregate contacts`Items` from zealous customers. Contacts`Items` benefit from an organization mechanism known as q`Queues`. QueuesThese can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group tickets`Items` for processing based on the contact source`Source` and other criteria. The userworker home page should show the various q`Queues` and the status they have. = New User Experience = - Administrator can configure who can create `Queue`s and `Source`s. - Defaults to Administrator only - 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 Contact Source Types = - twitter - facebook - quora - stack overflow - email - web form on Phabricator - Phabricator applications (Maniphest, Ponder, etc) - IRC