SourceGear's Tag List

Posted by Jeremy Mon, 24 Sep 2007 14:27:00 GMT

In the comments for the post on Tag Clouds, I mentioned one of my goals was to actually provide the “standard” list of tags we use internally. These are tags that we use to imply priority, so that everyone on the team can look at a bug, see which tags apply to it and immediately know what priority the bug should be. I should also reiterate that a bug which was assigned a lower priority because of a tag like Trivial or Grammar will still get fixed more quickly than some higher-priority bugs. Tags are a labeling mechanism that makes them easier to find.

Bugs:

  • PO
    • Blocker: This bug is preventing others within the company from fixing or testing on other items. The item has a time-critical context that supersedes the perceived priority.
  • P1
    • Data Corruption: Any error, whether GUI or API, where server data is or can be corrupted.
    • Broken Beyond Repair: Product feature does not work. No workaround exists
    • Server Crash: Server crash of any kind.
    • Obvious Client Crash: Client crash that is both reproducible and frequent
    • Legal: Errors in wording or use of copyrighted material that presents legal ramifications.
    • First Impression: Issues occurring in the first hour of use that negatively affect sales.
  • P2
    • Broken Causing Pain: Product feature is impacted, but the existing workaround requires extra steps or is impractical.
    • Odd Client Crash: Client crash that is either reproducible or frequent
    • Performance: Performance issues that are common.
    • Support Headache: Small or medium impact, but creates substantial confusion and high support load.
    • Fairly Common: Particular aspect of subfeature not working as designed, and likely to be seen by several customers.
  • P3
    • Broken with Workaround: Product functionality is impacted, but a viable workaround exists.
    • Embarrassing: Impact is small or negligible, but visibility presents poor company image.
    • Broken on Goofy System: Usability not present on certain older systems or non-prevalent machine setups.
    • Well Contained: Particular aspect of sub-feature not working as designed.
    • Odd Performance: Performance issues due to large or odd setups.
    • Not User Friendly: Incorrect error messages likely to produce some support load.
    • Unlikely, but Severe: Infrequent order of steps causes serious error.
  • P4
    • Bug on Goofy System: Usability reduced on certain older systems or non-prevalent machines setups.
    • Hand-Holding: Product functionality doesn’t match user expectations, needs better alerts or help.
    • Grammar: Incorrect or awkward titles or wordings in dialogs.
    • Trivial: Feature impact is small or negligible, and not embarrassing.
    • Phase of the Moon: Infrequent set up steps causes small error.

It has benefited us to make the priority guidelines for feature separate from bugs. In fact there have been times when trying and failing to find the appropriate bug-tags to put on an incoming item has caused me to think “That’s no bug… That’s a feature request!”

Features:

  • FO
    • Blocker: This feature is preventing others within the company from fixing or testing on other items. The item has a time-critical context that supersedes the perceived priority.
  • F1
    • Very Popular: Many people would be positively and substantially impacted by this addition. We have so many requests for this; we need a really good reason why NOT to add it.
    • Internal Consistency: This feature would allow different clients to work the same as their counterparts.
    • Preventative: The program works in a reasonable manner, yet certain bizarre work habits or program interactions will cause problems. This feature will prevent those from occurring.
  • F2
    • Extra Steps: Not having the feature forces the user to stop and figure out how to do what he intended to do by navigating through extra steps
    • Exceeds Expectations: This feature’s existence pleasantly surprises the user, creating customer loyalty.
    • First Impression: Feature additions that positively impact the first hour of use and therefore raise sales.
    • Administration: This feature helps the IT guys maintain Vault with less hassle.
    • Worthy: Many people would be positively or substantially impacted by this addition.
  • F3
    • Graceful: Functionality is not significant, but visibility presents good company image.
    • User Friendly: Better help or error messages likely to reduce customer annoyance or support load.
    • Performance: Adding this feature will improve program speed.
    • VSSConsistency: It needs to work like VSS does.
  • F4
    • Options: Users would like another way to manage his workflow.
    • Useful: Small featurette provides utility for a subset of customers.
    • Odd Configurations: Usability requested for certain odd program interactions, or unsupported systems.
  • F5
    • Diversion: It’s a reasonable request, but it doesn’t quite fit in with our company direction.
    • Misguided: A user is asking for something that ultimately would be a poor choice.
    • Behemoth: While this is a reasonable request, implementing it would take excessive work and have consequences that will spiral out of control in terms of bugs.

no comments

Comments

RSS feed for this post

Comments are disabled