This is an old revision of the document!
We are working towards making Mantis' defaults work for DCSS. Some of it is tweaking existing fields to suit our needs. But also making a plan what all the possible selections should mean to us, and how they should be used. Please take a look at the tracker, read discussion here and participate!
Generally, tweaks rather than overhauls.
There won't be different fields according to category for now.
Categories won't have subcategories.
Starting form the mantis defaults, fields are in progress of being customized to suit the needs of Stone Soup development.
(Simple view shows less fields.)
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 (remember, this is a proposal and feedback is desired!):
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
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:
Values: New, Feedback, Acknowledged, Confirmed, Assigned, Resolved, Closed.
The use seems to be for the developers to communicate the status of its knowledge and actions of the issue. Not sure what “feedback” is meant for. — evktalo 2009-11-20 00:03
I guess these are useful for our coders, especially to check if someone already had a look. — dpeg 2009-11-20 00:06
I suggest removing Feedback and Acknowledged for bug reports. — rob 2009-11-26 10:25
I suggest to add Unconfirmed for bugs (as in “I tried, but did not get the bug”) — it is crucial to see at a glance whether some item was looked at and Confirmed/Unconfirmed do that for bugs; I don't have an idea for how to say “this is a Feature Request I don't have an opinion on” — dpeg 2009-11-27 02:07
“Feedback” is meant to request feedback from the feature requestor/bug reporter. All marked as those show up in the “Awaiting feedback from me” box in “My View” of the reporter only (currently) yet also in the “Assigned to me” box of the person the FR/BR is assigned to. — Napkin 2009-11-27 09:49Ahh, excellent, that makes sense. I added this to the list below. — evktalo 2009-11-27 11:42
I guess Acknowledged is sort of the status to move things from New, but I'm fine with leaving issues at New until we can get some sort of resolution, so yeah, in favour of removing it. I agree that Feedback for bugs doesn't make sense. Also, instead of Confirmed we might want to use some other term for Feature Requests, essentially saying 'to be implemented'. Is there a way to make resolved (or rejected) items close themselves automatically after some time? That way, it could be used for implementations with some questions left open or waiting for feedback, etc.
Basically, this comes down to the following:
(Here, Feedback could be used for additional information being given but seeing how Mantis pulls these up top anyway, that's not really necessary. Alternatively, we could ask for additional information but again, with all reporters being signed in and leaving a valid email address that doesn't seem necessary either.)
And yet another question: Is it possible to define a pseudouser to assign items to as a sort of alternative to “Patches Welcome”? It not, that could be a sibling of Ready for Implementation (or however we end up calling this). — jpeg 2009-11-26 10:32
Patches Welcome should be a tag. — evktalo 2009-11-26 17:33
We need the same statuses for all the categories. Here's a rundown how the current DCSS statuses + brainstorm could be used in each of the categories - I've left those (except new) blank where I had no opinion. I didn't think of much anything for “acknowledged”. It *could* be used for signifying someone in the team has read the issue. There's still plenty of statuses, this may seem/be process-heavy, but listing it down like this should make it easier to propose cutting (even adding) something. Comments please!
— evktalo 2009-11-26 17:33
Nice list. Two conclusions (thinking of bugs) for me:
Apart from that:
— rob 2009-11-27 10:45
Good comments. Napkin clarified how Feedback works above and I've adjusted Status section accordingly. (feedback without assignment is asking feedback from the filer, so it's not to be used like “brainstorm”!) The “Setting “feedback” should”.. bit we can put into usage guide pretty much directly. :)
I see the point about “confirmed” and agree, with BRs it's different than reproducibility. Tweaked the list above accordingly.
I'm not sure about “unconfirmed” status. The good: it'll show up directly in the view issues list. Bad: it's a new status. :) Alternative: There's a Reproducibility field, it can be used and notes can be posted if someone does/does not reproduce the bug with specific version/setup. (And the field wouldn't be used except for BRs.) A tag can be used to mark some mysterious, rare bugs as such.
I want to keep “Confirmed” as a status, as it can indicate an implementable FR from a glance to the view issues list.
This and dpeg's “it is crucial to see at a glance whether some item was looked at” above are making me think that while I'd like to cut statuses, “Acknowledged” should be kept as the basic status of issues. At least when it comes to FRs, transitioning from “new” to “confirmed”(meaning implementable) is icky. Need to ponder upon this some more. It should *not* mean that who ever changed the status to “acknowledged” is taking care of the issue. Maybe it could be renamed, maybe consolidated with “brainstorm” for FRs?
The point about “assigned” status and “assigned to” field is a great one. Like in my above list, “Confirmed”+assigned to seems just the same as “Assigned”+assigned to. — evktalo 2009-11-27 12:18
Feedback might be nice to consolidate with “acknowledged”, but I think it has some (hardcoded?) functionality: it's the way you can request more feedback from the filer. This is much like assignment, but I don't think we have the option to arbitrarily assign issues to any users, they need to be of certain user level. — evktalo 2009-11-27 12:31
In that case (Acknowledged kept as the logical transition from New) maybe we should rename it to something a bit less intimidating? Agree that we need something inbetween New and Confirmed (for both FRs and Bugs) - for bugs that'd be the status to go with “tried it, but can't repro” that David wants to have. Also agree that Assigned as a status isn't really necessary. — jpeg 2009-11-27 21:34
Looks like “Assigned” is pretty hard-coded too; it went on automatically from “confirmed” when I assigned an item. So we'll keep it. — evktalo 2009-12-19 20:20
Keeping all the current statuses, adding brainstorm.
New list of use of statuses per category:
— evktalo 2010-01-11 12:42
Categories (BR, FR, support, test) could use subcategories; like the categories in the SF tracker.
In SF, there currently are:
for BRs: None, Arena, Build, Code Conventions, Dungeon, Interface, Items, Lua bindings, Miscellanous, Monsters, Player races, Religions, Spells, Tiles.
for FRs: Atmosphere/Flavour, Documentation, Gameplay Balancing, Interface Improvements, Tiles. — evktalo 2009-11-20 00:03 I would like to have thematical subcategories for FRs for the major topics: spells, gods, species (dpeg).
Could this be handled with tags? — evktalo 2009-11-20 00:03 Yes, but I find the tags to be more clumsy. E.g. for gods, it would best to have them in a separate folder on the moon or so. Subcategories should help in displaying/ignoring them. — dpeg 2009-11-20 00:06
More here: Tags policies
Since we can't add different subcategories to different categories, we'll go with categories and tags. — evktalo 2009-11-26 17:06
None is good for e.g. undecided FRs. Looks ok otherwise too? — evktalo 2009-11-20 00:03 Is ok — dpeg 2009-11-20 00:06
The priorities are fine, though I would add “rejected” for the same purpose as “1” on SF (to gather feedback before closing). — jpeg 2009-11-21 00:59
“rejected” is a good idea. — evktalo 2009-11-24 09:46
It should be a resolution, not one of these though. — evktalo 2009-11-24 11:52
True. — jpeg 2009-11-27 21:52
I'm not quite sure what all of those mean, so the severities we are going to use, if any, should be decided and documented. (evktalo)
I like the severities – the priority does not tell you what's the scope of the change. These severities are for bugs, obviously. We could use a couple more: tiles, vaults. Not sure if we need tweak, minor, major. Would rename text to speech or messages. — dpeg 2009-11-20 00:06
I think Tiles should be a category rather than a severity, there are tile specific crashes and minor misbehaviours, after all. If we restrict severities to bugs, feature and tweak don't belong there. I interpret trivial to mean typos, text (or message) description improvements (which are borderline FRs), the rest are fine as-is. — jpeg 2009-11-21 00:59
On second thought, Tiles is probably what the “Product Build” is there for, though I fear no one will find it there with that name… — jpeg 2009-11-21 11:46
Other than BRs (and perhaps Gameplay Balancing) issues don't need Severity. — evktalo 2009-11-26 16:32
Since we can't have different fields etc for different categories, all of them will have Severity but only BRs will use them in another setting than “none”.
Here's a proposal: “none”, “tweak”, “minor”, “major”, “crash”. “none” is used when the issue is not a BR. Vault/speech BRs use tags and “tweak” for typos etc, “minor” and “major” if more knowledge of the syntax of those files is needed. — evktalo 2009-11-26 17:58
I suppose the “block” priority is meant for the highest urgency when you can't even get the code to compile, though the name is a bit unclear about — jpeg 2009-11-27 21:45that.
Not sure if we need all three - just “priorities” might be enough. — evktalo 2009-11-20 00:03 I like the priorities — dpeg 2009-11-20 00:06
I don't think this is needed. Redesign could be a nice tag for FRs, though. — jpeg 2009-11-21 00:59
Ok - looks like we could axe the projection field. — evktalo 2009-11-24 09:42
Well not necessarily yet. I gather dpeg would like the scope of the propsed change to be measured in a field. Severities are for bugs, but projections work for FRs/Game Balancing/Code Cleanup. I think we could use one and not the other depending on the category. — evktalo 2009-11-26 17:27
Show sticky issues should be on by default.
There needs to be a lot less fields in the filter in general. It looks unwieldy. Especially for FRs; OS/OS version/Platform etc fields are probably good for bug reports? While the simple view is much cleaner for viewing issues, the “simple” filter needs to be simplified.
Yes. Do we really need “Monitored By” and “Hide Status” (whatever that is)? I agree that having both Platform and OS seems redundant, though OS version (specific Windows/Linux version) might come in useful. Agree that Sticky should default to true (and maybe be nonremovable?) I'm not sure what's the difference between “Product Build” and “Product Version”. Is there a way for me to predefine common filters I want to use (such as Tiles specific bugs, or recent feature requests)? — jpeg 2009-11-21 00:59
Yes, you can predefine common filters and make them publicly available, yay! — jpeg 2009-11-21 11:46
Excellent! — evktalo 2009-11-24 09:42
“Recently active Features” should include both Feature Request and Interface Improvement, since the latter is a type of feature request.
Also, some good additional predefined filters would be “My assignments” (assigned to me), “My reports” (issues reported by me), and “My monitored” (issues monitored by me). — Matthew Cline 2009-11-27 12:35
Good ideas! — evktalo 2009-11-27 12:54
Oh, also, the “Open” filters should include both open and re-opened issues. — Matthew Cline 2009-11-27 12:43
With this in mind, what do you think of axing “open”, “re-opened” etc.. resolutions would just be “none, “done”, “rejected”? (the whole proposal is a couple of sections up) — evktalo 2009-11-27 12:54
Also see Customization of "View Issues"
Priority should be “none” by default - only devs should be able to set it.
Reproducibility should be automatically set to “N/A” unless category is BR.
Apparently, you can specify with these which version, platform, etc etc (Tiles/commandline/server distinction could be handy for us) you use.
The problem is there are a lot of fields, and too many fields is unwieldy and unwelcoming.
Could be good for bugs though.