RE: [hyades-dev] TPTP and Hyades enhancement/feature requests

[Michael.Norman@xxxxxxxxxxxxx]

It's probably worth amplifying the Requirements side of this a little at 
this stage.
 
Every 6 weeks the requirements group will take as input the bugzilla 
enhancements list (if its not in there it won't be considered) and any 
supporting documentation in CVS (if the people on the requirements group 
don't understand the requirement it is unlikely to get significant 
priority). The requirements list to which we are actually working is 
then no longer generated automatically from CVS, the requirements group 
processes the CVS & bugzilla documentation, reviewing priorities, target 
releases and also allocating the subproject within which it is to be 
worked.  Priorities will be set around Themes which will be defined as 
part of the overall process of defineing themes for Eclipse Releases. 
The Requirements Group has a link up to the Eclipse Requirements Council 
to help set the Themes and if there is somehing required from another 
project we can handle it there too. There will then be a process whereby 
the priorities etc set by the requirements group also propagate back 
into Bugzilla to keep it up to date. The planning group then takes this 
as input and decides what actually goes into plan dependent upon 
available resource.  
 
This afternoon we got a certain distance down the process of 
prioritizing ehnancement requests, but the process will continue later 
on in the week.  As far as Version 3.2 is concerned, the new process is 
operating almost as a shadow.  We are not removing things that have been 
assigned to the 3.2 release, we may assign new things to the release 
and/or increase priorities but since there is a requirement for resource 
to be allocated to them by the Planning Group, which won't meet until we 
are done, impact to 3.2 deliverables, if any, is likely to be restricted 
 to small additions to 3.2 i2. However for post-3.2 consumers' 
requirements it is now an effective option to post the requirement 
yourself (rather than through a Committer) and then drive through your 
company representation on the Requirements and Planning group.  If your 
company isn't represented I will endeavour to represent  the requirement 
for you.
 
Mike
 

[Michael Norman]  -----Original Message-----
From: sluiman [mailto:sluiman@xxxxxxxxxx]
Sent: 30 September 2004 22:34
To: hyades-dev
Subject: [hyades-dev] TPTP and Hyades enhancement/feature requests




As most of you know we have been in transition Hyades into the TPTP 
project, and at the same time we have been introducing process change, 
as well as continuing to deliver new releases. 

All enhancements are being tracked in bugzilla and any post 3.2 features 
will need to go through the new TPTP process, which involves a 
requirements review  by the requirements group as well as a plan 
approval by the planning group in order to assess resource allocation. 

More information will follow regarding how to go about bringing an 
enhancement forward, and that will apply to all post 3.2 enhancements. 
Only after the above reviews and approvals will they be considered in 
plan. All enhancements approved by the requirements group will be listed 
on the plan features table currently shown in the draft documents 
section of the web site. This document will show the request bugzilla 
number, a link to a decryption document, as well as what priority and 
release the request is for. Once approved by the planning group it will 
be marked as "in plan". Any changes to the document has to go through 
the approval process. Mike Norman will formally own the requirements 
list, and Tyler Thessin will formally own the plan approval. 

To facilitate the transition from the current to the new process the 
plan document is already populated with most of the known requests. Even 
more appear in CVS. As of the end of this week, all 3.2 requests listed 
in the table are considered approved by all groups and "in plan". In 
order to move any of those 3.2 requests to a different state requires 
approval. This means we are committed externally to deliver these 
features on schedule for 3.2 in December 2004. 

To further facilitate this transition we need to create a baseline of 
information in CVS as well. The plan document will not get updated 
because of a change in CVS. In fact the enhancement in CVS needs to be 
updated to follow state change in the document. This means that by the 
end of this week we need to mark all 3.2 requests in the document with 
the correct priority (P1 or P2) and ensure all others are temporarily 
targeted to something else. You are also asked to update CVS to reflect 
the request state from the table. 3.2 request in CVS and the document 
are our baseline. 

In addition all rows in the document need to have a link to a valid and 
complete description document, before it will be considered by the 
requirements group. This is a requirement for all the 3.2 approved 
requests as well. 

The first requirements review will take place very early next week and 
hosted by Mike Norman. The person representing the requesting consumer 
needs to be able to speak to the request in enough detail to drive a 
target release and priority. By the time the requirement moves to the 
planning group for review it will need a rough sizing so resource can be 
balanced across the releases. 

On the Monday commiter call the 3.2 requests will be reviewed for 
accuracy and commitment and after that all 3.2 change will need to go 
through the new processes. 

So we really need you to work with the current commiter leads (Richard, 
Kent, Joe, Eugene, Antony, Nellie) to get the table and bugzilla updated 
asap, complete with description documents for 3.2 and any enhancements 
you want considered in the requirements review. 

Thanks for your time and continued support. 

Tyler Thessin and Harm Sluiman