a follow up to blog: OOo QA Internship programm

I am proud to introduce the results from the three month individual project of the Hitek school students, which is an important and closing part inside the oo qa internship program: Sample Music Database

p.s. a lot of further info & stuff you get on the students sites

screenshots from a students sample database:

.. at the end i would like to quote Nadejda, a student from the project:

"I'd like to say THANK YOU, OOo Openoffice for this project! Thank you for opportunity to learn so many new things! The time of internship was a great time! Sometimes it was very hard but I enjoyed it. I will miss you. Good luck OOo Openoffice!"

bye Chris

tags: community ooo open open-source openoffice.org opensource qa quality software sun

tags: community framework openoffice.org

Today I want to start a little overview about the current work of the framework project community members. Fortunately we have some volunteers from RedFlag 2000 who work on several projects. This time I want to provide some information about the following enhancement:

User interface migration

If you often change the user interface of OpenOffice.org you will probably stumble over the effect that the current user interface migration is not very smart. The migration process just copies all customized user interface settings from the old to the new version. This can result that you won't see any additional menu or toolbar items included in a new version. It's clear that only a minority customize the user interface of OpenOffice.org. But this problem leads to a bad user experience for all people who like to do it. Wu Yan, a developer from RedFlag 2000, and myself talked about the root cause and how to solve it in an acceptable way. Now that a first prototype is ready I want to give you a brief overview about the features.

The user interface migration enhancement wants to provide users the ability to choose what changes are migrated into a new version. Normal users can use the default which migrates all customized changes to a new version.

You can see a screenshot of a first prototype below:

First prototype: User interface of the UI migration wizard

You can see the Writer menu differences between a customized OpenOffice.org 2.3 and 3.2 (DEV300m55). The user can delete changes or reset his/her work. „OK“ migrates the remaning entries and with „Cancel the user can abort the migration process. This user interface is just a prototype to test the implementation and have a first impression.

Attention:
If you interested in this enhancement and know how to write a specification. We are looking for volunteers who want to help us writing a good specification for this enhancement. Most developers are not good at creating a compelling user interface which can be used by normal users. Therefore people who want to join the OpenOffice.org community can provide valuable input. This is your chance to actively influence the progress of OpenOffice.org and work on an interesting enhancement.

You can contact me via e-mail or subscribe to the framework development mailing list. Everybody is welcome. The framework team will help you to have an easy start.

tags: community framework openoffice.org

a follow up to blog: About one year of OOo QA Reloaded

The QA Reloaded Project and the general Mentoring and Participation Concept covers a lot of possibilities to connect and synchronize the OOo QA community with the SUN QA to optimize the quality of the OOo QA productivity suite. It range from small, specialized groups like the Database QA Team who currently overtake parts of daily QA work, to the new internship program, which should be the main topic for this blog.

The history of Internship in OOo QA area started after an open mail from a representative of the Hitek Computer School - Vancouver (Canada), which is a private educational institution focused on intensive training in Software QA and Software Testing, with a question if we, the OOo Team Leads, can afford their students a practice inside OOo QA.
In principal we already had worked out such an offer inside the OOo QA Reloaded Mentoring concept, but in this case we had several students for a limited time, who need rules, lessons and leading, so our concept had to be enhanced into this direction to not exclude such community groups and keep the community vibrant. So after a lot of mail traffic, we agreed to start a first test run with two former students, which should overtake the leadership of the following student groups, after passing a basic QA training. This was also a good occasion to create and test a new concept and fit it to the belongings of student- or similar groups.
After the course Natalia and Oleg became Group Leads (GL) for their student groups (group1,group2) and joined OOo QA Teams (Calc,Writer) as Team Members. With their acquired rights and knowledge, they also start to lead their groups trough the lessons (replaced the former, more general participation step rules) which include the general techniques and QA knowledge on OOo, with a big practical contingent. We started with ten student and eight finished this basic course. To complete the program, we added an individual project to give the students the possibility to get creative, show what they can and also have a work sample for their further job applications. Unfortunately Oleg had to give up the leadership of his group, because of private reasons, and so Natalia overtook the responsibility for all students. Because of this circumstance we decided to make only one common project and create three groups with three members. At the 25 May all groups had started with the project, which will last three months: Music Database.

bye Chris

tags: community ooo open open-source openoffice.org opensource qa quality software sun

tags: community framework openoffice.org windows

For quite some time now OpenOffice.org has been working on a move from the outdated CVS to a modern Distributed Software Configuration Management (DSCM) system. Last year the Engineering Steering Committee (ESC) agreed in a face-to-face meeting to start with a switch from CVS to Subversion as an interim step.  This conversion allowed us to leave all the dead branches and legacy releases behind. The size of the new repository shrank from the projected 100 GB to actual 6 GB. Since October Subversion is in use on our codelines leading to OOo 3.1 and later versions. As it was planned, now is time to go further and migrate to a DSCM. An in-depth evaluation document has been prepared and presented. It shows the pros and cons of Bazaar, Git and Mercurial. While there is a tendency towards Mercurial there was no clear favorite.

So the ESC decided during the March 9/10 face-to-face meeting to run a survey and consult the OpenOffice.org contributors. Contributors were asked about their experience with the different existing OOo repositories, SCMs in general and most important what their prefered DSCM for the OpenOffice.org source code is.

149 contributors participated in the survey - thank you. Most of them worked with OOo's code repositories CVS and SVN. In general participants have experience with the centralized systems CVS and SVN and quite a few know distributed systems already - Mercurial is a bit more familiar than Git.


So, what distributed system do our contributors prefer for OpenOffice.org source code?

