**aklapper** wrote on `2014-07-15 17:09:46 (UTC)`

**Generally speaking:** It's all about "keep it simple and stupid" vs "I want to categorize everything" and finding a good compromise. Before commenting, everybody should question themselves whether they do care a lot about expressing a reason //via task status// and if they really query for tickets and differentiate on that status, or if they can also survive having the reason in a project workboard column or comment only which is harder to search for.

Regarding the proposal to **set projects in addition to the "Declined" status**, I've in the meantime gotten afraid that people won't do that. I cannot exactly prove it and the quote refers to fixed issues, but: "Of course, the developer could change the issue category after resolution---but this happens rarely. In many cases there exists no real motivation to change the issue category once the cause for a problem is found and fixed." from http://www.st.cs.uni-saarland.de/softevo/bugclassify/paper/icse2013-bugclassify.pdf page 396.

**A status called "Invalid":** There are opinions in Mozilla ( http://eaves.ca/2011/07/27/lessons-for-open-source-communities-an-example-for-bug-tracking-more-efficient/ and https://bugzilla.mozilla.org/show_bug.cgi?id=592533 ) that average users who incorrectly filed a support request (configuration, on-wiki gadget issues) as a task/bug report and who are not used to dev workflows/terms, that "invalid" can feel derogative, but I really cannot come up with a better term after looking at other issue trackers and their terms, so I naively call it "Invalid here" instead of "Invalid".

I am probably less afraid of **cluttering the status field** if people //really// want to differentiate reasons for closing. The ~dozen of Bugzillas I sometimes interact with have 5-9 statuses and 6-13 resolutions. Combining that in one field in Phab, I think we're not too bad if we ended up with 7 or 8 task statuses.

**Summary:**
* Needs Triage
* Open
* Needs Info
* Resolved
* Invalid Here (resembling "Invalid", "Nothing for a Phab task", "Spam", "Support request", "On-Wiki issue", "Upstream it", "Works as intended" etc.)
* Declined (resembling "Wontfix", "Out of scope", "Actively against fixing this", "Overcome by events" etc.)
* Unreproducible (resembling "Works for me", "Insufficient data", "Feedback Timeout", "Your computer got hacked by an interwebs virus that displays ads on Wikipedia" etc.)
and
* "Verified" as an optional workboard column per $project if $project wants it.