BbWord 2013 Session – Understanding the Lifecycle of a Bug: Transparency around the Known Issue and Patch Process

Heather Maniscalco
Business Process Analyst, Support Operations
Blackboard, Inc.

    Goals and Expectations

To be transparent
To be efficient
To communicate
To respond

    Key Improvements

Behind the blackboard
Issue Tracking System
Dedicated Knowledge Base support
Bug and Patch processes

    Case Review and the Escalation Process

Issue submitted
Tier 1 reviews the case
Issue is a known bug > case associated with the bug and closed, Tier 2 reviews case > if Tier 2 cannot fix it is escalated to Tier 3
Other Answer > Duplicate Answer/Not possible
Needs further investigation > Triage Process > Tier 3


Before bug creation, it is determined if there is a duplicate bug and the case is updated accordingly
All client bugs for the week are reviewed in a Learn Triage Review once a week

Bug targeting variables:
Priority and severity
Number of clients reporting
Approved patch request status

Future Referenced Bugs generally meet the following criteria:
Medium priority/medium severity or lower
Only one client affected
Non-core component
Valid workaround exists

Bugs are ranked for each service pack
About halfway through an SP development, bugs are reviewed again

Will Not Fix status:
Future Reference bugs that have been closed
Phased out or rewritten components
Technologies beyond the purview of Blackboard

    Known Issue Creation and Publication

Known issue articles are ones that describe a known bug
Publish these articles within 48 hours of bug creation
Update these articles as information changes
Review the articles once per year

We do not publish articles based on bugs that are:
Security related
Will not fix
Functioning as Designed

If an issue is not created to a bug, a general article may be created for the issue
The best way to keep track of an issue is with the article number and title
We are phasing out the use of the LRN numbers when publishing information
The new retrieval limit for known issues is 3000
Search enhancements

Articles should contain:
Affected service packs
Target release
Patch information
Steps to replicate


Basic Patch Acceptance Criteria:
Issue is an acknowledged bug
Request is for the last three service pack general releases
Issue affects critical functionality, stability or performance
Issue is preventing an upgrade to a supported product or service pack, or from self-hosted to managed hosting

Basic Patch Rejection Reasons:
Issue is related to a single course or user
Mainline issue is Future Reference, which assumes that the issue is non-critical

Patch Prioritization:
All patch requests are reviewed four days a week

Patches are coded or back ported from the mainline code base
As soon as the patch is crated and code reviewed, the patch will be targeted to the next available Cumulative Patch
We generally have a maximum of seven issues per CP
All patches in a CP are full QA tested
Information delivered in a Support Bulletin. Tree will be links in the Support Bulletin to the appropriate KB articles

    Feedback and Client Involvement

Client Support
Surveys on articles
Client support phone numbers

    Bug Squad

The purpose is to leverage client expertise to aid us in prioritizing bugs
Login to Behind the Blackboard and navigate to Bug Squad under Get Involved


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s