September 25, 2007
September 19, 2007
How Open is your Open Source project?
I've been trying to scratch an itch with an allegedly Open Source project I'm working with. I've spotted a few errors that I should be able to easily fix and contribute back to the project, but I'm hitting a wide range of obstructions to my participation.
From an Open Source perspective, the ability for new users to become contributors (and then committers) is key to the health of any project. After all, people are more important than code - without people, the code will fall into disrepair. You have to take care of the community of users and developers around Open Source projects if you want them to succeed.
My first attempt to contribute something to this particular project was to try and start a discussion of the bugs I found. Unfortunately, this project uses web-based forums instead of mailing lists, which I personally consider a barrier to the healthy development of (technical) communities.
As a developer, I spend a lot of my time in email, and by now I'm efficient at processing it. Mailing lists are a push medium (messages are sent out to everyone on the list), whilst forums are pull (you have to visit the web site and trawl through the forums to find out what's going on). There are many different web forum packages out there, and to learn how to use every one effectively is a time debt I'm not willing to incur. Web forums also require registration (and hence usually email address validation and additional usernames and passwords to remember), which can often take longer than mailing list subscription.
I'm willing to accept that web forums are the correct solution for certain communities, for example Moodle, and if I were to make a sweeping generalisation I'd say they are better for less technical groups of users. But I think for development you can't beat a mailing list (with issue tracker notifications and SCM commit messages, ideally).
My next attempt at contributing was to try updating the project's wiki to at least fix some of the documentation. I wasn't able to edit any documents without first setting up a user account, but that's standard practice. What really bugged me was that every time I tried to save a page I had to go through CAPTCHA validation eyetest. This is not a good way to encourage me to contribute!
My final attempt at contributing was to grab a copy of the source code, to build a copy of the latest code and then create patches to contribute back. Unfortunately the project's subversion code repository has a very quirky non-standard layout (even though best practice is documented well, for example Subversion Best Practices and Choosing a Repository Layout). The project's documentation explaining how to build the code was not up-to-date, and the build itself had undocumented dependencies that caused it to fail.
Given all these barriers, my project contributions will have to wait for another day. The worst thing? In most cases people won't even have enough goodwill left to report this to projects, so projects silently drop potential contributors. Thankfully I happen to be in the same room as some of the project developers, so I can take a shortcut, but this is not usually the case...
Technorati Tags: community, computing, critique, opensource, software, sustainability
September 18, 2007
On training
For the last few days I've been sitting on the opposite side of the fence to usual: on the receiving end of training for a change. It's been an eye opener, if only as a textbook example of what not to do. I know I've committed many mistakes when delivering training in the past, so I'm going to take this opportunity to make a few notes, to avoid these pitfalls in future and hopefully to save others from the nightmare of training gone wrong.
For training to be effective, the people being trained need to feel relaxed, comfortable and at ease with their surroundings. Help them relax even before they arrive: give them clear instructions on what they are expected to bring with them, where they should go, and what time they should be there. Explain your expectations and set their expectations. If the trainer is hosting, then the trainer should be there long before the first person is likely to arrive, to ensure a warm welcome.
People are usually investing a lot in training, so use their time properly. Kick off promptly, don't waste lots of time on off-topic discussions, and make sure the course is paced suitably for the audience. Have enough material, with a good balance of hands-on and tutorial throughout.
The most effective training is entertaining, interesting and all about the rapport between the trainer and the people being trained. It's important to establish that rapport right up front, and to maintain it throughout. The warm welcome when people arrive will help, but build on it with a good introduction: explain who you are and what your background is, and why you're the best person to deliver the training. Make sure you speak clearly and at a volume suitable for the setting.
Crucially, all the training should be delivered by one person. Swapping trainers throughout the course is disorienting, distracting and breaks the rapport. If you need to bring in subject-specific experts, use them for question and answer sessions or to help out during practical sessions, but not for delivering the course materials.
Make sure the course materials are well-prepared and thoroughly reviewed in advance. Don't expect your audience to spell-check, fact-check or otherwise debug the information you're supposed to be teaching them. Spelling mistakes, typos, and poor grammar get in the way of learning. Make sure the materials are relevant to the subject, and where appropriate, to the versions of software and platforms in use.
Don't forget best practice: teach people to do things the quick and easy way and they always will. You should show them how to do things properly from the start (especially where subjects like security are concerned).
Training is one of the few occasions where I'm happy to see dead trees: it's much easier to scribble notes on printed materials. And spend a bit of money on the materials: a few scrappy pages run through the office photocopier or inkjet printer five minutes before the start is no substitute for properly printed and bound slides and notes.
Provide suitable refreshments prior to starting the course, as well as tea breaks during the course. Make sure the breaks are evenly-spaced and that fresh refreshments are provided - nothing is worse than stewed tea or coffee that's been sat in a thermos for three hours. If lunch is held in the same room, make sure it's cleared away before the afternoon session: it's amazing how distracting the smell of stale nibbles can be after a few hours. Unless your material is insanely compelling, find an excuse for people to step outside and get some fresh air for five minutes half-way through the afternoon. A slightly longer tea break is more effective than a room full of snoozing people.
Test all equipment before the course starts, and then double-check. If possible, have backup equipment. If you're providing resources, have them handy in as many formats as possible (CD, USB key, network share, external hard disk, etc.)
Make sure the projection screen is visible throughout the room. If you have problems getting your machine to work with the projector, go buy a Macbook. Seriously. Nothing is more embarrassing than the random function key pressing or rebooting that seems endemic in the Linux and Windows worlds.
Make sure there are no distractions, such as noisy venues or people not involved with the course talking at the back of the room. Take all coins and keys out of your pockets, and move all clickable pens out of your reach, so you have no chance to be subconsciously jangling or clicking throughout. Maybe turn off internet access for delegates, though these days those with short attention spans can flee boring training sessions via 3g mobile data cards. It's better to focus on making the course interesting instead of worrying about competing with news and email.
As with presentations, avoid death-by-powerpoint. Don't simply read slides out aloud: people have travelled to hear your insights and background information, not to hear you repeat something they can read faster than you can recite. If you must use powerpoint slides, let them illustrate key points while you give deeper details, and make sure the information is also printed out so that people have a permanent record of it (don't make them scribble notes at the expense of listening and learning).
Oh, and the final rule: someone that wrote the code is not necessarily the best person to talk about the code. Never make the mistake of thinking they are the best people to deliver training!
Technorati Tags: computing, critique, linux, macos, training, software, work
September 17, 2007
back
... from Egypt. Survived minor setbacks like passport control queuing hell, a missing hotel room reservation and revenge of the hotel cuisine. Photos on Flickr.Technorati Tags: holidays, travel
September 9, 2007
Cocoon GetTogether update
So Gianugo and Simone have some fantastic stuff lined up for the Cocoon GT, and it's now time to spread the word and start signing up! The wiki is available for discussing hacking, hotel and apartment sharing, the Cocoon website is carrying the news, and there's a set of buttons for people wishing to advertise the event.
Technorati Tags: apache, asf, cocoon, community, culture, dining, hackathon, opensource, travel