Stefan Taxhet's Weblog

Does a PATCH implement a FEATURE or a DEFECT and do we care ?

The preferred way to receive code contributions from developers starting to work on OpenOffice.org is the submission of patches. A dedicated section of the entry form helps to file an issue of type PATCH to our issue tracking system. Many issues of the types DEFECT, FEATURE, ENHANCEMENT and PATCH are filed every day. There are too many to resolve all of them. Besides a bunch of other unworked issues this led to a backlog of lingering PATCHes.

Some months ago we started an effort to improve the patch handling as one step to remove roadblocks for developers on their way to become a valuable contributor.
We introduced two metrics for patch handling

• Initial Response Time (IRT):
  Time in days between submission and first comment or status change.
• Issue Inactivity Time (IIT):
  Time in days since the last comment has been made.

We brought the average initial response time down to 2 - 4 days and are glad about the support from all owners of PATCH issues to keep it that low.

Average issue inactivity for patches is now at 40 days. This is a big improvement compared to the 120 days we started with. But there is still room for improvement and the issue owners are welcome to look at the statistics and take care of the patches - especially the outliers. Please keep the communication with the submitter going. The goal is to drive the issue to a solution. This means that the code is committed or it is not applicable or that it need some more work based on comments of reviewers.

A value of PATCH for the field issue type is the handle all these queries, statistics, ... are based on.

Unfortunately this value does not allow the distinction of patches implementing a bugfix (DEFECT) from those implementing a new feature (ENHANCEMENT/FEATURE). The workflow for features is not the same as for defects. There is an underlying assumption that most features but only a few defects need additional documentation like a specification and a feature mail. These notifications contain a short description, the link to the specification and a check mark to indicate whether UI, documentation, API, ... are affected. As a side effect a section of the release notes is created from feature mail data.

Here PATCH issues break ranks. It's hard to ensure that groups like localization, release engineering, documentation are informed about the impact of changes, if the nature of the issue is unclear. At least you can't enforce it with the technical means of the involved tools.

There are several ways to tackle the problem.
The most radical approach would be to refrain from usage of the type PATCH and mark issues with a keyword patch. This would be a major change in our workflow and needs significant work to achieve the same level of tool support we have today.
Or one could change the type from PATCH to DEFECT or FEATURE/ENHANCEMENT during hand-over to QA. Obviously there is no easy mean to recognize patches after the chance. One would have to take the consequences for the metrics supporting our improvement of the patch handling into account.
One could appeal for the discipline of committers to let a PATCH follow the necessary steps according to its nature. Peer review, incentives and pillories come to mind.

As a side note it should be mentioned that feature mails are not used very often. To me it seems that this mechanism is a bit outdated and not well integrated in the workflow. The helpful information it should carry might better be tied to issue handling or CWS handling.

So do we have to care about the type of a PATCH issue or is improper handling the exception?
Do you care?

Posted at 05:20PM Mai 09, 2006 by Stefan Taxhet in OpenOffice.org  |