After reading Mackenzie’s post about 5-a-day on the Ubuntu UK podcast I have to say that:
Dave: “What I’m getting at is, the Ubuntu community is vast, why in the last 7 days is there only 35 people working on it?”
is exactly what I don’t like about 5-a-day.
An issue with any metric is that you need to make very sure that you’re actually measuring/reporting what people think you are. 5-a-day stats are exactly that, stats on the 5-a-day participants, not Ubuntu as a whole. A problem with these types of community metrics is that they’re most often based on voluntary participation and the stats actually become more about who participated in the statistical method than the actual “thing” you were trying to measure.
Now, I think a problem with 5-a-day is not that it’s a bad initiative. I think it’s done a lot of great things around the community and I want to see it continue. However, I do feel like there are some issues with it that I think people need to think about some:
- 5-a-day promotes quantity rather than quality. The problem is clearly that quality is very difficult to measure, but the fact remainst that you can create a lot of bug “churn” and not get much of any actual useful work done. We can create a highly participatory community that contributes pretty much nothing to its users, other distros, or the FLOSS landscape as a whole.
- 5-a-day is heavily promoted as the way to track bug triaging work in Ubuntu. While it certainly measures some, I believe 5-a-day only measure a minority of the actual work being done in Ubuntu
- The 5-a-day stats page gives no indication of what it’s actually measuring and could be easily misconstrued, IMO
- 5-a-day not only doesn’t track all contributors, it doesn’t necessarily track all contributions by a by a particular contributor. It relies on a person actively putting bug numbers in their 5-a-day applet/CLI tool.
Lastly, I think a lot of this comes down to 5-a-day being designed to be a fun “scoreboard” for the community to have a little competition. The problem is when people see it rather as serious business, and especially in these days where Ubuntu is being challenged about its contributions I think we need to be perhaps more careful with how these types of metrics are seen by “outsiders”.
I’ve never really liked Network Manager all that much. Part of it is that I haven’t changed wifi networks all that much, and mostly because I have a static IP address at work. My usual network solution has been to create Home (let NM find my home wifi) and Work (turn off wifi and set up static IP on eth0) profiles in the Gnome Network config GUI. So when I saw that Intrepid wasn’t going all Network Manager and not install the Network config GUI by default I was pretty concerned. Sebastien Bacher convinced me to give NM a chance and after getting some bugs fixed I’m pleased to say that for the first time I’m only using Network Manager for network connections. I even did a bit of testing for Alexander Sack to see how the new Network Manager handled/parsed existing /etc/network/interfaces files. Awesome.
I’ve been rather busy with the PhD and other real life stuff, but I wanted to give a shout-out to a couple things going on in the QA realm. Leann Ogasawara has been working on the package-status-pages spec. A prototype can be seen at: http://people.ubuntu.com/~ogasawara/pkg-stats/openoffice.org.html . Stéphane Graber is also working on taking the XML output that Leann creates and making nice pages to go on qa.ubuntu.com. This will be a rather awesome addition to Ubuntu’s QA tools. Another cool project on the bug-metric front is work that Brian Murray is doing on the useful-bug-metrics spec. Brian’s working on gathering time-based data from Launchpad so that we can analyze things like the average time a bug sits in the New status, or how long it takes to get to Triaged, or even simply how long it takes to close bugs. This will add a whole other dimension to QA data that I’m really happy to see.
One of my true loves is education. Creating a FLOSS environment for kids to grow up learning and exploring computing is a sure way for FLOSS to permeate society. Providing high-school and university students high-quality applications to learn and research is awesome. Showing students how to collaboratively develop technology, expand scientific knowledge, and empower open learning is revolutionary.
Edubuntu has gone through a lot of changes over the last couple years. Oliver Grawert and the rest of the crew have made some really great strides developing an LTSP educational server. More recently, LTSP has been shifted to the Ubuntu Alternate CD and now Edubuntu’s CD offering has moved to an Educational Addon CD containing ~500 MB of educational software and other useful packages.
For Intrepid Oliver’s been moving into the mobile arena and consequently Edubuntu has kind of been in a kind of a holding pattern, waiting to see what comes next. I’ve been doing a little work lately to make sure the CD is installable (KDE-Edu 3 -> KDE-Edu 4 required some seed changes) but there’s a lot more that could be done. I think we’re going to need some sort of Project Phoenix to revitalize, rejuvinate, and refocus the project. I’ve was really impressed with Cody’s Xubuntu Strategy Document and would like to see something similar (though probably shorter 😉 ) for Edubuntu. Anyway, if you have interest in Edubuntu or Linux in education (pre-school, K-12, university) we’d love to to see you in #edubuntu on IRC or edubuntu-devel/edubuntu-users mailing lists. We want to hear from educators, school sysadmins, developers, students, etc.
Do you want to help contribute to Ubuntu but you don’t want to run the development release? Do you want to see Hardy become more bug-free? Then do I have a deal for you! 🙂
Ubuntu pushes updates to stable releases (currently Dapper, Fiesty, Gutsy, and Hardy) through a system of review and testing. Once stable release updates (SRUs) are prepared and approved for testing they are uploaded to the corresponding -proposed repository (hardy-proposed for example). The packages in -proposed wait there for at least one week and until 2 people verify that the bug(s) being fixed is indeed fixed. This step of SRU verification is where you all can help.
What you can do to help: You can look at the list of Pending SRUs and pick something you’d like to verify. Click on the bugs in the “Changelog Bugs” column, read about them and follow any instructions on how to reproduce the bug. Then install the package from -proposed (System->Administration->Software Sources, go to the Updates tab and select Pre-released updates) and then retest to verify that the bug is fixed. Report your findings, both positive and negative as a comment to the bug report.
Where you can go for help on how to help: The #ubuntu-testing IRC channel on irc.freenode.net is the place to go. Steve Beattie (sbeattie) and others would be glad to assist.
What you get in return: a warm fuzzy feeling for help your fellow Ubuntu users have the best Linux experience possible. You also might find you enjoy testing and get involved with other testing efforts the QA team will be doing for Intrepid.
Rock on people!
P.S. did I mention that SRU verifications are great for 5-a-day? 😉
OK, so rather than my usually long and boring posts I’m going to try to do some smaller/quicker posts just so I can get some thoughts out without it turning into some boring epic that nobody wants to read 😉
- the latest discussion about appropriateness of Planet Ubuntu posts – even though Stephan can’t seem to stay out of trouble I really feel that the problem is with this one little sentence: “Planet Ubuntu is a window into the world, work and lives of Ubuntu developers and contributors.” I think we’ve perhaps grown too large to not limit aggregation to Ubuntu-related posts. [Edit: After some further thought I think I might change my position a bit. I’ll give more info in a follow-up post]
- upcoming Ubuntu QA team meeting – tomorrow (23rd) at 17:00UTC we’ll be having a meeting in #ubuntu-meeting. There’s a few agenda items that people might be interested in so if you’d like to contribute feel free to drop by.
- hiking this weekend – my wife and I hiked Mt. Rose this weekend with some friends from church. Total the hike was ~10.6 miles (17 km) and had a ~1,900 ft. (579 m) elevation gain. We started at 8,900 ft. (2710 m) and it took us 7 hrs to hike to the summit, eat a quick lunch, and get back to the trailhead. You skinny hiking fanatics might not be impressed, but it was the longest/hardest hike I’ve done.
- related to the previous item, anybody have a good suggestion on a place to put pics of my hike and other events? I’ve heard both good and bad things about Picasa and Flickr, what would you suggest? I’m looking for a pretty easy, simple, storage and sharing site.
For the last couple weeks I’ve been working behind the scenes on creating a community Ubuntu QA (quality assurance) team. For quite a while Canonical has largely driven QA efforts in Ubuntu and I firmly believed that the community can and should step up in this area (see this wiki page for more background information).
So, long story short, I’m announcing that a community-driven Ubuntu QA team is up and running! The IRC channel is #ubuntu-quality and the mailing list is ubuntu-qa.
From the team wiki page:
The Ubuntu QA team is focused on developing tools, policies, and practices for ensuring Ubuntu’s quality as a distribution as well as providing general advice, oversight, and leadership of QA activities within the Ubuntu project.
In general, QA in Ubuntu is broken down into the following areas:
- Defect Management (Bug Triage)
- Quality Control (Update, Application, and Pre-Release Testing)
- Quality Assurance (Verification of Changes, Policy Compliance Review)
- Product Improvement (Development)
The main entry points for working on QA tasks are the BugSquad and Testing Team, however feel free to drop by #ubuntu-quality, if you are interested in Ubuntu QA.
Because Ubuntu QA is a coordination/development/working team the membership guidelines are:
- Individuals, not teams may be members.
- Expectations are that members have already been doing some QA work in the community, show a commitment to QA, and have some sort of plan for work they want to do. Ubuntu Membership and membership in a relevant QA team (see the list below) is generally what we are looking for.
- Memberships expire annually and can be renewed by members themselves.
- People from all areas of QA are encouraged to join.
What kinds of things does Ubuntu QA do?
- Coordinate between the various QA-related teams
- Build communities around QA work and help them run smoothly
- Provide lead-from-the-front leadership to Ubuntu’s QA projects
- Assess and communicate Ubuntu’s QA needs
- Develop tools and services needed in Ubuntu QA work
- Work on creating consistent and efficient QA-related policies
- whatever else comes up or people want to contribute
Huge props go to Emmet Hikory, Steve Beattie, Henrik Omma, and the rest of the team for helping this get launched.
So stay tuned for more exciting QA developments, feel free to contribute, and rock on!