Posted
12 months
ago
While Javascript-centric, I think it applies to communities in general, and Free Software communities specifically.
I'm now thinking more about how I'm treating the shared property of the communities I participate with.
Posted
about 1 year
ago
In an effort to broaden my horizons beyond writing code, I've been reading a lot of business books lately. Coming from a mostly Free Software background, it's been an enlightening experience1. One thing sticks out the most: Processes matter, and
... [More]
they matter more than I ever thought.
It's common for me to contribute to random projects. Launchpad and Github and the like make it easy (can we get a Launchpad version of this shirt2?). However, I'm not likely to contribute to a project that has a HACKING document longer than any source file in the entire tree. If it takes me longer to figure out how to send a patch than it takes to write the patch, there might be some problems.
Here's what Brandon Hays says in his blog post Why I Still Don't Contribute to Open Source:
Guidelines often make a maintainer’s life easier, and mine harder. Yes, maintaining an open-source project is an arduous, thankless task. But I’ve looked at contribution rules/guidelines that turn a simple idea for a fix into a bureaucratic brick wall worthy of Microsoft.
Now, when projects grow large, processes are a necessity. Launchpad, for instance, has a good culture of code reviews and a relatively strong emphasis on testing. I've only heard war stories about what it was like to hack on Launchpad before those processes and guidelines were in place. I don't have enough fingers and toes to count how many times code reviews and testing prevented me from doing something insanely stupid in a proposed patch to Launchpad.
Processes aren't bad. We need them, sometimes to maintain quality, more often to maintain sanity.
Here's a personal example of a not-so-good process: Not long after Launchpad started putting more thought into how we use javascript (back in late 2008), we put together this process of UI reviews3. We already had a good culture for code reviews, and we wanted to do the same with UI. We started with one or two people who seemed to have a good handle on what good UI is, and we worked to train and graduate new UI reviewers. This seemed like a good idea, because we could gradually get everyone on the same page with regards to what good UI was.
We trained a handful of developers, and then interest waned in becoming a UI reviewer. Some people still attempted to get UI reviews, others would just ignore the process entirely if they could get away with it (and I don't blame them: attempting to get multiple reviews can be a PITA). It wasn't until a chat with Aaron Bentley that I realized the real problem with this process: We were inadvertently telling experienced Launchpad developers they didn't know enough about UI. In some cases, that was true, but in most cases, we were missing out on some great suggestions for good UI in Launchpad. Recently, Curtis Hovey proposed that UI reviews be discontinued and it was instantly ratified. Launchpad's UI has grown leaps and bounds since then.
The Patch Pilot program that the bzr team created is a perfect example of a process that promotes the Bazaar culture. One core developer takes a time out from his/her regular duties (slowing velocity) to help guide patches from the community. "Hey, we have a process for patches (and even a HACKING document, but don't worry if you don't know it all just yet. <developer> will personally guide you through the process."
Now, every time someone proposes a new process, I spend some time thinking about it more. How would this process affect culture? Is the proposed process in-line with the goals and values of the project?
Personally, I think it's best to choose people over process, but I also don't maintain any projects that have an abundance of contributors.
When in doubt, ask Zed Shaw.
1 The best book I've read this year was Harvard Business Review's 10 Must Reads: The Essentials
2 Seriously, I want one that says "Merge Proposal or GTFO" Maybe even get a picture of dobey scowling to go on the back.
3 I liked the idea of UI reviews. I'm also relatively impetuous, so it's to be expected. [Less]
Posted
about 1 year
ago
For the last six months, I've been working closely with Zac Bir on really polishing the web frontend for Ubuntu One. I thought I'd sit down and write a bit about what we're doing and how we're doing it.
I was tired of not having a very good
... [More]
way of reporting feedback and errors to the user. The error message doesn't have to be that complicated, and sometimes the feedback just needs to be enough to say "Hey, I saw your click, and I'm working on it, but it'll take an indeterminate amount of time." I didn't like Launchpad's spinner, because it forces heavy page reflows (and sometimes repaints!). I searched/experimented with this for a while before I came to a conclusion.
What you see above is the culmination of two ideas I'd been playing with for a while. Essentially, instead of having the spinner show up underneath what you clicked on (forcing the repaint/reflow), the spinner sits over the content. This is a problem in cases where we don't want to block the user while we do something, but in the case of the video, we do (we don't want them adding contacts while we're trying to find duplicates).
If there's a error, we have a nice error box that also doesn't reflow, sits "over" the contact (it's actually absolutely positioned), and reports the error back to us. I should also add that we kiped this look from Landscape. They've really by putting effort into UI sexiness.
Now, the UX porn is okay (it'll get better as we iterate). The best part (obviously in my opinion, but I wrote this so grain of salt and all that) is the API we're using to do all of this. It's entirely asynchronous and event driven.
For instance, here's what an io call would look like:
YUI().use('io', function(Y) {
Y.Global.fire('one:busy');
Y.io('/ajax_endpoint', {
on: {
success: function(id, response) {
/* Do your thing here... */
Y.Global.fire('one:idle');
},
failure: function(id, response) {
/* Do failure things here */
Y.Global.fire('one:idle');
Y.Global.fire('one:error', {message: 'An error occurred. We suck.', error: response.responseText});
}
}
});
});
Now, ideally we should be firing 'one:idle' in the 'complete' handler, except that complete executes after success and failure, so you can get some weird bugs that way. The end result is the same though: the user gets a friendly message, and we report the error to the server side to be dealt with in our error reports (this part is still getting ironed out, however). [Less]
Posted
about 1 year
ago
Every time want to create a YUI 3 Plugin, I always run into this same problem. I'm sick of forgetting this, so I'm going to blog about it, in hopes that it will help me remember. Here's my code until a few minutes
... [More]
ago:
YUI.add('formPlugin', function(Y) {
var FormPlugin = Y.Base.create('formPlugin', Y.Plugin, [], {}, {});
}, '1.0', {requires: ['base', 'plugin']});
This makes YUI very angry. What's worse is that it gets swallowed in YUI's error handling, so you don't even get good line numbers. The console spits out Uncaught TypeError: Cannot read property 'constructor' of undefined--It kinda provides hints, but it required me to get out ye ol' debugger to figure it out.
The problem is actually very easy. Don't extend Y.Plugin You should be extending Y.Plugin.Base, and the documentation says that, but I keep forgetting.
Don't let it happen to you. [Less]
Posted
about 1 year
ago
When confronting users with forms, you need two things: (1) simplicity, because your user is being hassled for information, and (2) clarity, because the user needs to understand why they need to give up this information. If these two criteria are
... [More]
not met, the only users you're going to get are really determined ones who will spend their entire time hating your app and looking forward to the day they get to dump it or you're going to get idiots who have nothing better to do.
I prefer to have awesome people use my software. [Less]
Tagged as
player audio feedreader mediacenter feed glade tv clutter movie music mp3 entertainment cd media rss_aggregator gnome movies players feeds video python sound rss linux dvd display media_player multimedia center cd_audio gstreamer avi viewer
KatchTV
OpenELEC - Media Center Operating System
XBMC for Xbox
XBMC Media Center