Stefan Taxhet's Weblog

SoC application period ended

The application period for students ended last week on Tuesday. Before the weekend we were a bit worried. We received as few as 25 applications up to Friday (1/3 ineligible). And this time we advertised the program even more than last year. But as with the OOoCon 2006 Call for Papers (closing end of this month) people took their time and submitted just before the deadline.

During the initial review 20 applications were marked as ineligible due to insufficient information, extensive cut&paste work, a new revision, ... 2 applications were out of scope for OpenOffice.org and have been given to other organizations. Now we are reviewing in more detail a respectable number of applications for 35 SoC project ideas backed by 20 mentors and tied to 15 OpenOffice.org projects.

You wouldn't guess which idea most students would like to work on: guessing the language of a text. We are now gathering all the necessary information needed for the ranking of applications. The final ranked list of application is due May 22.

During the review period the overall good experience from last years SoC came to mind. Summaries from Miguel and Gervase describe remarkable different outcomes we can certainly learn from. Besides the diligent examination of applications we will work on some guidelines. These should help participants so that students find their way into the project and code its way into the product.

Posted at 01:20AM Mai 17, 2006 by Stefan Taxhet in OpenOffice.org  | 

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  | 

Summer of Code 2006

OpenOffice.org is happy to participate again in the Summer of Code initiative sponsored by Google.

We have some suggestions we find suitable for the program. If you have ideas for other tasks please send a note to the developer list of the related OpenOffice.org project or contact the project lead.

We would be glad to support a few projects. Please understand that mentoring capacities are limited. So we depend on your dedication during the preparation of the detailed specification and description of the outcome. Many mentoring organisations recommend to read the well-written hints from Drupal.

The timeframe for applications is May 1 - May 8. But keep in mind that it may need some prearrangement before you are ready to sign up and apply.

These comments from SoC 2005 Mentors may help this year's participants.

• We should put student's responsiveness to the test before an application is accepted.
• The decision about an application was difficult without a dialog with the student.
• The time for the preparation of the projects was too short.
• Active communication between student and mentor (and community members) is fundamental to define and meet milestones and deliverables.
• Weekly review of the status helps to make a project successful.
• It was fun to work with self-dependent students.
• The student should be aware that his SoC project is a full-time job.
• The program was helpful for both - the mentor and the student - to investigate new technical and personal areas
• We are happy that successful students from SoC 2005 still continue to work on OOo.

We look forward to read your detailed project description and will do our best to make Summer of Code 2006 even more successful than last year's.

Posted at 12:42AM Mai 03, 2006 by Stefan Taxhet in OpenOffice.org  |