linaro-project-management team mailing list archive

[Joey Stanford <joey@xxxxxxxxxx>]

FYI


---------- Forwarded message ----------
From: David Rusling <david.rusling@xxxxxxxxxx>
Date: Tue, Jul 5, 2011 at 9:47 AM
Subject: Fwd: Linaro Requirements
To: Joey Stanford <joey@xxxxxxxxxx>
Cc: Christian Robottom Reis <kiko@xxxxxxxxxx>


checklist...

Begin forwarded message:

From: Roger Teague <Roger.Teague@xxxxxxx>
Date: 24 May 2011 16:34:16 GMT+01:00
To: Andrea GALLO <andrea.gallo@xxxxxxxxxxxxxx>, David Rusling
<david.rusling@xxxxxxxxxx>, Vandervennet Yves-R55763
<r55763@xxxxxxxxxxxxx>
Cc: TSC <tsc@xxxxxxxxxx>, Victoria Janicki <vicky.janicki@xxxxxxxxxx>
Subject: RE: Linaro Requirements

Just spotted this email trail so I'm afraid my comments are even
later..  Apologies for this.

My feeling is that before we agree on a set of requirements for any
tool we should have an agreed process for submission, management and
reporting.  This in itself will lead to a set of requirements satisfy
that process.

Some more direct feedback…

1.  Any SW tool used should provide us with an Audit mechanism so that
we can track back thru the history of a requirement.
For example:
a) Where a requirement is subsequently split more than one requirement
b) Where a requirement is marked as a duplicate
c) where a requirement is combined/merged with another
c) Identify the originator and who makes changes (and what changes)
d) Ability to mark for a specific cycle and any changes
e) Tag to a specific Blueprint or whatever we deem the next level

2.  For each company there should be a “sandbox” where we can
gather/prioritise/refine requirements prior to submission into Linaro
– the idea here is that each company can refine their inputs for a
specific Cycle, iteration or… and cleanly submit once which I hope
would stop a lot of churn.  It also means we can have “open house”
internal to our organisations on who can submit but when it comes to
committal into Linaro we can do this via either the TSC member or the
companies elected member. Anyone in a TSC members organisation should
have read access.

3.  Somewhere we need to capture effort against a requirement – e.g.,
how long Linaro Eng. thinks its gonna take so that we can help
consider it’s priority and status.  This will help with a lot of the
discussions we’ had this time on whether we can/cannot do something in
a Working Group.

4.  We should be able to filter on requirements to enable us to
generate reports specific to our organisation.  For example, it would
be great to see how many requirements for this cycle we attribute to
our Android strategy and the effort we are allocating.  It will help
us in the TSC be subjective about “have we made the right call” on
priorities.  Now I’m not thinking anything fancy here just the basics
that are needed to say “ for GCC tools consolidation we’re expending
15% of the available effort for this cycle”.

5.  Once a requirement has been satisfied we should be able to work
thru what we did to close it off (e.g., we mentioned a test plan etc
in Budapest) so perhaps the ability to link to test case in a test
plan and it’s result.

HTH

Roger

-----Original Message-----
From: Andrea GALLO [mailto:andrea.gallo@xxxxxxxxxxxxxx]
Sent: 23 May 2011 21:08
To: David Rusling; Vandervennet Yves-R55763
Cc: TSC; Victoria Janicki
Subject: RE: Linaro Requirements

Then I am even later as I have just read all emails now :-(

Anyway, excellent!

I look forward to playing with the e-postit tool that Kiko
demonstrated at LDS :-)

Andrea

PS: all that noise from Germany benefit trips to Budapest is raising
jokes from my colleagues about our own summit in Budapest...

-----Original Message-----
From: David Rusling [mailto:david.rusling@xxxxxxxxxx]
Sent: Thursday, May 19, 2011 4:06 PM
To: Vandervennet Yves-R55763
Cc: TSC; Victoria Janicki
Subject: Re: Linaro Requirements

Thanks Yves.   For the rest of you - the deadline was yesterday...

Dave

On 18 May 2011, at 19:01, Vandervennet Yves-R55763 wrote:

> David,
>
>     Thanks for putting this list together! My comments are below
>
> Thanks,
> Yves
>
> -----Original Message-----
> From: David Rusling [mailto:david.rusling@xxxxxxxxxx]
> Sent: Tuesday, May 17, 2011 7:28 AM
> To: TSC
> Cc: Victoria Janicki
> Subject: Linaro Requirements
>
> All,
>     these are my thoughts so far.   Deadline is tomorrow.
> Dave
>
> REQUIREMENTS
>
> [1] Interface
>     The ability to easily edit them via a web interface and offline
>           Any tools should be OS / platform neutral, must work from {Linux, Mac OS, Windows, IOS, Android}
> [[YV]] If it's a web interface, then I would specify that any browser must be supported.
>           Needs to be light and fast
> [[YV]] ! yes !
>           Restricting the editors might be useful (as part of controlling change)
>     Order by any field
> [[YV]] one field must the version number of the requirement
>     Group by implementation team (for example, Kernel WG), but needs to cope with multiple teams (for example, SMP, device tree)
>     Print reports / summaries (or generate PDF)
> [2] Requirement description
>     Description (can include pictures, text etc).   Might need a mechanism for signing off a 'good' description (as opposed to slide ware)
>     Links to associated documents {blueprints, web sites, attached PDFs slides etc}
> [3] Status and Tracking
>     Who raised this requirement (owner, sponsor) {set of names}
>     Priority {high, medium, low}
>     Edit history
>           Discussed at meeting X, decided Y
>           Person A modified information B
>           Reviewed by
>     Actions (set of next things to be done to this requirement or set of requirements, with owner(s) and date(s))
> [4] Operational
>     Size {big, medium, small}
>     state {queued, in progress, deferred, dead}
>     List of work packages associated without this
>           Rolled up status (73% complete)
> [[YV]] Not sure about this. Isn't that provided by status.linaro.org?
>     Deadline for completion
> [[YV]] Then the different leaders must update this as well.
>
> COMMENTS
>
> [1] I think that we should use this only for the high level requirements (and leave the rest of the (blueprint based) work flow alone as that seems to be working).
> [[YV]] How are we going to link the requirements (high level <-> blueprints)?
> DO we want the validation team to use this as well?
>
> STORIES
>
> [1] I want to be able to chair meetings and work through the a set or subset of high level requirements discussing and modifying them as the meeting progresses
> [2] I want to be able to track actions from a particular meeting or a set of meetings so that I can ensure that they're owned and done
>


-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.