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
