openSUSE:Bugreport process

This is digest of discussion "Improving the bug management lifecycle/process" on opensuse-project mail list.

Goals

What is the aim of this bugreport project?

To make the bug reporting process more efficient and effective, enhancing developer productivity and user satisfaction.

• First phase - address the triage and initial screening process. This involves a few steps:
  1. Clearer documentation on the bug statuses for non-technical users (particularly for bugs in a NEEDINFO state - non-technical users may not always understand what this means, resulting in them thinking the bugs are being ignored when in fact we're waiting for them to provide some necessary information)
  2. Survey users (tech and non-tech) to find out what their perceptions are and where the process needs to be clearer.
  3. Survey developers to find out what pain points they have that might be addressed by reviewing

• Parallel to the analysis above:
  1. Work out a way to advance existing bugs from old versions of openSUSE
     • Identify bugs that are resolved or no longer relevant in 11.4 or 12.1
     • Update bugs that are still relevant to reflect their relevance for 12.1
     • Those bugs that are still relevant should go through the screening process again for de-duping purposes

• Second phase (to be more clearly defined later)
  1. Identify bottlenecks after triage - overloaded teams, skills/interest mismatch, etc?

Possible Problems

1. bug reporting problems
   • user not following instruction
     1. possible reasons:
        • not able to navigate instructions
        • not attempting to find instructions
        • not able to understand instructions
        • not able to locate required information on their machine
        • other reason
     2. problem with form/layout/procesing?
2. bug processing problems
   • developers swamped with ?
   • not enough information to act on report
   • reason
   • another reason

Discussion Points, including from list

Please feel free to add any comments on any aspect of Bugzilla. Keep as concise as possible.

Ideas to follow up: consistency with other distro Bugzilla instance Should alternatives be considered? (Mantis, Trac, Issue tracking on GitHub....)

TODO:

• add relevant quotes from "Improving the bug management lifecycle/process".
• poll forums for user opinions on Bugzilla
• poll developers for their pain points in the bug tracking/resolution process
  • including what trends they see in reports that don't include necessary info - if we can reduce NEEDINFO situations, we should be able to increase resolution speed.
• check mailing list & forum for info re previous bugsquashing day comments/ideas
• information on longevity/capability of Bugzilla, capacity for addons/front ends
• this page: add links to relevant Bugzilla information pages - what are existing resources?
  • openSUSE:Submitting_bug_reports aka bugs.opensuse.org - and the pages linked from there
    • some of those are still on old-en.o.o
  • several labels in the bugzilla form (enter_bug.cgi) are links that provide more information (component, hardware, OS, severity, bug status etc.)
• ideally would like to conduct mini study: ask some users to go through bug submission process (perhaps create a scenario and provide them with error message?) and observe their progress.

(The below is pulled in from temporary wiki location)

This page is just for brainstorming ideas about the tasks that need to be completed for this project.

In no particular order (ordering will be determined later):

• Identify the current process for bug reporting
• Identify the current process for bug screening/handling
• Identify what's needed in a good bug report (for documentation purposes - and possibly a bugzilla template)
• Identify desired workflow for bug reporting
  • Highlight desire for bugs to be discussed in community before reports (may not be a hard requirement, but bugs that do this are likely to be more complete and thus more likely to be worked on)
• Identify desired workflow for bug screening/handling
• Identify thresholds for identifying a bug should not be pursued (for example, unable to duplicate and reporter provides no additional information after 'x' days/weeks)
• Figure out what to do with bugs from old releases
  • Determine relevance to current releases
  • If they are relevant, update the version in the report and reassign if necessary
  • If not they aren't relevant, identify the best way forward (possible they might be relevant to SLES/SLED, in which case they might still need to be reassigned with a different product?)
• Identify if a regular bug review session on IRC would be advisable (say every week or two?)