Roadmap closed»

The planning period for Xubuntu Precise Pangolin has ended. All in all, we have fifteen (15!) roadmap items with assignees! Thanks for all of you who submitted ideas, discussed the roadmap items and took action items! By the way, there is still a few items up to grabs. The roadmap has been closed for direct submissions, and all ideas must now pass, and be approved the community meeting separately.

If we don’t get any counterarguments for the items (see my email about approving roadmap items) and everything goes well, we will be expecting to get at least 11 of these in Precise.

The four roadmap items that still need a separate approvals from the community after the specification writing part, which last all the way to the end of this month, are:

  • New default media player (audio)
  • Ubiquity “Application sets”
  • Rethink shortcut keys
  • Clean themes (GTK, xfwm, wallpapers) list

To be honest, I expect at least three of these to get community approval after none to slight discussion and reviewing of the specification.

Yes, you guessed right, the one I’m not sure is the new default media player. It seems that we have had a lot of debate about this during my involvement in Xubuntu; we have changed the default player three times! While I think gmusicbrowser is a wonderful player and am very proud to ship that as our default player, I think there might be some viable alternatives, especially those players that are really simple. A bit like Listen was when we shipped it. I’m waiting the discussion with lots of interest, but I do hope we will have a civil and as objective as possible, discussion to make the best choice for most of our users.

Let’s keep on working hard, and this will be our best release so far, by far!

Xubuntu Precise Pangolin roadmap»

We have started to brainstorm Xubuntu Precise Pangolin! The Xubuntu Precise Pangolin roadmap will contain all the information you need to contribute, including the schedule for planning and all the items in the roadmap.

The first step is to brainstorm all the new features we want in, the bugs we really want to fix and the default applications we want to review. The brainstorming period has already started, and will end on Monday, November 21.

Assignees for ideas should be found during this month. If you want to take an action item, feel free to add your name/nick in the list too already. We will send an another mail asking for assignees for not-yet-taken items on when the brainstorming period is over though, so don’t worry about it just yet. Implementation for the features and other stuff will be expected to happen according to the Ubuntu Precise Pangolin Release Schedule.

Canonical–community collaboration»

Jono Bacon, with all respect, you are not always so awesome. I wholeheartedly agree with much of what Lionel, the lead developer of Xubuntu, said in his blog when he wrote about doing community survey reports the wrong way.

Any survey report that doesn’t do any analysis with the content in any way is useless. Especially if you have large amount of data gathered from very different groups of people, you should do some correlation between different questions, to actually spot possible problems in the community. For example, I’d really like to see some correlations and differences in the answers by Canonical employees and volunteers.

A word of few about collaboration

The survey shows that there is various problems with collaboration between the Canonical teams and the community. While this might not be objectively the biggest problem, it is a multi-layered one, with hard-to-find solutions. Especially if there is no change from the Canonical side of things.

There’s a few specific reasons why I think Canonical employees working on Ubuntu should collaborate more with the community.

While 1+1 is not three when you collaborate with other people, it usually does reduce the workload for everybody, since you wouldn’t need to do duplicate work and you would be able to brainstorm with other people to get better results with the first try.

Volunteers in derivatives would have much more information on what is going on, and it would be much easier to get things working again, when you could collaborate with the person who (accidentally) broke something you need. Currently it is nearly impossible to get any non-volunteer to help with broken things in Xubuntu, even if the reason for being broke was a direct outcome of any change in Ubuntu, or the core packages.

With derivative developers not having to use most of their time fixing bugs others made appear, they will have more time in getting the derivatives more user-friendly, stable and even more feature-rich. The more interesting and well-working a product is the more people want to use it. This applies to Ubuntu and it’s derivatives too, so this would certainly attract more users to Ubuntu, too.

First step forward, but are we going the right way?

I heard there is a new “If you break it, you fix it” -policy coming up. I really hope this works as expected and applies to new versions of packages breaking other packages too. My main concern is that this will not apply to Canonical employees or other core developers, permanently or via exceptions.

Only future will tell.