I wrote a quick summary of yesterday’s party and chronicled many press hits the event got on the Internet. I’m still not finding many photos which I know were being taken. If you took photos or wrote about yesterday, please do comment on this post or email me.

I also wrote about the Laoban Soundsystem 1.0 July 1st Green Day IDEA2009 on my wiki previously if you’d like to chip in some links or comments. I really want to use the speakers, granted they aren’t the big Laoban 2.0 stack, for more events in Beijing! Also, I really must learn more about this brilliant Ableton live software. I’ve avoided it because its not free software, but now I think I’ve got it running in Wine. And, regardless, I must learn about this software if myself or anyone else wants to make something similar for live audio/video performances in the same caliber, but as Free Software (and better!).

If you want a great analysis and take on the Chinese Green Dam Saga, please read Andrew Lih’s post and the other great ones by Rebecca MacKinnon.

You can get this info from sessionstore.js in your firefox profile, but it's a jumble of javascript. I wrote a script ff-pages to display them in a more useful way.

Example usage:

$ ff-pages .mozilla/firefox/*.default/sessionstore.js

Window 0:
    http://shoutcast.net/directory/index.phtml
    http://www.radioparadise.com
    http://people.ubuntu.com/~bryce/Plots/
    file:///var/www/X/Graphs
Window 1:
    https://bugs.launchpad.net/ubuntu/+bug/379797
    https://bugs.freedesktop.org/show_bug.cgi?id=21315
Window 2:
    https://bugs.launchpad.net/ubuntu/+bug/360319
    https://bugs.launchpad.net/ubuntu/+bug/376092
Window 3:
    https://bugs.freedesktop.org/show_bug.cgi?id=21756
    https://bugs.freedesktop.org/show_bug.cgi?id=16702
...

Since this is a bad problem there's been quite a few ideas proposed.

FIXING the bugs faster would be the best thing of course. That's a whole other topic... but does deserves first mention.

Launchpad already has a solution in the form of the "This bug doesn't affect me (change)" text and link on every bug.

Presumably this is serving as a lightning rod saving us from heaps of me-too comments. And presumably the data is being stored somewhere to help developers identify highly popular bugs, but I don't know how to access that info. I would imagine if developers could filter/sort/view this data it'd give added incentive for people to use that and it would be a more effective tool.

Another issue is that the link just isn't that noticeable. I'll leave it to usability experts to work out how best to improve it, but it definitely needs a re-think so it's a bit more obvious, especially for casual launchpad visitors.

Educating bug reporters is another oft-suggested solution. I think there's some truism about documentation being the worst way to explain how software works, because no one will read it. Actually there's been reams and reams of discussion and documentation about how to write and behave on bug reports, and indeed I think this is really helpful as it can turn bad bug reporters into really good bug reporters. That said, many people are just too busy, or too lazy, or don't even know they don't know how to report bugs.

Hiding comments or otherwise emphasizing/de-emphasizing comments by various criteria has been suggested and I believe is being considered by the launchpad crew. The trick is to do this in a way that doesn't end up actually consuming more time to manage than it saves. I think a lot of useful experimentation could be done on this idea using greasemonkey, as Brian Murray has done.

Splitting bug reports would be pretty cool feature, at least in theory. If we realize that John and Bob have different issues, it'd be slick to be able to push a button and have all of Bob's comments moved to its own bug report. But in practice I suspect this could result in creating more confusion by losing context. In any case, I don't think it'd help with me-too storms since most of the low value comments really aren't worth setting up a separate bug for; better to just have the people file new bugs from scratch.

Locking bug reports, is sometimes suggested by those familiar with similar functionality provided by forums software.

Minimum karma requirements to post onto other people's bugs is an idea I've been kicking around for a while. I've noticed (thanks to Kees Cook's lp_karma_suffix greasemonkey script) a very strong correlation that the worst me-too'ers also tend to have the lowest karma. People with the most helpful comments usually have higher karma.

So why not make use of that by requiring posters to have a certain karma level before being able to comment on someone else's bug report? From what I can tell, it needn't be high; 50 points would be enough to weed out the vast majority of the noise, but still be low enough that anyone with a legitimate interest in helping on bug reports could earn with a fairly minimal amount of work, such as helping on answers.ubuntu.com or going through the full bug process following up on their own bug reports.

Perhaps it could be set up to kick in only after there are already a few commenters, so we don't get in the way of random helpers on bugs that would otherwise be neglected. In a way, this would be akin to the "locking" idea above, but a bit more targeted.

Other thoughts?

Now that the Green Dam Youth Escort has been delayed, we have a full on celebraton on our hands in CaoChangDi from now until midnight, on Wed, July 1, 2009.

[Link to the SVG file]

We will bring our Laoban 1.0 Soundsystem with its new shiny grillz tomorrow. To all DJs and musicians out there (especially good ones!), this is an open call to come on out and plug-in to the speakers. We need you to come out and make some sound, art, and have a big ole green day brainstorm. The whole day is free and open! The entire day is to boycott the Chinese Internet.

To all our Internets Massive! To all Twitteronians, Identicators, Free and Open Source, Creative Commons’d out people in Beijing, or those who just want to have fun, please come out tomorrow for the full day or even just part of it. Matt Hope, Jon Phillips (rejon), Robin, Phil Dunn and so many more will most definitely be on hand to mix, make some projects in realtime and collectively boycott the Internet.

Party Day — See You in Caochangdi

WEDNESDAY 2009 1 July 9:00 AM to 11:30 PM, all day beer and chatting.

Blog friends, food friends, all are welcome. There will be gifts.

Phone: 010-8456-4194
Email: xuesheng512@gmail.com

Address: Beijing, Chaoyang District, Airport Service Road, Caochangdi No. 258 FAKE Studios

Breakfast menu: soy milk, gruel, youtiao, dumplings, four types of pickled vegetables, fried eggs, ham, tea eggs, fruit platter

Lunch menu: cinnamon lotus root, village style fungus mushrooms, seafood hot and sour soup, marinated duck, oyster sauce beef, fried fresh vegetables, Yangzhou fried rice, fried noodles, seasonal fruit

Dinner menu: cucumber, fish and egg soup, barbecue chicken, fish steaks, gulao pork, hot and spicy tofu, black peppercorn beefsteak, fried dishes, assorted mushrooms, udon, lotus fried rice, seasonal fruit

Midnight snack menu: cabbage hearts, spicy dried tofu, peanuts, fried broad noodles, gruel, fried bread with dipping sauce, garlicky vegetables, season fruit, four types of pickled vegetables

Breakfast, lunch, dinner, and midnight snack. Coke, Sprite, Fanta, orange juice, plum juice, lemon tea, Tsingtao, all kinds of beverages.

Guests can hang out in the lobby our outside eating and doing whatever they feel like.

Thanks to our great friend Robin Peckham for the realtime translation of the original post by the Wizzler.

UPDATE: Chinese government has delayed the Green Dam! The party goes on though in more of a celebration-mode!

Part of the concept of the site is that I invite people to submit reasons to be happy. My mom did it and she provided an interesting insight on it that I wasn't expecting: it made her think about what makes her happy and just added to her happiness because it brought all those good thoughts to mind. Bonus!

If you haven't visited Tweeted Blessings yet, do it. If you haven't told your friends about it yet... do you hate your friends and not want them to be happy? Go, enjoy some reasons to be happy and then share them. Help start a happiness pandemic.

Since this is a bad problem there's been quite a few ideas proposed.

FIXING the bugs faster would be the best thing of course. That's a whole other topic... but does deserves first mention.

Launchpad already has a solution in the form of the "This bug doesn't affect me (change)" text and link on every bug.

Presumably this is serving as a lightning rod saving us from heaps of me-too comments. And presumably the data is being stored somewhere to help developers identify highly popular bugs, but I don't know how to access that info. I would imagine if developers could filter/sort/view this data it'd give added incentive for people to use that and it would be a more effective tool.

Another issue is that the link just isn't that noticeable. I'll leave it to usability experts to work out how best to improve it, but it definitely needs a re-think so it's a bit more obvious, especially for casual launchpad visitors.

Educating bug reporters is another oft-suggested solution. I think there's some truism about documentation being the worst way to explain how software works, because no one will read it. Actually there's been reams and reams of discussion and documentation about how to write and behave on bug reports, and indeed I think this is really helpful as it can turn bad bug reporters into really good bug reporters. That said, many people are just too busy, or too lazy, or don't even know they don't know how to report bugs.

Hiding comments or otherwise emphasizing/de-emphasizing comments by various criteria has been suggested and I believe is being considered by the launchpad crew. The trick is to do this in a way that doesn't end up actually consuming more time to manage than it saves. I think a lot of useful experimentation could be done on this idea using greasemonkey, as Brian Murray has done.

Splitting bug reports would be pretty cool feature, at least in theory. If we realize that John and Bob have different issues, it'd be slick to be able to push a button and have all of Bob's comments moved to its own bug report. But in practice I suspect this could result in creating more confusion by losing context. In any case, I don't think it'd help with me-too storms since most of the low value comments really aren't worth setting up a separate bug for; better to just have the people file new bugs from scratch.

Locking bug reports, is sometimes suggested by those familiar with similar functionality provided by forums software.

Minimum karma requirements to post onto other people's bugs is an idea I've been kicking around for a while. I've noticed (thanks to Kees Cook's lp_karma_suffix greasemonkey script) a very strong correlation that the worst me-too'ers also tend to have the lowest karma. People with the most helpful comments usually have higher karma.

So why not make use of that by requiring posters to have a certain karma level before being able to comment on someone else's bug report? From what I can tell, it needn't be high; 50 points would be enough to weed out the vast majority of the noise, but still be low enough that anyone with a legitimate interest in helping on bug reports could earn with a fairly minimal amount of work, such as helping on answers.ubuntu.com or going through the full bug process following up on their own bug reports.

Perhaps it could be set up to kick in only after there are already a few commenters, so we don't get in the way of random helpers on bugs that would otherwise be neglected. In a way, this would be akin to the "locking" idea above, but a bit more targeted.

Other thoughts?

Essentially, a me-too storm is a bug report which accumulates a large number of confirmation statements from different people, to the point that it actually hinders progress.

Knowing that a bug affects additional people does have some value to it. I particularly appreciate it when someone of a technical bent is able to reproduce a problem, because I can have confidence that they can test out patches or at least provide insightful technical analysis.

However, past maybe half a dozen comments, the value of an additional confirmation drops off to zero. So, comments in a healthy bug report would shift from confirmatory statements towards comparing data, discussing workarounds, identifying test cases, proposing patches, and so on.

Unfortunately, with a me-too storm, the confirmation statements come in at a faster clip, and their quality often drops further. Commonly, the confirmer will not provide log files or other proof that they do indeed have the bug. This is a particular problem with X because often there are different unrelated bugs that have identical symptoms (examples include X freezes, black screens, performance degradation), and so they might have a different bug; by "me-too'ing" their bug instead of creating their own bug report, it means their issue probably won't be investigated, or it can cause massive confusion or even sidetrack the discussion away from the original bug.

The bug suffers from a bad feedback loop at this point. The more comments a bug has, the more "important" it looks to launchpad's search engine, so it gets suggested to anyone with vaguely similar symptoms. New commenters notice that some old commenters provided data already so they don't bother putting it in.

Indeed, after a while the bug report can start accumulating negative comments, that have a value below zero - they actually detract from the discussion. These range from demanding "is it fixed yet?" questions to rude, inflammatory or borderline threatening comments "fix it now or I go back to windows, you insensitive clod!!!1!" These predictably stir up a variety of 0-value follow on comments, "No, it's not fixed yet, please be patient," "yeah +1 for fixing this soon," "did you try rebooting? it helped me," "plz unsub me from this list, to many emailz," "'doze sucks, get a mac," and so on.

Now, no one would argue that "me-too storm" bugs are not important. Obviously with so many people commenting, there must be some real problem that needs dealt with. It could be a real bug, or a class of bugs with similar symptoms, or a usability issue, or even just poorly set expectations...

However, the stormy nature of these high comment bugs tends to work against themselves, for a few reasons. First, as a developer it's just plain time consuming to read through a gazillion comments. Second, these bugs can be hard to summarize and send upstream, particularly if analysis data is coming from different people (with perhaps differing hardware). Third, if you post a proposed solution, you often get feedback from people having unrelated bugs that leads you to make erroneous conclusions about the fix.

The "me-too storm" is a fascinating phenomenon, but since it hinders bug solution it is interesting to consider ways that this could be prevented or mitigated in launchpad. I'll share my own thoughts in a future post. Meanwhile, I'd love to hear other's ideas.

In some sense development have stood still for a while as I have focused on testing various devices and GStreamer features. Remuxing is still on my todo list, but discovered that for instance an ac3parser is still needed in GStreamer to
do nice DVD conversions.

Was kinda nice to successfully use Transmageddon for a business related need at work, we had gotten a request at Collabora Multimedia which meant I needed to transcode a video into quicktime+h264+aac from a .vob file. Worked like a charm I mean while I have of course done hundred of transcodes as part of development, it was nice to do one for something ‘real’