JonStanley/BugTriageIdeas

Also see JohnPoelstra/ImprovingBugzillaF9

Bugzapping Ideas

Separate Instance of Bugzilla

Not really an option, IMO, since RHT employees will be required to work in two separate bug tracking systems. Reassigning and cloning between instances would be a problem. I see this as especially an issue for the Security Response Team, whose work we we absolutely do not want to impede. Agree - ChristopherBrown

Require Changes to Bugzilla

• fedora-triage flag Not sure I agree on this one. For what purpose another flag? Prefer ASSIGNED - ChristopherBrown
• New UNCONFIRMED state ala mozilla.org (why did RH take this away? I agree not really useful for RHEL (well it could be - with IT being able to open stuff in NEW and BZ reporters unable - that could actually be valuable to RH internally as well), but essential for a community driven product. This could actually be accomplished via workflow changes below - JonStanley
• Whining for bugs not touched with fedora-triage flag
• Enforce upper limit on comment size? Refer to bugs such as this where reporters paste gobs of text that should be in an attachment, making it harder to read.

Bodhi state changes

• Maybe a new flag fedora-rawhide???
• When bodhi pushes to rawhide, set this new flag (or at very least make a comment, may already do this)
• When pushed to updates-testing, set status ON_QA
• When pushed to stable, set status CLOSED ERRATA Prefer CLOSED CURRENTRELEASE - ChristopherBrown

FAS changes

• Ensure that 'fedorabugs' requires either cvsextras or sponsorship. I recommend going to a sponsor system for fedorabugs since you do not want just automatically approving memebership in it, as well as the fact that only sponsors get mail when new members wish to join.

Policy/Proceudre changes

• Weekly IRC meetings
• Rewards for top triagers Not so keen on this - why not reward top packagers etc etc. - ChristopherBrown
• Triage Guidelines - some already exist at BugZappers/TriageGuidelines
• If fedora-triage flag not viable, change definition of states - NEW to ASSIGNED. ASSIGNED should become the equivalent of fedora-triage+, and ON_DEV the new ASSIGNED. Prefer this. ChristopherBrown
• Use the Triaged keyword
• Use the EasyFix keyword and tracker bug
• Need something like the Docs project has for 'how to become a triager'

Distro-level changes

• Implement a many-many package<->maintainer model, ala Gentoo Herds , with triage being one of the ways that a new contributor can enter the herd
• Integrate with the various SIGs within the distro a triage function.
• Some sort of deadbeat maintainer system maybe with the assistance of PackageMaintainers/PackageStatus

Mass closure

• We should probably mass-close all bugs of unmaintained releases . It is highly unlikely that these are actionable any longer.
• Need to develop a policy for NEEDINFO bugs. I am in favor of short lifecycle for these - a week or two at most (maybe 3 - see this bug for a request to make this automatic from some time ago. Agreed - I have been using 2-4 weeks. ChristopherBrown
• Something similar has been attempted before.

Mass closure comment

Hello,

Thank you for taking the time to report this bug. Unfortunately, this version of Fedora has reach end-of-life and is no longer maintained. Please refer to http://fedoraproject.org/wiki/LifeCycle for an explanation of the Fedora lifecycle policy.

We therefore regret the necessity of closing this bug report WONTFIX. Please upgrade to a currently maintained release of Fedora, currently either Fedora 7 or Fedora 8, update the system using either 'yum update' or pup, and attempt to reproduce this bug. If the bug still exists, feel free to re-open this bug report, changing the version accordingly, or file a new bug report (you can use the 'Clone as Bug' link at the top of this bug report in order to preserve the content of this bug in the new one).

If you no longer have the hardware that is required for reproducing this bug, it would helpful if you would mention that and close this bug as INSUFFICIENT_DATA

The Fedora Project is undergoing a revitalization of its bug triage program, staffed for the main part by volunteers. We are committed to addressing bugs in a timely and courteous fashion, and we thank you for the time you have taken to file bugs. Please be assured your Fedora experience matters to us, and we hope you will enjoy all the innovations, features, and improvements we have provided in the latest release.

We regret any inconvenience that this may cause you, and thank you for your continued support of Fedora!

Bugzilla workflow

Here's some suggested changes to the Bugzilla workflow. Not being privy to internal RHT processes, I don't know if these align well or not. This area is one where I desperately want input:

• NEW - incoming bug
• ASSIGNED - triaged bug (or maybe NEW with Triaged keyword?)
• ON_DEV - assigned person has actually started work and commits to resolving bug
• MODIFIED - assigned person has committed possible fix to CVS or build to Koji for testing
• ON_QA - Bodhi has pushed to updates-testing
• CLOSED ERRATA - Bug is released to stable I think CLOSED CURRENTRELEASE is better and have been using this for kernel bugs as an indication of what fixed the issue - ChristopherBrown

Obviously bugs can transition from either NEW or ASSIGNED to either NEEDINFO or a proper CLOSED state as well (WONTFIX, NOTABUG, etc).

Suggestions?

• If you have additional suggestions, please feel free to either modify this wiki page or if you are unable to do so due to the lack of a Fedora account and membership in EditGroup, then you can post a comment at my blog .

More to come after I review the few e-mail threads that we've got on the topic and IRC logs....I'm forgetting alot here.

Bug Triage for Component of Fedora Core/Extras

Mentor:

Title of Triage Task

Volunteer(s):

Description: Task description. What type of bug triage do you need help with? Are there hardware specific requirements? Is there an example bugreport they should review?

---

["Bugs"]