linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

Hello again

the change described in this RFC is now in place regarding the statuses.
What this means: if you are searching for cards which are delivered or
deferred please adjust your filters to search for status Closed and
resolution Delivered or Deferred depending what you want to find. For the
resolution part I have just added 1 resolution (Cancelled), but have
decided to not mess with the existing values, as that would affect the
history of the existing data.

I have also updated the documentation in
https://wiki.linaro.org/OPSCOM/RoadmapProcessWithJIRA

Let me know if you have any further questions about this change.

BR,
Ilias

--
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 22 May 2013 13:02, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:

> 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
>>
>
>