Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Felblood]

There are a lot of bugs on my watch list that are getting tagged as "Resolved" when the problem has not actually been addressed. The ticket is simply getting closed as a duplicate, and that is completely okay, but the tracker managers need to be marking these tickets as "closed" as the problem hasn't actually been "resolved".

This clues in the people watching the ticket that they need to open the ticket and see which ticket it was merged with, so they can update their watch lists.

With the way DF is made by a single dev, I don't see the acknowledged/assigned states being all distinct, but the need for distiction between an issue that has been "resolved" and one that has been "closed" for housekeeping seems pretty clear.

I searched around, and I didn't see anything on this, but it seems really obvious to me. That makes me think this is probably more subjective than it seems to me. Is there some reason for this that I've failed to see?

"Bugs" that are expected behavior, like contructed walls never melting, should probably also be "closed" rather than "resolved" as well, but that's considerably more subjective.

[Footkerchief]

Someone raised the same issue on the tracker.  This is what I told them:

I'm setting them as "resolved" so that Toady can review them before closing them. As far as I can tell, that's the expected workflow for Mantis, so I'm trying it out. Also, when you resolve tickets, it gives you to the opportunity to also set a duplicate relationship, which is more convenient than doing it as two separate steps.

In addition to the fact that Mantis makes it easier to do things this way, here's a workflow diagram for general bug tracking:

Spoiler (click to show/hide)

I agree that "resolved" isn't the best word for duplicates, though.  This is all still very experimental, so I may switch to closing them directly, depending on what works best for Toady.

e: Heard back from Toady -- we're going to stick with this method, at least for now.

[Zalminen]

If the default Mantis workflow and the used terms cause confusion, it's also quite possible to rename some of the default states.

We use Mantis at work and had to make similar customizations to make it fit our workflow better...

[Footkerchief]

Considering how many people are posting and PMing me about this, renaming seems like a good idea, although it doesn't look like the code will make that particularly clean.  Does anyone have a good word in mind?

[h3lblad3]

Well if it's for duplicates, why not just "duplicate"?

Or perhaps "noted"?

[Footkerchief]

It's not just for duplicates -- about 1/4 of the ones I handle get marked "no change required."  Mantis has a separate "resolution" field to tell you why it's been moved to that state.

"Noted" definitely doesn't work.  It tells you nothing, and the Mantis comments are already called notes.

[Felblood]

I see. The diagram is quite helpful.

In my only previous project that used Mantis, our mantis server was down well over half the time, so I don't have a tremendous handle on the definitions it uses for it's terminology.

It still isn't very intuitive, but at least we can see where it's coming from. It's kind of strange that even in that diagram the QA Engineer checks the results and can send the ticket into Feedback, when it is resolved without action. It's as though the beta testers are supposed to keep testing the problems that haven't been fixed.

I suppose to really follow this diagram, you'd want mods to tag the issues that actually need to be addressed as acknowledged and then have Toady tag them as assigned when he takes them on, but that seems like it would be a lot of hassle, for Toady. I suppose if Toady just grabbed a large number of orange tickets off the list that caught his interest, it wouldn't be very different from the list thread, except with bugs instead of features.

Whatever works for Bay12 is fine. This is primarily a way to communicate bugs to Toady, and doesn't need to serve as a two way communication system, except to facilitate that function.

EDIT:

Hey, Footkerchief, your link up there is broken.

Mantis give me an "Access Denied," even when I'm logged in.

[Footkerchief]

Hey, Footkerchief, your link up there is broken.

Mantis give me an "Access Denied," even when I'm logged in.

Oh, weird, I didn't know that ticket was marked private.  Should work now (not that it really has additional info or anything).

[Stormcrow]

Unless I'm:

A) Reading that diagram wrong or

B) Misunderstanding the response

(And if so, please disregard)

By the book, duplicate issues should be marked closed. By leaving them resolved, they are not really finished. Resolved bugs need QA so they can either be sent to 'feedback' if they're not really fixed to satisfaction, or sent to 'closed' where they can rest. Bugs marked duplicate are set to 'resolved' so someone can make certain it's really a duplicate, and then promote it to 'closed' where it can rest.

That last step's not happening, is all.

[Felblood]

I think you're right, Stormcrow.

Unless, there is actually something that needs to be review/tested by the testers, Footkerchief might as well close those duplicate tickets right after he resolves them.

It might save him some work if a couple of regulars were empowered to change the status of resolved tickets to closed/feedback, after they were tested/reviewed. If they wanted to be really regimented, Footkerchief could even assign the tickets to reviewers when he resolved them, so that they were automatically listed in their "Main" and "MyView" pages.

[Footkerchief]

Bugs marked duplicate are set to 'resolved' so someone can make certain it's really a duplicate, and then promote it to 'closed' where it can rest.

That last step's not happening, is all.

It's not happening presumably because Toady's still swamped.  He's barely had time to fix bugs, let alone do managerial stuff, so the current state, with hundreds of bugs languishing in "resolved," shouldn't be considered normal or permanent.  Once the post-release hubbub dies down, this should become a mostly moot point.  I'll switch to closing the duplicates directly if Toady decides that's a better approach (I definitely see the argument for it), but I'm not inclined to raise the issue with him while he's this busy.

[huhu]

The current system felt unintuitive enough that I had to dig up this discussion. I can't imagine any other solution to all issues than marking duplicate bugs as closed after being reviewed by a moderator. That would satisfy two of the critical issues at hand: a) Users browsing the bug tracker, facing the mass of 'resolved' bugs and b) Toady needing to review and reaffirm every duplicate bug before closing them (the lack of time argument).

Any fundamental problems with this new approach would be dug up by the power of the people (the reporters), most likely in the form of prolonged discussion and arguments in the closed bugs' notes - Or alternatively as some certain bug being reported over and over even after they are all marked as duplicates and closed. That would only take place if there was a visible error in judgement. If the goal of the Mantis was something else, then perhaps the report bug page should receive some kind of introspection paragraph with more detailed directions for the would-be reporters.

[profit]

I just would like to say I found it really screwy as well, but if it works for toady don't change a thing!

The bug tracker is for his work, if he likes it the way it is and it helps him work, it doesn't matter what it says... Or how we feel about it...