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 - [email protected] 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 <[email protected]> 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 - [email protected] > Technical Program Manager, Linaro > M: +358504839608, IRC: ibiris, Skype: ilias_biris > Linaro.org | Open source software for ARM SoCs >
_______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
