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.
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.
This article is part of the article series A day in an open source project.