Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Establish support case tracking process #5

Closed
8 of 28 tasks
cbeams opened this issue Feb 7, 2020 · 1 comment
Closed
8 of 28 tasks

Establish support case tracking process #5

cbeams opened this issue Feb 7, 2020 · 1 comment
Assignees
Labels
has:approval bisq.wiki/Project_management#Approval to:Improve Support was:aborted bisq.wiki/Project_management#Closing_as_aborted

Comments

@cbeams
Copy link
Member

cbeams commented Feb 7, 2020

/cc @bisq-network/support-agents (so everyone is aware of this work in progress)

Delivery criteria

  • Wiki documentation of the case tracking process is complete
  • All support agents understand how to track their cases and are actually doing so
  • Script(s) exist that process closed support case issues and produce the simple metrics discussed in the Q1 2020 Update call (Establish support case tracking process #5), including:
    • Support cases per cycle
    • Support cases per trade
    • Mean time to response
    • Mean time to resolution
    • Support cases per known issue / critical bug (this one is probably not scriptable per se, but a process can be put in place to make getting the information feasible)

Tasks

  • Decide to use bisq-network/support repo issues for tracking
  • Announce this decision in the support team kickoff call (Improve Reliability #19)
  • Create support repo Case Tracking project board
  • Automate adding newly created issues to the Case Tracking Board (Establish support knowledge base #6)
  • Give @bisq-network/support-agents Triage access to the support repo
  • Experiment with issue title formats and encrypting sensitive data contents with Keybase (Establish compensation request review process #7)
  • Define metadata fields for programmatic parsing of closed support cases (Refine support case issue template support#336)
  • Create new support case issue label in the support repository
  • Create support case issue template containing the metadata fields mentioned above, and YAML front matter that labels issues as 'support case' (Refine support case issue template support#336)
  • Figure out a dead-simple way that all support agents can quickly convert their local time in keybase to UTC/zulu time to copy and paste into the date metadata fields of each new issue
  • Create a short screencast showing how to follow the case tracking process (@cbeams)
  • Finish documenting the process for tracking support cases on the Support Agent wiki page
    • Include a link to the screencast
  • Get bisq-network/admin#18 (wiki notifications) implemented
  • Send a message to @bisq-network/support-agents linking to the wiki and asking everybody to read it and take action, and to please 👍 this message to indicate you got it and will do. Mention / link to the screencast. Ask to respond with any questions or feedback, and to make edits to the wiki as appropriate (Improve Support #18 needs to be done first!). Also ask agents to #reference this issue when they create their first case tracking issue, so we can easily realize when the task immediately following below is finished.
  • Leave this issue open until all current @l1-support-agents and @intern-support-agents have created at least one support case issue correctly
    • @bisq-knight
    • @leo816
    • @huey735
    • @mwithm
    • @bayernator
    • @wiz (?)
    • @m52go (?)
  • Write script / application that queries the GitHub Issues API to produce the metrics listed above in delivery criteria
  • Make it a duty of the support team lead role to run that script and report on those metrics every cycle.
@cbeams cbeams self-assigned this Feb 7, 2020
@cbeams cbeams transferred this issue from bisq-network/admin Feb 17, 2020
@cbeams cbeams added has:approval bisq.wiki/Project_management#Approval is:stalled bisq.wiki/Project_management#Stopping_work needs:info bisq.wiki/Project_management#Triage and removed needs:info bisq.wiki/Project_management#Triage labels Mar 6, 2020
@cbeams
Copy link
Member Author

cbeams commented Jun 8, 2020

Closing as aborted. Per https://github.com/orgs/bisq-network/teams/dao/discussions/13, I'll be stepping down from the role of Support Team Lead (bisq-network/roles#102), and rather than leave this open or try to hand it off to someone else (e.g. the new team lead), it's probably better to call the shot that this has, in the end, not been important enough to get done, and to just drop it. We are unable to really measure support activities without this kind of tracking, but user support is no longer a serious pain point for the project; it appears to be going pretty smoothly and perhaps the current process, e.g. coverage calendar and escalation process is "good enough" for the time being. The one thing that's really missing without this kind of tracking in place is getting good data about which critical bugs and issues are causing issues to land in support, but in practice, we know what most of these are anyway; it's just a matter of actually fixing / addressing them.

@cbeams cbeams closed this as completed Jun 8, 2020
@cbeams cbeams added was:aborted bisq.wiki/Project_management#Closing_as_aborted and removed is:stalled bisq.wiki/Project_management#Stopping_work labels Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has:approval bisq.wiki/Project_management#Approval to:Improve Support was:aborted bisq.wiki/Project_management#Closing_as_aborted
Projects
None yet
Development

No branches or pull requests

1 participant