**jdforrester** wrote on `2014-05-30 16:13:58 (UTC)`

>>! In T359#8, @greg wrote:
> My suggestion for day 1:
> * Open
> * Not a bug (instead of "invalid")
> * Incomplete (or Needs more info)
> * Fixed
> 
> I don't find "works for me" useful. If anything, it should be called "works, period" aka "not a bug". The "for me" part bothers me.

I agree that it's a bit sucky; normally it's used for

1. "this is a fault you're experiencing due to something else not in our control",
* "this may be a fault, but you've given insufficient information to reproduce", or occasionally
* "this was fixed since it was filed but I don't know exactly how so, so I'm not going to mark as FIXED"

… so use case (2) is no longer needed if we add "INCOMPLETE" or "NEEDSINFO" or whatever, and case (1) //could// be marked as "NOTABUG"/"INVALID"; for case (3) we could just be more lax about marking things as FIXED even when we don't know for sure that they are.


> I also find "won't fix" not useful. If it's not a bug, mark it as such. If it's way low priority, set the priority as such. Since we can have multiple projects in use by a team to track sprints and such, the product owner argument of "I want a clean backlog" doesn't apply.

I strongly disagree, and I think the term "bug" rather than "task" skews this.

There are totally "valid" requests for new features or feature enhancements which are incompatible with the direction that we want to take a product (//e.g.// "Change the FOSS policy for Tool Labs so I can run Windows on it" or "Let me upload MPEG files to Commons" or "I want to have a button in VisualEditor to block the last editor if there are spelling mistakes"). "Lowest" priority for these is totally wrong – these are "No, we will not do this ever, and we will work to stop other people doing this if they try".


> Boy do I wish we could have separate statuses per project per task (eg: Fixed in master but open in 1.23.0)

Yeah, deployment/release statuses would be a lovely nice-to-have, but maybe for post-initial-switch?