Martin Hollmichel's Weblog: Martin Hollmichel's Weblog

When watching a tennis match together with members of my tennis team, it is often fun to comment on the match, comment on mistakes of the players and what have could have done better to win the point. So it will not take that long until somebody says that if you really play as good in practice as you're able in theory, you will win even the Wimbledon championship ! Everybody who ever saw my tennis play in practice is pretty sure that I will never win any championship.
But why I'm telling such a simple story ? I was wondering for quite some time why some people are very shy to do many of their technical discussion open in the public. So far I have heard the answer, that doing work in small, closed teams is much more effective than doing this is big team. And I wasn't able to prove the opposite. The story of commenting a tennis match gave me finally an idea for the reason: Just commenting a match has almost no effect. I'm not the person on the playground being responsible for the result of the match. Although my comments and advises are correct, I am finally not able to give the right response because 1) I'm not the player and 2) even if I would be the player, I would not be able to give the right answers - in practice, because I have not the power or the resources for the right answers. Even worse, if I would hear in that situation some comments on how to give better answers, this would make my play worse because I would get angry about these "advices". Even if these advises are correct and given with the best wishes for me, they will be destructive for my play.
I guess the same applies for some of the related discussion on OpenOffice.org, people don't want to hear any advise if the originator of that advise does not have the power to help with the appropriate action.
So my lessons learned are:

• I only will participate in discussions where I'm ready to help in an active manner, if I'm only able to give an advise without sustaining help, I will shut up. I will assume that the actors also have read the right books and doing the right things that there are able to do.
• I will do as much discussion as possible do in the public, but I will use also as much filtering as I can for those people which are generating noise without really providing help, but I will carefully listening to people which are 'literally' helpful.
• A person who is "responsible" (in German "verantwortlich", not "zustaendig" how many Germans are sometimes misinterpreting the term "responsibility") for something should be able to give answers to any (maybe silly) question, if a person being in charge of a certain project will act in a closed environment, he will never be able to be responsible !

So in short:

• Be open, otherwise you will not be able to get new, unexpected help and you will never be responsible for your project !
• Only give advise if you are able to help !

A first developer snapshot of the PDF-Import Extension is now available on the Extensions Website.
Imported a couple of PDF files laying around on my disk. I'm quite surprised how many authors seen to think that PDF can't be edited anymore. Using the security settings (restrict permission) should help to set the expectations right.
Also new with the PDF Import extension for OpenOffice.org is the possibility to create hybrid files (PDF containing ODF). This allows the editing of those document with the original document format.

On Slashdot some comments based on the review by Bruce Byfield of Linux.com.

I looked today into the search suggestion list of various search engines.

	google	ask.com	yahoo
1	download	tutorial	download
2	mac	download	2.2
3	templates	templates	2.0
4	.com	.com	software
5	software	base	suite
6	docx	impress

For me it was unexpected that .com was that high in the various lists. Google provides an interface for looking up this data, e.g. http://google.com/complete/search?q=openoffice&output=toolbar

OpenOffice.org 2.0.4 comes now with a new online update feature which will automagically notifiy the user about new updates.

It is available as own module during the installation

and its settings can be changed via Tools->Options dialog

A few days ago there was a meeting of some OpenOffice.org project leads who agreed on writing more blogs for their projects to get more visibility for their project. I was asked why we want use one more medium to work with on regular basis for communication.

Here's my answer: Please think about how to get best your target audience involved and then choose the appropriate channel which fits the purpose and you are able to deal with.

Think first about your problem you want to solve with your communication and choose the right channel. In our OpenOffice.org world we have to deal with different content we have to communicate and various communication start and end points. Examples for content may be:

• documentation
• announcements
• presentations
• questions and answers

In some of these cases it may be desired to have the possibility to get feedback. Or it may be even required, e.g. if you need some guidance by an experienced developer during a debug session. Examples for communication end points are:

• Individuals
• Employees of a company participating the OOo Project
• Members of an OpenOffice.org Project
• all members of all OpenOffice.org Communities
• OpenOffice.org Users
• the rest of the world
• and many more like managers, committees, etc.

In most case you think of communication on OpenOffice.org you are yourself the communication start point. This is the easy one.

So it might be obvious if you seek advise during your debugging session that you do not choose the channel "TV" but a personal meeting or a phone call. Or the other extreme, if you want to do some advertising to increase the amount of OpenOffice.org users, you will probably do not choose the channel "phone calls" but a "TV Spot". It not too difficult to put a list with good examples together:

