Martin Hollmichel's Weblog: Martin Hollmichel's Weblog

In the past weeks there were some discussions about reviewing open patches for OpenOffice.org and about the possibilities to integrate them in the main code line.

Quick review of patches

Patches should be reviewed quickly. There is now in agreement of reviewers that patches do need have a target milestone in the near future. If a patch can not applied as is there will be some comments on it in the issue. Or the patch will be refused because the patch breaks things and can't be fixed.

Specifications

On the OpenOffice.org wiki better is prepared to make the Guidelines for writing OpenOffice.org Specification more clear. There is a new Specification Template out which provides a "guided tour". A self-reviewable, lightweight process for reviewing a specification by the community is desirable. Specification for implementing obvious and non-controversial features may even don't require a full blown specification document but only some documentation at a centralized location.

QA on Child Workspaces

A similar problem as for Specifications applies for QA. The QA Team (Andre Schnabel, Joost Andrae and other) are currently looking on how interested people can be included more in feature (cws) and localization testing than before.

automated builds and tests

Some people already took a deeper look on how to implement something like a Tinderbox compile and test farm and are creating a new subproject for it.

I think having all of the above in place will make it for both, patch submitter and reviewers, more easy to get contributions into the OpenOffice.org code base. New contributors will get faster feedback if spec and QA Guidelines are more transparent. With a tinderbox farm many aspects of the review will be filtered out early.