To me the correlations to general experience and OOo work were interesting. There is almost no difference in preference between the groups who worked on OOo CVS for source or OOo CVS for webcontent or OOo SVN. These are consistent with the overall result.
But looking at the ratio correlated with the general experience, we see that Mercurial users are even more enthusiastic about their system than Git users.

The bottom line?

The system of choice is for 3% Bazaar, for 23% Git and for 49% Mercurial. 25% had no preference. 

Let's see which next steps the ESC will nail down on Monday under consultation of the input from the community.

tags: community dscm openoffice.org repository survey tools

The OpenOffice.org wiki is alive and well. There is more information there than probably anyone knows or may be able to find and enjoy.

As a member of the OOo user experience project, I've created a survey to jump start a revision process for improving the usability of the wiki and therefore making that information easier to find and consume (yummy!) .

If you have ever experienced the OOo wiki, please feel free to get vocal about it by taking this quick survey.

Your wiki will thank you :-)
Liz

tags: community survey user-experience wiki

We are short before code freeze for OpenOffice.org 3.1 and I want to give you an overview about the major community contributions for the framework project. First of all I want to thank all contributors for their dedications and commitment. It's a pleasure to see how hard and target-oriented community developer work to reach their goal. This part wants to present the work from Ariel Constenla-Haile, a very active community member from Argentina. If you are involved in OpenOffice.org development you definitely stumbled over his name. Some months ago Ariel detected an issue which complained about the limited abilities of UNO AWT API regarding menus, especially setting an image for a menu item. UNO AWT is a project which provides an UNO based abstraction layer above VCL (OpenOffice.org user interface toolkit). This API is often used by extension developers to create their own user interface. The framework team received a patch for this issue from Shi Zhoubo, a developer from the RedFlag 2000 team, regarding menus and images. Ariel noticed that the patch fixes the issue but other VCL features for menus were not part. He decided to overcome the limitations of the first patch and worked on a complete solution. He analyzed the present situation and listed what features were missing. He thought about possible solutions and contacted me for discussion. We agreed to a solution which provides three additional interfaces for the missing features. He created patches for the projects involved and contributed them. Summing up Ariels contribution is a good example how people can help to fix/enhance OpenOffice.org.

The following image give you a impression what's is possible with this enhancement:

Ariel created a wiki page to explain what problems extension developers face, how to solve the problem and what's possible with his enhancement. I strongly recommend people that are interested using menus in OpenOffice.org to read his explanations.

If you want to help us to make OpenOffice.org better please contact me via e-mail or join the framework development mailing list. Everybody is welcome to join us. The framework team will help you to have an easy start. Just give it a try to become a development member of the leading open source Office suite.

In my next blog I want to continue the overview with an enhancement regarding keyboard shortcuts.

tags: community contribution framework openoffice openoffice.org

tags: community ooo open open-source openoffice.org opensource qa quality software sun

Last week we had a face to face meeting of the “notes2” team in Hamburg. It was the first time where all members came together at one place – until then the work was completely done remotely in different parts of Germany. We started with a Google Summer Of Code project in 2007 and continued as a team that works together for quite a year now.

We think that our little project was very successful, but nevertheless we wanted to look back a little and talk about our “lessons learned”. Here's a short list of things that aren't new at all but that we consider to be important especially for remote team work:

• While meeting agendas are a good thing to have always, they are indispensable for IRC meetings.

• It's good to become acquainted with each other early and know more about everybody's background and motivations. This makes it easier to understand and trust each other. So if possible a face to face meeting in the beginning is desirable.

• We should have used telephone conferences much more often; we used e-mail too much.

• It was good not to plan for a fixed release and instead define the minimum feature and quality requirements for a first possible release.

• Not all decisions can be made by the whole team, and so it shouldn't be tried. Instead of this the team members need common guidelines they have agreed to.

• Use cases are a very useful way to define such guidelines. Personal preferences should be hold back as much as possible.

• Discussions shouldn't be exhaustive in all cases, but it is important to point to technical limits and errors as soon as possible.

But of course the most important insight was that we all had a lot of fun working together and that we think that we created a considerable value for the product. That's what working in a community is about – and I hope that we can have more like this in the future. So if you know something you want to implement in Writer, but need some help – just let me know. :-)

Of course we also talked about future plans for the “notes” feature and the new notes sidebar we created for it. We want to start implementing them in OOo 3.1 and continue in the following releases. Here's what we came up with. You might be pleased to read that work on the first items is already in progress. :-)

As Christoph Noack happens to be the Co-Lead of the OOo User Experience team, we took the chance to meet with the User Experience team members Christian Jansen and Frank Löhmann in Hamburg also and made it a “ what we always wanted to discuss about Writer usability improvements” meeting. We identified some topics that we see important and that we want to include in the upcoming project review that is planned to happen in early September (right after my vacation ;-) ):

• An "Insert page" function that frees users from dealing with several single steps just to e.g. insert a landscape page

• "Insert page number" also as a one-step function

• Improve other functions dealing with page styles (allow to describe which pages shall be influenced by the change etc.)

• "Delete hyperlink" function in the context menu of text formatted as a hyperlink

• “Accept/Reject Changes” in the context menu of changed text

• Add (a) Landscape style(s)

• Use transparent selection in Writer as in the other OOo applications

• Add a Change Tracking option "don't show deleted text in track changes" and use it by default

• Status bar improvements

The mentioned changes in the Change Tracking feature look even better if you add the planned “show change tracking comments in sidebar” feature from our list of “ notes” enhancements!

Here's a picture of the exhausted ;-) team after a long meeting:

From the left to the right: Christoph Noack (UX), Éric Savary (QA), Max Odendahl (Dev), Mathias Bauer (Dev)

tags: community development features user-experience writer