linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

Hi folks

it seems that largely there is agreement to move on with this change.
However I should point out that doing this change will also mean moving old
cards from states like Delivered/Deferred to Closed with corresponding
resolutions Done/Deferred. One annoying side effect is that JIRA will
re-record the resolution date, which will affect historical data.

I am checking on how to avoid this so it should explain why the move has
not yet been effected.

Bear with me.


--
Ilias Biris - ilias.biris@xxxxxxxxxx
Technical Program Manager, Linaro
M: +358504839608, IRC: ibiris, Skype: ilias_biris
Linaro.org | Open source software for ARM SoCs


On 13 May 2013 20:24, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:

> Hello techleads/opscom
>
> This is an RFC with regards to the handling of the delivered/deferred
> state for Roadmap Cards. In particular for Deferred it has been used to
> indicate actual cancellations (cards which will not need reopening) as well
> as deferrals (cards which should be reopened and taken back to teams after
> a point in time).
>
> == The Changes ==
> I would propose the following changes to improve a bit our roadmap
> workflow:
>
>  1. Merge Delivered and Deferred states to 1 state called "Closed".
>
> 2. Use the RESOLUTION field of a card to indicate how the card was
> resolved. The proposed resolution values are:
>
> * DONE: code is completed, tested and upstreamed (where applicable)
>
> * Won't deliver: the work will not be done for whatever reason (comment
> with explanation is needed)
>
> * Incomplete (the card is incomplete and therefore needs to be drafted
> again if it is supposed to be taken further)
>
> * Duplicate (card is a duplicate of another card)
>
> *Cancelled (work is cancelled - eg the sponsor does not want the feature
> or the feature became irrelevant - comment is needed)
>
> * Deferred (card is deferred for later)
>
> So my proposal is to associate:
>
> * Delivered with: status Closed and resolution DONE
> * Cancelled with:
> - status Closed and resolution Cancelled if the sponsor cancelled the
> feature OR
> - with status Closed and resolution Won'd Deliver if there is some other
> reason for which the card cannot be delivered
> - with status Closed and resolution Duplicate if the card is a duplicate
> of an existing card
> - with status Closed and resolution Incomplete if the card is rejected as
> Incomplete description
>
> * Deferred with:
> - status Closed and resolution Deferred - giving the reason for deferral
>
> 3. JIRA allows the workflow transitions to automatically set/clear the
> resolution field as needed. As such, the transitions to Closed would set
> the Resolution field in order to determine what sort of resolution was
> achieved.  So,
>
> * When pressing "approve deliverables" in Closing review state: the
> resolution will be marked DONE automatically (as is today). There is no
> need to edit a resolution.
>
> * The transition which was previously known as "Defer card" will need to
> be split to allow "cancelling" as well as "deferring" a card. That would
> allow choosing the resolution, whilst the status of the card would
> automatically become "Closed".  When deferring the resolution would be
> automatically set to "Deferred" whereas when cancelling it would be
> possible to set the resolution.
>
> 4. Also each transition can be accompanied by a transition screen where
> card data can be added. I can define special transition screens for
> delivering, cancelling/deferring a card. Today we use only 1 screen across
> all transitions.  The special screens would be simpler than the default we
> use today, only allowing to edit eng progress update, fixVersion,
> description (to update the close-out section), resolution (where needed to
> set manually) and comment (comes by default from JIRA).
>
> So overall I think we can use this proposal to simplify the workflow a bit.
>
>
> == The Impact ==
> How will this change impact usual JIRA operations:
> - searches for delivered/deferred cards would need to be adjusted to
> search for status AND resolution.
> - Views for the structure plugin would need to be adapted to allow showing
> the status AND resolution
> - Negative impact: rapidboards show cards based on their status only. So a
> Closed lane would contain Delivered and Deferred/Cancelled cards. What can
> be done for this issue is to either
>
> * exclude the deferred/cancelled cards via the filter used to create those
> rapidboards OR
> * rapidboards facilitate painting cards with different colours based on
> some criteria: it would then be possible to mark the cards which are
> deferred/closed as eg Gray, vs Green for the cards which are Done.
>
> Also, obviously, I would need to change existing delivered/deferred cards
> to become "closed" with the corresponding resolution values (Done, and
> Deferred).
>
> Your feedback and questions are welcome. FYI this has run through project
> managers and was seen as a positive update. If I do not see any objections
> till Friday 17 May I will implement this proposal on cards.l.o.
>
> Best regards,
>
> --
> Ilias Biris - ilias.biris@xxxxxxxxxx
> Technical Program Manager, Linaro
> M: +358504839608, IRC: ibiris, Skype: ilias_biris
> Linaro.org | Open source software for ARM SoCs
>