FYI
---------- Forwarded message ---------- From: David Rusling <[email protected]> Date: Tue, Jul 5, 2011 at 9:47 AM Subject: Fwd: Linaro Requirements To: Joey Stanford <[email protected]> Cc: Christian Robottom Reis <[email protected]> checklist... Begin forwarded message: From: Roger Teague <[email protected]> Date: 24 May 2011 16:34:16 GMT+01:00 To: Andrea GALLO <[email protected]>, David Rusling <[email protected]>, Vandervennet Yves-R55763 <[email protected]> Cc: TSC <[email protected]>, Victoria Janicki <[email protected]> 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:[email protected]] 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:[email protected]] 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:[email protected]] > 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. _______________________________________________ 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
