Difference between revisions of "Bug Report Workflow (Support)"

From Dreamwidth Notes
Jump to: navigation, search
(→‎Github Issues Reporting Workflow)
(removing GIthub Reporting section - merely repeats steps from GHI page, which is now linked)
 
(5 intermediate revisions by 2 users not shown)
Line 26: Line 26:
 
== File a bug! ==
 
== File a bug! ==
  
−
If you need to file a bug, you can follow the instructions for bug reporting (anyone is welcome to file a bug!), or you can hand this off to a senior support person if you'd prefer.  Do as much of the process as you're comfortable with and ask questions along the way.  Try to get someone else to verify the bug and the steps to reproduce it if possible.  If you can't reproduce it (or you can but someone else can't) make a note of this in your report.
+
If you need to file a bug, you can follow the instructions for [http://wiki.dreamwidth.net/wiki/index.php/Github_Issues#Reporting_Bugs bug reporting]  -- anyone is welcome to file a bug, but it does require a Github account. If you prefer, you can hand this off to a senior support person instead.  Do as much of the process as you're comfortable with and ask questions along the way.  Try to get someone else to verify the bug and the steps to reproduce it if possible.  If you can't reproduce it (or you can but someone else can't) make a note of this in your report.
  
 
'''IMPORTANT:''' If the user is reporting a security-related bug in the main support queue, ''don't touch it''!  Alert a senior support person, who will transfer the request to an appropriate private queue.  We need to keep these things out of the public eye, so if you spot a miscategorized report, tell us immediately!  This also applies to Abuse/ToS related support requests.
 
'''IMPORTANT:''' If the user is reporting a security-related bug in the main support queue, ''don't touch it''!  Alert a senior support person, who will transfer the request to an appropriate private queue.  We need to keep these things out of the public eye, so if you spot a miscategorized report, tell us immediately!  This also applies to Abuse/ToS related support requests.
−
 
−
= Github Issues Reporting Workflow =
 
−
 
−
The entire Github Issues workflow (which goes from bug reporting to committed patch) will be found at the [[Github Issues workflow]] page. This page will be updated at some point when it's finalized.
 
−
 
−
 
−
A general overview:
 
−
 
−
 
−
# You will need a Github account to file a bug, although you can probably search the issues without one.
 
−
 
−
# Link to create the issue goes here.
 
−
 
−
# Description of the minimum amount of information to create the bug goes here. Commentary on documentation process if different.
 
−
 
−
# How to submit. Don't be afraid that you've left out something important. If devs need further information, they will ask; in accordance with your Github settings, you should be notified.
 
  
 
[[Category:Support]]
 
[[Category:Support]]
 
[[Category:Brainstorming]]
 
[[Category:Brainstorming]]
 
[[Category:Development]]
 
[[Category:Development]]

Latest revision as of 03:50, 7 August 2015

Note: This currently requires update to match current practice, full swapover to GHI, and update from Support leads on current practice.


Bug Workflow

Is it known?

When a bug report comes in, check to see if it's known already. Dreamwidth has moved from Bugzilla to Github Issues. You can also ask around Support areas to see if anyone else is aware of whether it's filed (or was filed in Bugzilla).

If the bug is a known issue, reply to the user letting them know. Use appropriate soft skills, especially if the issue has resulted in frustration or data loss. Per [info]mark, don't give links to the Github Issues entry! A good description of what we have on file will suffice.

Confirm the bug steps

If the issue is not an obvious bug, get confirmation of the steps that the user is taking to get the problem. It's possible that the issue is user error, but that doesn't mean there's no bug! You may find that a user has inadvertently stumbled on a way to make the service better, in which case you will want to file an enhancement request. Great ideas come from everyday users.

Make sure you understand what the user is trying to do - don't be afraid to ask questions! Emphasize that you are trying to get a clear understanding, while doing your best to not talk down to the user. It takes baby steps sometimes to get to the root of a problem; don't be afraid to share that with someone! Important information to get:

  • Operating system and browser, versions if possible.
  • Exactly what the user is doing, step by step.
  • What the user expects to happen as a result of their steps and what actually happened.
  • Any error messages, copy/pasted.

If you've found the problem was based on what the user was doing give them steps to correct it - nicely, of course. If through their work you've discovered a way to improve the service, continue with the bug report process!

File a bug!

If you need to file a bug, you can follow the instructions for bug reporting -- anyone is welcome to file a bug, but it does require a Github account. If you prefer, you can hand this off to a senior support person instead. Do as much of the process as you're comfortable with and ask questions along the way. Try to get someone else to verify the bug and the steps to reproduce it if possible. If you can't reproduce it (or you can but someone else can't) make a note of this in your report.

IMPORTANT: If the user is reporting a security-related bug in the main support queue, don't touch it! Alert a senior support person, who will transfer the request to an appropriate private queue. We need to keep these things out of the public eye, so if you spot a miscategorized report, tell us immediately! This also applies to Abuse/ToS related support requests.

Retrieved from "http://wiki.dreamwidth.net/wiki/index.php?title=Bug_Report_Workflow_(Support)&oldid=12329"