Quarterly Review

From Apache OpenOffice Wiki
Revision as of 07:45, 14 March 2008 by Mh (Talk | contribs)

Jump to: navigation, search

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:

  1. Status of the project
    1. what are the most severe issues in the current release
    2. which are the most requested (or needed) features (in the press, user forums, issues, other feedback)
  2. short term planning
    1. which defect needs to go into the next release
    2. which features will be worked on for the half year.
    3. which issues needs an assignment
  3. mid/long term planning
    1. which features/bugfixes needs to be addressed in the next two/three years
    2. 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:

- the project lead
- a qa lead
- if available one representative from user experience
- if available one representative for user base (user forum or user mailing list maintainer and/or a marketing rep)
- if available representative from marketing project
- if available: more developer and qa folks pr any other contributing members of the OpenOffice.org project

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
Personal tools