Merge lp://qastaging/~jamiebennett/launchpad-work-items-tracker/add-later-support into lp://qastaging/launchpad-work-items-tracker

To be honest, the purpose of this new state isn't very clear to me. We already have "POSTPONED" and "DROPPED", and adding a third similar one "LATER" won't help to ease the semantics. "POSTPONED" and "LATER" have a very similar denotation, and the way you describe it, "LATER" is already available as "DROPPED", no?

On 13 Sep 2010, at 07:56, Martin Pitt wrote:

> Review: Needs Information
> To be honest, the purpose of this new state isn't very clear to me. We already have "POSTPONED" and "DROPPED", and adding a third similar one "LATER" won't help to ease the semantics. "POSTPONED" and "LATER" have a very similar denotation, and the way you describe it, "LATER" is already available as "DROPPED", no?

LATER helps to fix bug 509806, i.e. postponing items to a later milestone. The LATER status just allows the same work item to be in two different milestones with the LATER one not being counted. This allows one to determine how many items didn't actually make their milestone and also means that you do not have to shuffle work items around every time you miss a milestone.

Shouldn't we rather fix the double counting then, by making (description, spec) a primary key of work_items?

On 13 Sep 2010, at 12:11, Martin Pitt wrote:

> Shouldn't we rather fix the double counting then, by making (description, spec) a primary key of work_items?

The LATER status was implemented so it would be trivial to pull out all LATER items to determine a 'predictability of delivery figure' and also find out what is slipping. Of course this could be done in other ways, adding the LATER status seemed to be the lowest impact (you don't have to use the LATER status) and most benefit.

I still think that POSTPONED/DEFERRED would serve the exact same purpose. If a later milestone sets the same WI to "DONE", then it would override the postponed state, so the DB would always be correct?

On 13 Sep 2010, at 12:32, Martin Pitt wrote:

> I still think that POSTPONED/DEFERRED would serve the exact same purpose. If a later milestone sets the same WI to "DONE", then it would override the postponed state, so the DB would always be correct?

My idea was:

POSTPONED = Item will not be done this cycle but will be revisited for next cycle
LATER = Item was not completed this milestone and has been moved to another milestone, still to be completed this cycle

The idea is to track these slipped items as well as determine what needs revisiting for next cycle. Also to stop the merry-go-round of moving items at each milestone. As long as this is possible with a unique key in the database I'm happy either way. Having the two distinct status' with the explanation above seemed the most obvious way of doing from me though.

So what you define as "LATER" has been the original intention of the "POSTPONED" state. Your "POSTPONED" state already exists as "DROPPED", which more clearly describes the meaning. So instead of keeping piling up states like "postponed", "deferred", "later", "moved", "nudged", etc. (which do not have a clear and intuitive semantics), can we just keep DROPPED and POSTPONED?

For this, we just need to provide a real implementation of DROPPED instead of just aliasing it as POSTPONED.

On 13 Sep 2010, at 13:21, Martin Pitt wrote:

> So what you define as "LATER" has been the original intention of the "POSTPONED" state. Your "POSTPONED" state already exists as "DROPPED", which more clearly describes the meaning. So instead of keeping piling up states like "postponed", "deferred", "later", "moved", "nudged", etc. (which do not have a clear and intuitive semantics), can we just keep DROPPED and POSTPONED?
>
> For this, we just need to provide a real implementation of DROPPED instead of just aliasing it as POSTPONED.

Right and of course fix POSTPONED to allow multiple entries for the same work item. My only concern with doing that was the impact of changing POSTPONED's behaviour for everyone.

Updating status to improve the "active code reviews" status page. This should be done by fixing the "postponed" state.