I would like "Fixed in version", and that would be easy to add. Have an additional "Planned for version" would be useful for tracking how well you're following your plan.

This seems to have been fixed. Thanks!

Woohoo!

Really, just remembering how the bug list was filtered would be the best I think.

> But FYI - we're working on this next after the API is released next week.

Awesome on both counts!

> One question: why aren't you using "Resolved" as "Ready for QA"?

That's an option we've played with. The trick is that there also needs to be a "Ready to Deploy/Passed QA" status.

When I am done implementing a feature/fixing a bug, but haven't deployed it to the staging server yet, I might mark it as Resolved and leave it as assigned to myself. Then when I deploy it to staging, I leave it as Resolved and make it unassigned. Then the next available QA person will take it and test it.

However, what happens when QA passes my fix? They can't deploy it. So, they mark it as Resolved and assign it back to me.

Thus, the same combination of status and assignment can mean two different things. That's what we're trying to deal with at the moment.

I agree, it'd be nice to assign a bug to, e.g., the QA group to check that it is fixed. Then, whoever is available will take it.

> I think no one should need to customize the current statuses that we have

Well, that's the thing. This software is being used for a variety of purposes across multiple countries. Let me give you an example.

I am developing software for internal use. QA is provided informally by my colleagues (which is why I'm using a free application...) I'm not doing CI because I'm the only developer. So, each fix is deployed independently.

For my own benefit, I'd like to be able to mark a bug as "Implemented". Then, when I deploy it for QA, I'd like to mark it as "Ready for QA" or something. (We're using Feedback for now.) Then, when it's been QA'd, the colleague doing it can mark it as "Resolved". However, if QA finds a problem, they should mark it as... well, something. Feedback would be good, but we're using that as "Ready for QA". Finally, when it's deployed to Production, I can mark it as "Closed".

I really have no need to have both "Confirmed" and "Acknowledged". To me, these are redundant. In fact, I don't even use them at all. I would be happy to change the labels on these and use them for something else.

As you can see, the existing statuses work pretty well, but they're not quite right. If the exact wording didn't matter, then they could just be labeled Status 1, Status 2, and so forth. Connotations matter.

Thanks again for making this very useful tool available for free, and for listening closely to your users!

Sounds good. We currently have a global setting, all we need now is the project override. 

Also "Can't/Won't Fix".

I concur that non-image files are not typically going to be used for screenshots.  Imagine, e.g., a spreadsheet with a list of various inputs and their outputs.  Implementing that directly in DB would be a major project of questionable value; allowing upload of spreadsheets would address it quickly.

It's definitely annoying to have to download an attachment every time, but sometimes it's unavoidable, and it can be very useful.

All that said, thanks so much for this free application and for listening to your users!  I picked Damn Bugs because it's in the sweet spot between too simple and too complex, and I'm sure with all the thinking about features you guys are doing, it will stay there.