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

From Dreamwidth Notes
Jump to: navigation, search
(First Revision)
 
(removing GIthub Reporting section - merely repeats steps from GHI page, which is now linked)
 
(21 intermediate revisions by 11 users not shown)
Line 1: Line 1:
−
{{Note|text=This is currently a proposed policy that is open to comment.  If you have ideas for how this proposal could be approved, add them to the Discussion Page or contact skrshawk directly.}}
+
{{Note|text=This currently requires update to match current practice, full swapover to GHI, and update from Support leads on current practice.}}
  
−
Currently a significant number of support requests are related to site functionality, many of which may be actual bugs.  Most bugs are known, but since this is such a common source of inquiries we need to be able to handle them quickly to keep our stress levels down and our users happy!  With this in mind, follow these steps to ensure a consistent, timely approach.
 
  
−
== Bug Workflow ==
 
  
−
1.  When a bug report comes in check to see if it's known already.  The best way to do this is to search Bugzilla.  Put important words into the search.  Also ask around IRC - people can often point to common bugs off the top of their heads.
+
= Bug Workflow =
  
−
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.  Give them the Bugzilla link so they can see our log (important confirmation that we have indeed registered the bug - transparency at work!) and track its progress if they wish.  Handle any further inquiries as necessary.
+
== Is it known? ==
  
−
2. 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 a bug to log the enhancement request.  Great ideas come from everyday users.
+
When a bug report comes in, check to see if it's known already.  Dreamwidth has moved from Bugzilla to [https://github.com/dreamwidth/dw-free/issues 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).  
  
−
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:
+
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 <dwuser>mark</dwuser>, ''don't'' give links to the Github Issues entry!  A good description of what we have on file will suffice.
  
−
- Operating System and Browser, versions if possible
+
== Confirm the bug steps ==
−
- 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!
+
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.
  
−
3.  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.
+
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:
  
−
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.
+
* 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.
  
−
== Bugzilla Reporting Workflow ==
+
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!
−
 
+
−
The entire Bugzilla workflow (which goes from bug reporting to committed patch) can be found here: http://wiki.dwscoalition.org/notes/Bugzilla_workflow .  The full article is good reading so you have an understanding of the entire development process.  Here is a simplified version focusing on bug reporting.  If you'd rather follow the primary document, the first three steps are what you need to know.  Otherwise, read on.
+
−
 
+
−
1.  To log a bug you will need a Bugzilla account.  Anyone can make one, so follow the simple process.  You don't need an account to search and view bugs, however.  Go here to create your account: http://bugs.dwscoalition.org/createaccount.cgi
+
  
−
2.  Create the bug here: http://bugs.dwscoalition.org/enter_bug.cgi.
+
== File a bug! ==
  
−
Select a queue for your bug.  Generally you're going to want the Dreamwidth Development queue.  If the bug is related to something that needs to be better clarified in the FAQs or elsewhere in the site copy, use the Project Documentation queue.  The next screen is the main bug entry page.  Fill in the following fields:
+
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.
  
−
<b>Component:</b> Most of the time UI/Frontend is the nature of the bug, but use other options as appropriate.
+
'''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.
−
<b>CC:</b> Add your email here if you want to track progress of the bug.
+
−
<b>URL:</b> The page (if appropriate) where the bug is happening.
+
−
<b>Summary/Description:</b>  Fill these in with as many details as you can - you should have plenty from your interaction with the user and other support people.
+
−
<b>Severity:</b> Most likely the highest severity you'll need to use is minor, which is what you want if you suspect a bug affect a significant number of users.  Any higher than that should be significantly affecting site usability - if so, talk to a senior about it (or check with IRC).
+
−
<b>Priority:</b> You'll want to stick with P4 or P5. If you suspect a bug warrants a higher priority, again, talk to a senior (or mention it in IRC).
+
−
<b>Tags:</b> Stick to the existing tag list.  The tags are intuitive; use what's most appropriate.
+
−
<b>Flags:</b> You may wish to use need-spec or needs-design for enhancements that aren't fully fleshed out.  Spec is for enhancements that need thought as to just what should be done; Design is for enhancements that might need thought put into the visual/frontend elements. Set either to ? as appropriate.
+
  
−
3.  Hit the commit button and watch it go into the queue (and Bugsy report it in #dw!).  Be prepared to field further questions from the devs if needed - don't worry, we don't bite unless asked nicely!
+
[[Category:Support]]
 +
[[Category:Brainstorming]]
 +
[[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"