-
Notifications
You must be signed in to change notification settings - Fork 0
Requirements
imbradmiller edited this page Jan 22, 2013
·
15 revisions
- Create one column for personal and organization repos
- Each repo will be display with a checkbox for enabling that repo on IssuePress
3. Customer support on front-end of WordPress site without requiring issues being created on Github since not all issues are development-related
- Customer User Clicks Create Issue Button
- Customer User enters text into title field
- Customer User enters description into description field
- Customer User clicks add issue
- System adds issue to GitHub and associates the ticket to the GitHub Issue Number, appends user info in description, since it's posted through the daemon.
5. Provide Github developers the ability to communicate with customers directly from Github => WordPress and WP customers => devs. The communication will be tracked via comments on the issue inside of GitHub.
- User or Developer can enter content into the comment field and click comment.
- System records the comment on the presentational side of IssuePress, then sends that comment to the issue number within GitHub.
- simple controls on front-end that really are only conversational, not necessarily functional/admin purposes. Devs/support guys will be more efficient using the github interface, we shouldn't spend time reinventing the wheel.
6. Pick up "closed" issues and bring the closure message to WordPress and notify the customer that an issue has been closed/resolved.
- Developer closes the issue within GitHub
- System captures issues that have been marked as "closed" and provides a system comment stating the ticket/issue has been closed/resolved
- Question: What happens when a ticket is reopened by the developer, because they noticed an issue after the fact? Is there a time gap or does the service collect issues that are reopened on GitHub.
8. Allow an administrator to use OAuth to authenticate one support user that will interact with github on behalf of the customer, since they will not have access to private repos
9. Live Search when querying issues, this was discussed but might not be possible because of api request limitations.
- Repo Listing View - Design Not finalized
- Repo Single View - Needs Design
- Issue Single View - Design completed, may need some customization/changes
There is the idea of allowing the user to influence the layout of these views by using a module based design. Each view will have one widgetized sidebar that IssuePress functionality modules can be added to. We still need to decide if the core functionality on each view will be decided by us (i.e. search field based design on repo listing/single that's scope is defined by it's context / Issue single view that shows the comment thread of the issue's history), and the widgets are supplemental info/data based on repo context OR if the views themselves are all widget generated. My recommendation is on the first, set design with widgets being supplemental.
- what functionality are they?
- How many are there?
- Where are these sidebars actually going in the design?
- They should be able to be placed on any of the three views and still work properly, intuitively.
- If a repo is from a personal account, checking the checkbox will add/remove the admin as a collaborator
- If a repo is from an organization, IssuePress will attempt to add them as a team member for that repo. If they are not the owner, a second admin drop-down will appear for selecting the organization owner account. * If the owner admin is not authenticated, a button will appear to authenticate