What do all the categories, fields etc mean in the bug tracker? How are they used in the Dungeon Crawl Stone Soup project? This page is a work in progress.
Categories are what separate bug/FR/etc trackers are in SF. You don't pick a different tracker to see BRs and FRs, instead, you filter by Category.
Current categories and what they are used for (not necessarily final; feedback is welcome!):
Bug Reports - reporting bugs and anomalies in the game
Feature Request - for requesting new features. Note that wiki is meant to be utilized heavily.
Documentation - fixes to documentation, plans and requests for documentation.
Gameplay Balancing - when there's a problem with the game design, i.e. the code works correctly but the design needs fixing. Not quite a request for a New Feature.
Graphics - For new tiles and requests for tiles.
Interface Improvements - feature requests considering the user/playing interface(s).
Source Cleanup - ideas, plans and proposals for making the innards of Crawl codebase work better
Support Request - I guess build issues and so on, not related directly to the game but availability of it etc
Testing and Feedback - for general feedback. Developers can also post “feedback/testing wanted” tickets, and in the summary/OP provide information about what is wanted to be tested, and possibly also methods of testing. Then testers and commentators can post comments and testing results. Wiki might be better for both.
Vaults - Mainly for new vaults, as a way to submit them.
More can be added as needed. TODO: Add new categories to the Status proposal below.
Oh, and a separate patch tracker is not needed - people should be able to post patches to BRs and FRs directly. TODO: Document/propose how this would work.
— evktalo 2009-11-26 18:15
Resolution has open, fixed, reopened, unable to reproduce, not fixable, duplicate, no change required, suspended, won't fix
Change “fixed” → “done” and “won't fix” → “won't do” to make them work in non-bug context.
(Discussion in this mailing list thread. Old discussion on this page here)
todo for documentation: how these resolutions would work in different DCSS categories:
Bug Report
Documentation
Feature Request
Gameplay Balancing
Graphics
Interface Improvements
Source Cleanup
Support Request
Testing and Feedback
Vaults
Values: New, Feedback, Acknowledged, Confirmed, Assigned, Resolved, Closed.
Previous discussion
Keeping all the current statuses, adding a “brainstorm” status for gathering ideas to the wiki.
New list of use of statuses per category:
Bug Report
“new”
“feedback” - requesting more info from filer.
“acknowledged” - the team acknowledges the bug without (being able to) confirm it
“brainstorm” - is not used.
“confirmed” - the bug has been seen or reproduced by the team
“assigned” - assigned to someone to be fixed.
“resolved” - someone has implemented a fix, pending confirmation (from someone else than the fixer) that the fix works.
“closed” - confirmed that the fix works (or closed because “rejected” resolution).
Gameplay Balancing
Feature Request
Interface Improvements
Documentation
Graphics
Vaults
Source Cleanup
Support Request
“new”
“feedback” - requesting more info from filer.
“acknowledged”
“brainstorm” - feedback and ideas are gathered and edited on the wiki page
“confirmed” - the proposal is complete, ready to be implemented
“assigned” - someone is assigned to implement the proposal
“resolved” - implementer considers work done
“closed” - someone else confirms the issue can be closed (or closed because “rejected” resolution)
Testing and Feedback
“new”
“feedback” - requesting more info from filer (used if a player/tester filed an issue that needs clarification)
“acknowledged”
“brainstorm” - basic mode for developer-filed requests for T&F.
“confirmed”
“assigned” - someone is assigned to look at the feedback and turn it into new issues/fixes as necessary
“resolved” - feedback has been read, turned into new issues/etc
“closed” - someone else confirms the work is done
— evktalo 2010-01-11 12:42
Priorities are currently none, low, normal, high, urgent, immediate.
Previous discussion
Measures the importance of bug/proposal.
todo for documentation: how the priorities would work in different DCSS categories:
Bug Report
Documentation
Feature Request
Gameplay Balancing
Graphics
Interface Improvements
Source Cleanup
Support Request
Testing and Feedback
Vaults
Severities are currently feature, trivial, text, tweak, minor, major, crash, block. —
evktalo 2009-11-20 00:03
Previous discussion
Used for bugs and perhaps gameplay balancing issues.
todo for documentation: how these resolutions would work in different DCSS categories:
Bug Report
Gameplay Balancing
Not used for:
Documentation
Feature Request
Graphics
Interface Improvements
Source Cleanup
Support Request
Testing and Feedback
Vaults
And then there's the Projections: none, tweak, minor fix, major rework, redesign.
Previous discussion
Used to predict the scope of change; the work required to complete it.
todo for documentation: how the projections would work in different DCSS categories:
Bug Report
Documentation
Feature Request
Gameplay Balancing
Graphics
Interface Improvements
Source Cleanup
Support Request
Testing and Feedback
Vaults
