linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

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