Difference between revisions of "Quarterly Review"
From Apache OpenOffice Wiki
(New page: = Draft: Quarterly reviews = For these reasons I suggest to do quarterly review meetings to identify the most important issues and enhancements and to establish a plan for their resolutio...) |
|||
| Line 3: | Line 3: | ||
For these reasons I suggest to do quarterly review meetings to identify the most important issues and enhancements and to establish a plan for their resolution. The outcome or agenda of those meetings may look like this: | For these reasons I suggest to do quarterly review meetings to identify the most important issues and enhancements and to establish a plan for their resolution. The outcome or agenda of those meetings may look like this: | ||
| − | + | # Status of the project | |
| − | + | ## what are the most severe issues in the current release | |
| − | + | ## which are the most requested (or needed) features (in the press, user forums, issues, other feedback) | |
| − | + | # short term planning | |
| − | + | ## which defect needs to go into the next release | |
| − | + | ## which features will be worked on for the half year. | |
| − | + | ## which issues needs an assignment | |
| − | + | # mid/long term planning | |
| − | + | ## which features/bugfixes needs to be addressed in the next two/three years | |
| − | + | ## unassigned feature/bugixes | |
| − | + | ||
| − | + | ||
The outcome of these items should be a prioritized list of issues, in case of not being able to assign the resources the escalation path should be look like this: | The outcome of these items should be a prioritized list of issues, in case of not being able to assign the resources the escalation path should be look like this: | ||
| − | 1. Project Lead of the project | + | 1. Project Lead of the project |
| − | 2. project_leads@openoffice.org | + | 2. project_leads@openoffice.org |
| − | 3. Engineering Steering Committee (ESC) | + | 3. Engineering Steering Committee (ESC) |
| − | 4. Community Council (CC) | + | 4. Community Council (CC) |
To come to a balanced assessment of issues there should be a least in those meetings: | To come to a balanced assessment of issues there should be a least in those meetings: | ||
| − | - project lead | + | - project lead |
| − | - qa lead | + | - qa lead |
| − | - member for release status meeting | + | - member for release status meeting |
| − | - reprentative for user base (user forum or user mailing list maintainer and/or a marketing rep) | + | - reprentative for user base (user forum or user mailing list maintainer and/or a marketing rep) |
| − | - if available: more developer and qa folks. | + | - if available: more developer and qa folks. |
I suggest to start with our main, visible projects like Writer, Calc, Impress and Base and see later if we need to involve also other projects in this effort. I would like to encourage these teams to organize those meetings within the first two weeks of the each quarter (next slot would be April 1-14th) | I suggest to start with our main, visible projects like Writer, Calc, Impress and Base and see later if we need to involve also other projects in this effort. I would like to encourage these teams to organize those meetings within the first two weeks of the each quarter (next slot would be April 1-14th) | ||
Revision as of 17:05, 10 March 2008
Draft: Quarterly reviews
For these reasons I suggest to do quarterly review meetings to identify the most important issues and enhancements and to establish a plan for their resolution. The outcome or agenda of those meetings may look like this:
- Status of the project
- what are the most severe issues in the current release
- which are the most requested (or needed) features (in the press, user forums, issues, other feedback)
- short term planning
- which defect needs to go into the next release
- which features will be worked on for the half year.
- which issues needs an assignment
- mid/long term planning
- which features/bugfixes needs to be addressed in the next two/three years
- unassigned feature/bugixes
The outcome of these items should be a prioritized list of issues, in case of not being able to assign the resources the escalation path should be look like this:
1. Project Lead of the project 2. project_leads@openoffice.org 3. Engineering Steering Committee (ESC) 4. Community Council (CC)
To come to a balanced assessment of issues there should be a least in those meetings:
- project lead - qa lead - member for release status meeting - reprentative for user base (user forum or user mailing list maintainer and/or a marketing rep) - if available: more developer and qa folks.
I suggest to start with our main, visible projects like Writer, Calc, Impress and Base and see later if we need to involve also other projects in this effort. I would like to encourage these teams to organize those meetings within the first two weeks of the each quarter (next slot would be April 1-14th)
