Looking towards Xubuntu Q

During the Precise cycle, the Xubuntu team has accomplished many things. Now that there is only a week and some until the release, it is time to look at the Q cycle. In February, I started creating a list of things I want to work in the Q cycle with our community. In this post I present some essential items from the planning.

Redefine the community

Providing a wonderful operating system is not just having skilled developers and contributors. The community needs to be devoted, committed and feeling well.

Creating the roadmap

In the beginning of the Precise cycle, we introduced a new way to plan the release. Creating the roadmap along with registering the blueprints and listing all the work items really paid off. (Huge thanks go to the team creating the Ubuntu work items tracker too. Without it, tracking the process would be so much harder.)

In the next cycle, we need to polish the roadmap creation to be even more streamlined and effective. Now that we have done it once we probably know most of the pitfalls and can avoid them. One of the mos important aspects is scheduling the different phases correctly.

Having a clear idea on how to build the roadmap hopefully means we will get more ideas for the next release too. Naturally, more ideas doesn’t mean we will get more things done, since every blueprint needs to have an assignee. Any way, I believe good and justified ideas will attract people to work on them, whether it is new contributors stepping up as assignees or pinpointing  the existing contributors’ focus on a single items.

By the way, the roadmap for Xubuntu Q exists in the wiki.

Devotion and growth

Getting things actually done needs devotion and usually good communication with other people along the way. We will need to be able to support contributors better in the next cycle. Since working on Xubuntu is all volunteer work, we can’t force anybody to do anything. Constant babysitting is both annoying and stressing for the contributor and time-consuming for the team, so we probably need some other ways to keep people devoted.

I hope that the community will step up on this area and propose ways in which we can help them being committed to the things they are working on. People are different and need different kind of things to stay excited and focused, so any feedback is very welcome.

Much of what is said about getting existent contributors to commit is also true on attracting new members. In addition, we need to offer low-hanging fruit for them to make it easy as possible to start contributing. After you’ve done a tiny thing, it’s easier to register yourself as the assignee for a slightly heavier work item and so on.

Communication

One of the procedures which unfortunately didn’t work so well in the Precise cycle was the community meetings. They weren’t as regular as they should have been. More importantly, they were all too scarce especially towards the end of the release. In the future cycles, I hope we can create a schedule for meetings which both supports the contributing as much as possible but doesn’t tie people to schedules too strictly. This most probably means finding a good balance between scheduled meetings and impromptu meetings.

Chairing a meeting is something everybody in the team can do, which, in my opinion, is one of the key things when you want to have a regular meeting times with a group of volunteer people. This means the team is able to carry out regular meetings without needing a specific person being available at that time. Of course, if the key people for an agenda item are not available, that item can’t be addressed in that meeting.

As well as encouraging continuous developer–developer communication inside the team, we also need to communicate better with other teams. This includes reporting about progress to other teams via the the Ubuntu release team mailing list and IRC channel as well as communicating with other teams directly – namely, the Ubuntu Studio team because they use Xfce too and the Xfce development team, because that’s where our desktop environment comes from. Generally, knowing and being in touch with people from other teams of Ubuntu should be encouraged more.

We can’t forget the communication with users either. We registered a Twitter account @XubuntuLinux this cycle and there is a Google+ account for Xubuntu too. Our website undergone a huge facelift. Now it’s time to take care of these and post interesting content about the Xubuntu development, community and any other thing related. The good news is that the whole Xubuntu team can take part in creating the content.

Strategy Document

Our Strategy Document is four years old. It definitely needs an update. Here’s a few things that definitely need fixing.

We need to update our mission statement. Times are changing and so is Xubuntu. While we are relatively lightweight, we just can’t promise Xubuntu works with all computers built in the last 15 years.

During the Precise cycle, the voting procedure was criticized. The main criticism was that restricting the voting to happen at the meeting doesn’t allow as many people to vote as possible. The issue was raised especially when electing the new project leader in October and when voting about the logo change in March. I agree that this is an issue that needs resolving as soon as possible.

The community structure gives way too much power for the project leader. Generally, the decision-making should be much more collaborative. We need to make sure other team leaders get their voices heard too. Non-technical people need to be encouraged to be more engaged in the development

The Xubuntu Council has been defined in the Strategy Document for four years, but it still hasn’t actualized. That’s a problem, since in too many situations, the Strategy Document refers to the council doing things, including resolving conflicts. Since it doesn’t seem to be a plan in the near future to form the Xubuntu Council, we need to remove the references to the Council in the Strategy Document. This effectively means we will need to remove the council from the document completely. Don’t worry, the definition for the Xubuntu Council can and will be reintroduced to the Strategy Document if need arises. Right now we’re just better off without.

And finally, we need to condense, clarify and simplify. Work is in progress already and the hard work of reviewing will start at the right beginning of the Q cycle.

Things visible to end-users

Default applications

Our default applications need a review. This is not to say any of them is bad, but it’s too long since we really focused on this the last time. Do we want to stay with Ubuntu Software Center or are there better alternatives? Can we even ship Synaptic anymore, it’s not maintained very actively lately. What about gThumb and Ristretto? Abiword and Gnumeric? Oh, and do we really need GIMP? What about gmusicbrowser, is it the optimal media player selection for a default user? The elementary OS video player Audience looks much better than Parole, do you think too that we should switch? Hmm, Alacarte is much better now but is it still suboptimal?

Polish the user experience

This is much what we done in Precise too, but we need to continue working on it. We planned a relatively big facelift for the Xubuntu booting experience, but we only got to fix a few minor bugs. Let’s keep working, and this is easily ready for Q cycle alpha releases.

Update the documentation

The Xubuntu offline documentation shipped with the CD image is in awful state. It has an old version of the old logo. No, not the one created over two years ago, the one previous to that. Unfortunately, some of the documentation might be as old.

This is a big undertaking, but it’s possible to fix the documentation if we all work as a team. All you need to know is some general knowledge about Xubuntu and Xfce, the rest you can learn on the way.

Finish postponed blueprints

We will have a few minor blueprints hanging about from Precise, those will be carried on to Q and fixed there. We promise.

Next steps

There are still a few things left to do on the Precise cycle, including writing the final release announcement and release note, which are in the works too. After all the small work items, the next thing to do is wait the Precise release and maybe celebrate a little when it’s out.

Don’t forget to pat the Xubuntu team on the back for good work, because in May we are back to the hard work again.

This article is part of the article series A day in an open source project.