Difference between revisions of "Quarterly Review"
(→Implementation of Review) |
|||
Line 27: | Line 27: | ||
- representative for user base (user forum or user mailing list maintainer and/or a marketing rep) | - representative 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) | ||
== Implementation of Review == | == Implementation of Review == | ||
− | + | It is almost impossible to get a slot defined where all parties together at a time for an irc meeting. To involve as much poeple as possible there might be an offline phase before an online meeting: | |
* call for important issues on the project mailing list dev@<project>.openoffice.org and put them into the wiki | * call for important issues on the project mailing list dev@<project>.openoffice.org and put them into the wiki | ||
Line 41: | Line 41: | ||
* irc meeting to confirm the priorization | * irc meeting to confirm the priorization | ||
+ | |||
+ | * send out the result to dev@openoffice.org |
Revision as of 07:41, 14 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 - representative from user experience - representative 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)
Implementation of Review
It is almost impossible to get a slot defined where all parties together at a time for an irc meeting. To involve as much poeple as possible there might be an offline phase before an online meeting:
- call for important issues on the project mailing list dev@<project>.openoffice.org and put them into the wiki
- irc meeting to check if all important issues are raised and sort out the unimportant ones
- call for review the list and suggest a priorization of issues on the mailing list and put the result into the wiki
- irc meeting to confirm the priorization
- send out the result to dev@openoffice.org