linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

Hello again

Final call for feedback. Otherwise changes will be applied by Friday 28 Sep.

I have received very few comments on this RFC, none negative. So I will
make the switch to the new simplified process by Friday 28 Sep. What
this means for TLs and PMs is:

1. Cards in Toolchain, Infrastructure and Kernel - shown in the URL
filter below - will be moved to Engineering, they are now Accepted.
Please make sure to mark any of them as blocked if they should be marked so.

http://cards.linaro.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CARD+AND+status+%3D+Accepted

2. The following Android card will be moved from Incomplete to Deferred.

http://cards.linaro.org/browse/CARD-146

If you have any objection or worry please let me know. I can help you
mark any card as blocked if you need my help.

Once the change is made in JIRA I will also make sure that documentation
is updated with the new process diagram (updated with the cosmetic
comments I got from some).

Best regards,
Ilias

On 29/08/12 12:26, Ilias Biris wrote:
> Howdy folks!
> 
> Our current roadmap process in JIRA can be visualised via
> 
> https://wiki.linaro.org/OPSCOM/RoadmapProcessWithJIRA#JIRA_Workflow_transitions_diagram
> 
> I would like to change it to look like the attached flow diagram. The
> main changes are outlined by the following list
> 
> 1. Removal of the INCOMPLETE state. IMHO it is not a very useful state,
> based on the interactions with the teams for 2 quarter cycles so far.
> Usually the decisions towards handling incomplete work are taken at
> closing-out review stage, rather than marking cards incomplete for later
> inspection/decision.
> 
> 2. Removal of the ACCEPTED state: also not a very useful state. It was
> meant to indicate cards which are accepted at TSC level but which have
> not been blueprinted yet. In practice work usually starts as soon as a
> card gets accepted, but the card state remains unchanged. Blueprinting
> is effectively part of the engineering. In that aspect, and since we
> followup at OPSCOM, makes the Engineering state sufficient.
> 
> 3. A minor addition to Change-Review outgoing transitions: it should be
> possible to move a card back to drafting if the requested changes
> warrant this move.
> 
> 4. A final suggestion - not reflected in the flow diagram. Reviews
> (blocks painted orange: Reviewing, Change Review, Closing out) should
> take at  most 2 weeks to complete from the moment a card has been moved
> to a review state - unless there is a commented decision to wait for
> some specific event. OPSCOM bears the responsibility here to keep track
> of the reviewed cards and probe for feedback eg from the TSC.
> 
> Comments, ideas, questions - all are welcome.
> 
> Best regards,
> 


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