Skip to content

DRAFT: Evaluate GitLab customer-related bugs for support-contribution suitability

Problem Statement

  • What is the problem?

In a recent SSAT Metrics Workgroup, we observed that a large proportion of our satisfaction:bad SSAT survey results are connected to new-or-existing bug reports in the GitLab Issue Tracker. Support often says to customers that we can't control when bugs are addressed, and customers are frequently unhappy with this answer.

  • Why is this a problem?

Support is frequently in a position of "breaking the bad news" to customers (usually with apologies), and we are unable to provide clarity around fix-dates. This is disappointing to customers, and frustrating for Support Engineers. If we look at open customer bugs, there should be some that Support can fix, which would improve the customer experience and improve the product and improve SSAT.

Proposal

Generate a list of currently open GitLab Issues with labels customer + bug + Accepting merge requests, and identify any that could be fixed by Support team members.

ACTION PLAN

  1. Identify 10 Issues from the large pool to triage and apply Possible Support Contribution label
    1. Update handbook workflow to include the new label applying to Issues
    2. Update handbook to include the Support Team Contribution label goes on MRs only
  2. TRIAL: Find a test group (5-6 engineers, including a few new contributors) to work through this in FY22-Q1
  3. Develop Issue Boards and other tools to evaluate results from the trial / workflow.
  4. IN PARALLEL: Describe an OKR for Rebecca in this. E.g. conducting the trial for a quarter + documenting what we learned.

DRI

@rspainhower with support from @lbot

/cc @lbot

Required Resources

  • GitLab Issue Tracker
  • Documentation and training on submitting GitLab Product MRs
  • TBD: criteria for evaluating support-fix suitability
  • TBD: SEs who can evaluate and categorize bugs
  • TBD: ???

Potential Roadblocks/Things to consider

  • Ensuring SEs feel encouraged to fix bugs without feeling like it's "one more thing" to pack into tight schedules
  • Ensuring SEs have necessary documentation and training on submitting GitLab Product MRs

Desired Outcome

  • What does success look like?

Support increases the number of submitted MRs for customer + Accepting merge requests bugs, reducing time-to-fix. Customer experience is improved.

  • How do we measure success?

  1. Increasing the number of customer MRs by X or X%
  2. Increasing the number of Closed customer MRs by X or X%
  3. Customer experience improvement is measured as: Decreased proportion and/or number of satisfaction:bad SSAT results with product known issue as the underlying reason for the negative feedback.

  • Where would future feedback go?

Feedback Issue TBD.

Related Issues/MRs/Epics/Tickets

Metrics Workgroup - 2020-10: SSAT

MR creating a "How to Code" learning Module for Support

Edited by Rebecca Spainhower