• Reference Documentation: -> Web Pages
• Guides and FAQs: -> Wiki
• Proposals and Discussion about them: -> Mail/Newsgroup
• Questions: -> mail/irc
• write something intesting with unclear communication end point: -> blog
• ask for more money: -> personal meeting with your manager
• ... endless list

I often heard that people tend to prefer privat communication instead of doing this in public. They want to have quick confirmation for doing things right and it is much faster to get this in a personal talk than writing a mail and waiting for responses. In many case you will not even get response on mailing lists. I think it is understandable but not the point. But it is not the point, we need to get all stakeholders involved for any issue regarding the specific project. So the primary issue is not that we need to communicate almost all communication on public channels, but to involve all concerned parties. This usually will result that this is somehow done on public channels but the main point is to do this on the right channel.

Our starting point was "why we want to use one more medium (blogs) ?". There was the question how we can attract more developers for participating in the OOo project. One of the answers was that we need to make OOo more interesting in technical aspects. We found that project specific articles might increase the common interest in OOo. Doing this in blogs seems a appropriate way for doing this: You are able to reach not already subscribed people and the effort for doing this via blog is reasonable low.

Further readings: Social Software

Pavel found it first: "Looks like after logging at the issue page, we are now back on that issue page." This will save a lot "go back and reload" key strokes :) (see issue 34822 )

The last childworkspaces containing new UI or Feature has been integrated now. With one exception: onlineupdate03 will be a little bit delayed. Now waiting for build m177.

What does UI Freeze mean: any strings changes are not longer allowed to do. This deadline ensure that translators will have some time before the release to do their work. Strings changes done after this deadline will remain untranlated. UI Freeze is also an important milestone for documentation puposes: builds after this milestones can be used to do screenshots and writing documentation about new features.

Feature Freeze: new functionality is not allowed any more. This will give some time for feedback on new feature or new code. That said, I also consider major rewrites/refactored peaces of code as new features.

The OpenOffice.org Snapshot builds are available on regular basis to give feedback.

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.

The OpenOffice.org Roadmap draw the picture to a more continuous development compared to OOo 2.0. It allows new functionality to be integrated when it is complete. Future 2.x releases will not only be minor bugfix releases but will also contains enhancements on the road to OOo 3.0.
This will benefit both: Developers and Users of OpenOffice.org:

• Developer will be more flexible wrt feature planning: there's no big drama anymore if a new feature will miss a major release deadline, it will be integrated into the code line once it is ready and stable.
• User will sooner get access to feature, he has not to wait for the next major release in every case

Last bot not least there will be less problems with slipping (forward :) ) a major release.

With OpenOffice.org 2.0.1 we have the first new features a micro release. Unfortunately we also got the first problems that we missed the UI Freeze for that feature and missed translation timeline, this result in English string for localized version (see screenshot below) in the main insert menu "Formatting Mark" and it's submenu. Please help fix this issue by providing the translation for your favorite lang into issue 58172 until Monday noon (GMT) for 2.0.1 release.

What's going on in OpenOffice.org development

As you might have already heard, we are still planning for the next releases of OpenOffice.org. Although there is an OOo 3.0 target in the IssueTracker, there is not yet a concrete plan for 3.0. OOo 3.0 currently is the synonym for the next major release of OpenOffice.org.

OOo 2.0 was a major release where we have shrinked down the amount of issues from our original plan to make the release finally happen. For 2.0.1, which is coming soon, we had many items on the list which we didn't managed to do for 2.0. Only few minor new features like "Context menu for numberings" or "Add shortcut to jump to recently used slide and view" will make it into 2.0.1 release.

For OOo 2.0.2 I expect that we will incorporate feedback from 2.0 release to increase the stability further by doing bug fixes. I think we will be able to manage a release about every three to six months, so we're going to plan next releases on this basis. Since we are now able to add new UI into minor releases we can add new features into the product even before the next major release. From my experience in 2.0.1 release, we should have a feature freeze at least 6 weeks before the planned release date, to enable all local communities to do their localization. It's also obvious that this is only doable UI changes or enhancements with a limited amount of strings to be translated.

Changes like bigger UI-changes, enhancement of API's or any other complex changes which needs some more time for implementation and review (rewrite of code, new concepts, major incompatible changes) should be targeted to a next major release.

