[hyades-dev] Requirements process - important

[Michael.Norman@xxxxxxxxxxxxx]

Everyone,

We are seeking to ensure that we have in place all new enhancement 
requests for a review cycle next week. To be included in version 3.3, 
enhancements will have to be posted by friday 12th.  Any substantive or 
API-breaking 4.0 enhancement requests should also be posted by friday 
12th.  It would be extremely useful to the process if you could ensure 
that small-grained enhancements are bundled together into larger 
requests or attached to other requests, with the permisson of the 
originator. Enhancement requests shoudl be accompanied by documentation 
to allow the group to understand their significance. Documentation is 
also required later in the process when Architectural and Planning 
considerations come into play, and it is probably best to provide as 
much as possible of this at the outset.  Harm Sluiman will be posting 
round separately what he needs for his Architecture group, which will 
scope out the requirement before it is passed to Planning.

Enhancement requests are reviewed by the requirements group on whihc all 
participating organizations have representatives, and it will help the 
group review priorities correctly if these individuals are up to speed 
on the requirements at the meeting.  As the chair of that meeting I will 
take the responsibility of represening those enhancemetn requests which 
are submitted by non-represented organizations or by individuals, and 
will be pleased to receive input in support of those requests.

I think it is fair to say that the Bugzilla technology is not yet 
well-supporting our new process, but I propose we work in the following 
way.

1) BRAND NEW enhancements 
please post enhancement requests into bugzilla along with an indication 
of when you require this to happen in the form of a target release.  
Release dates are on the web site.  Please be specific about the timing 
of a requirement - "future" and "--" are both allowed, but since neither 
of them is associated with a release, they are both pretty-much 
equivalent to "never".  Priorities are interpreted as follows P1 "I need 
this at this release or my product/project/whatever isn't going to 
happen". P2 means "I'd really like this at this release but I can if 
necessary live without it". P3 means "I'd like this".  I think it is 
fair to say that resources are still very short in this project and 
requiremens and only high priority requiremtns will actually get built, 
and you will need to strongly argue your requirements to get a high 
priority.

2) RECENT enhancements
As of today enhancement requests 50766 53760 53760 58359 64800 69285 
71057 73868 75026 75028 75523 75524	75609 and all those with ID's 
greater than 75782 have not been reviewed by the requirements process.  
These will be reviewed next week. If you want to amend the priorities or 
release of these requirements please do so in Bugzilla

3) REVIEWED enhancements
Enhnancement requests up to 75782 (with the exception of those mentioned 
above) have been reviewed and priorities/target releases amended.  These 
are being psased immediately into the architectural/planning reviews. 
The changes that were set by the requirements process will be reflected 
back into bugzilla, overwriting the values currently set there. Harm 
Sluiman is physically doing this and will email hyades-dev and post the 
newsgroups when it is completed. PLEASE do not amend the values set by 
this process in bugzilla.  If you wish to "appeal" the release/priority 
that has been set please email me directly and these requests will be 
handled as exceptions. 

I hope this makes sense.

Mike Norman
TPTP requirements group chair