[trac] remove assigned state but keep assigning feature

[philll]

Background

Trac's "assigned" state is just redundant information to the actual assignee and there is no need to explicitly have a step in the process being named "assigned" apart from knowing that somebody is on it.

What to change

In the adblock plus issue tracker, remove assigned state but keep assigning feature. Ensure all issues currently in the assigned state are being set to some reasonable other state upfront, as it wont be possible afterwards.

[fhd]

This is supposed to fix #320, but I'm not fully convinced.

1. While having an "assigned" state is arguably redundant, it makes it easier to see at a glance that something is being worked on. Assuming this doesn't need to be kept in sync manually.
2. It seems to me like the underlying problem persists: We cannot move between states arbitrarily. What if you accidentally set something to "reviewing" and want to go back to "new"? Won't work either. I really believe people should always be able to undo things they do.

[philll]

1. It will not fix #320, but make it obsolete, as there will be no assigned state left. As the default queries give you the assignee column either way, I regard that information as obvious enough.
2. Well, I did not really adress that problem, as I wasn't aware of it so far. Technically, it's easy to allow every state from every other but logically that workarounds the enforcing workflow concept. Although it might be quite arguable, whether it is possible to enforce anything at all, as there are always ways around, if one really wants to. If you think, we should allow that, please file a seperate issue for it.

[trev]

Yes, #320 is an issue I mentioned as well in this context - properly unassigning an issue is currently impossible. A more common issue however is that somebody changes to codereview state and forgets assigning - fixing this state currently takes two status changes (back to assigned and the codereview again). Finally, I occasionally set assignee already when creating the issue - and then I have an issue in the "new" state which should really be "assigned".

The way we assign issues the "assigned" state indeed is redundant, in our case anything having an assignee is assigned. And the assignee is displayed by default in every query so I don't see a real issue here either.

[trev]

For reference: ​https://hg.adblockplus.org/infrastructure/rev/a02f637637fa

[fhd]

1. I agree, it's probably obvious enough that something is taken care of if it's assigned to someone. What we had before was redundant and a bit confusing.

2. We don't need arbitrary state changes per se, all I want is that people can undo things. So why only allow them to move forward in the states? Why not backwards? (e.g. from codereview back to new.)