For this reason I would like to ask OpenOffice.org contributors about their plans for the next time, so that we are able to compile a plan for the time until the next major release. Good starting points for this might be:

• a revisit of the PCD plan of 2.0, what have we accomplished for 2.0, what's left ?
• Publish your plans like Malte already did for performance area.
• Put stalled items like the rewrite of the Chart module onto the agenda.

For 2.0.2, planned for end of February, there are already some interesting items at the horizon, such as the Icon Theme Switching , new implementation of Spellchecking hunspell , Quattro Pro 6 Import Filter for Calc .

Contributing code to the OpenOffice.org repository is not easy, there are a lot of rules to follow. In the past there were again questions about these rules like:

• Have really all child workspaces passed this rules ?
• Do I have to comply with all these rules, I only have just a small change to make ?

We have to keep in mind that we want to achieve to major objectives with these rules:

• keep the quality of the build, meaning we are everytime able to release
• keep integration of new or changed code smooth, don't break the build

Since we introduced these rules we made major steps forward: we now have less build breakages than before and we also experiences less P1 issues when a build has been completed. But we still experience faults when integrating code back to upstream. If we look into these issues, we soon discover two categories: issues which could have been avoided if all rules would have been followed and those, which simply haven't been covered by test cases or where the cost-value ratio is too high. We have now this situation:

• These rules can't ensure that no failures will happen at reasonable cost
• Understanding the objectives of these rules help to avoid integration failures

This leads to the practice that we look at the cost-value ratio for many child workspaces: workspace for enhancing build environment, localization or build fixes will often get a check by code review to get integrated fast, others with feature enhancements will get even more attention by our GateKeeper (Joerg Sievers mark those cws with a pin). I as the Release Manager for the current code line look into many child workspaces and look if a owner of a child workspace needs help or even more control. The good news is that most people involved in this are pretty good in understanding our goals and apply to the rules as needed. If there are questions left please don't hesitate to ask your project leads for guidance or help to get your child workspace finally integrated. So the answer to the two above questions is a "no, but ...".

I updated yesterday the release plan for 2.0.1 and 2.0.2 release ( here ). In comparision to earlier releases the introduction of new features will be allowed. But it should not be expected that now tons of new feature will be available for these releases, only feature with small impact to documentation and locolization are expected. For bigger changes we need a more detailed roadmap which allow coordination among users, development, localizers and documentation people.

It is a good thing to have some paid support for operation the OpenOffice.org website. The site is running quit well since the birth of the project eaxctly 4 years ago. Ok, when got slashdotted, the site was quite slow, but this might not be the failure of infrastructe but the sussess of the OpenOffice.org project.

The collab.net infrastructure offers a framework where the most important stuff for doing software development, SourceControl (cvs), BugTracking and Webcontent, is very convient integrated. People familiar with SourceControl will enjoy the maintaince of WebContent with the help of cvs. Just do your changes with your favorite html editor (vi in my case) and commit it the cvs repository. Page got updated by magic on the site. At least for software developers, providing some "static" documentation or information this works perfect. Almost perfect. From time to time things are failing:

Our community manager, Louis Suarez-Potts, did some update for our birthday page last night and somehow the magic update of the new home page failed (experienced cvs user will see that cvs detected a conflict). Since collab.net provides granted support for the operation of the site, members of the regular OOo community don't have direct access to the infrastructure. This works well for regular problems, but it is a big problem if you want to fix a trivial problem immediately. Like this one.

In an Open Source Project with volunteers all over the world this should not be the problem. The project is working around the clock. In this case we will go the formal way: Write a new issue for this and wait for the resolution of the issue. Things get documented by this proceeding which is important if you several people working on the site. But you loose speed in fixing things, you got dependent on proprietary work of people.

This applies also for related items: Some things, like the cross reference (lxr), CVS Tree Control (bonsai), dynamic web content (php or other scripting), Online Databases (wiki), enhancement of content management services (plone) are available and well accepted in the various Open Source communities but the integration of them into the collab.net infratstructure seems to be a major effort. If we look back the past four years we see lots of minor improvements but the big wish list for the next birthday is always growing. It may be also in real life that the amount of wishes grows with child's lifetime, but from time to time it would be nice to get some wishes realized.

But anyhow, the project has good parents: If the infratructure part is the mother, we can see that the mother will take care of it's child, although her options are limited. The project also has it's thoughtful father: Louis. His community management always gives guidance to the growing child.