Difference between revisions of "Data Bug Process"

From PCGen Wiki
Jump to: navigation, search
m
 
Line 25: Line 25:
  
 
NOTE: You may fix an issue and skip the IN-PROGESS to the RESOLVED [If addressing another Reporters issue] or CLOSED [IF and ONLY IF you are adding a Feature and you are the Reporter].
 
NOTE: You may fix an issue and skip the IN-PROGESS to the RESOLVED [If addressing another Reporters issue] or CLOSED [IF and ONLY IF you are adding a Feature and you are the Reporter].
 +
 +
I intend to work on a few steps - In the future we'll have:
 +
 +
* Confirmed Bug [Data Member confirms the Bug]
 +
* Cancel [Data Member can't confirm the Bug - Issue will be set to 'Can't Reproduce' and Reporter will need to re-open or Comment on how to find the bug]
 +
* Needs Code Work [This Bug is unresolveable by LST work alone, Monkey needs to open a CODE-BUG, LINK the original issue marking it as [DATA-xxx] requires [CODE-xxxx]
 +
* Code Work Complete - Implement LST fix [Code Team has fixed the code, back to LST for final resolution]

Latest revision as of 10:08, 10 December 2011

Data Bug Process:

Open JIRA Tracker - Anyone with a JIRA Account may open a Bug for Data

Bugs are to fix existing data sets with issues believed to be LST issues in origin.

Example: Say I have an ability that says "Allows te user to 1/day per 8 levels to increase their attack by +1 per 2 levels" The user could say their is a typo "Allows the user" or mention a Class progression is incorrect.

Data Bug Submissions should be as detailed as possible.

SUBJECT: [GameMode] Issue discovered as one liner

  • Which Version did you discover it? [Select appropriate AFFECTS VERSION]
  • What Game Mode are you using? [Game Mode is a Component to be selected]
  • What Data Set(s) are you loading? [Crucial to isolating a problem]
  • What Steps will reproduce the bug?
    • Remember, someone else has to be able to duplicate your problem, and test their fix to make sure it's actually working.

STEPS:

  • Open [Someone Submitted a request - Data Team Determines it's a legitimate request and will mark it for 'In-Progress']
  • In-Progess [Determined to be legitimate - Monkey has assigned themselves and are working on it]
  • Resolved [Data Monkey has added the issue - the Original Reporter is notified. Set FIX VERSION as the next Release Version]
  • Closed [Reporter is allowed to CLOSE the issue if they confirm the issue has been implemented and are happy with the results, otherwise a Tracker Monkey, or Data 2nd/Silverback will close after a few Release Cycles]

NOTE: You may fix an issue and skip the IN-PROGESS to the RESOLVED [If addressing another Reporters issue] or CLOSED [IF and ONLY IF you are adding a Feature and you are the Reporter].

I intend to work on a few steps - In the future we'll have:

  • Confirmed Bug [Data Member confirms the Bug]
  • Cancel [Data Member can't confirm the Bug - Issue will be set to 'Can't Reproduce' and Reporter will need to re-open or Comment on how to find the bug]
  • Needs Code Work [This Bug is unresolveable by LST work alone, Monkey needs to open a CODE-BUG, LINK the original issue marking it as [DATA-xxx] requires [CODE-xxxx]
  • Code Work Complete - Implement LST fix [Code Team has fixed the code, back to LST for final resolution]