All posts by rbowen

Too many beginners

Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.

 

 

Project Leader

I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:

A healthy project has a visible lead(s). Who is the project lead(s) for this project?

This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.

Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.

There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:

  • What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
  • What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
  • What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?

A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.

But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.

BAHA 5 Power

Back in December I received my replacement hearing device, the BAHA 5 Power.

The photo shows the last three generations of the BAHA. The one on the left i the one I was replacing – the “Intenso”. The one in the middle is, I think, the BAHA 3, which is what I had as a loaner while waiting for the replacement. The one on the right is the 5.

One of the features of the 5, which makes it practically magical, is that in high noise situations it can make it possible to hear voices. I was a little skeptical, but I had the first opportunity to test this on Friday night when I attended a gathering of Asbury Math department alumni. The room was very noisy, and I turned on the “noisy room” setting. For a moment, everything got a lot louder, and then after a few seconds – I presume it had to calculate ambient noise of whatever – the roar  of the crowd lowered, and I could clearly hear the person next to me – professor Ron Welling, who taught me Abstract Algebra back in 1991 or so – and understand his words.

I’m reminded of meeting Vint Cerf, and his wife, in 1996 or 1997. Someone asked him to think back over the technology advances in his lifetime, and say which one was the most amazing. Rather than talking about the Internet, he said that the most amazing, almost magical, was his wife’s cochlear implant, which let her hear and understand speech, after decades of hearing nothing. At the time I had a Xomed Audiant, which was a very early generation of what I have now.

Each generation of this technology gets more amazing. The new one even does Bluetooth! But the voice enhancement and noise reduction is truly amazing. I expect it to make attending conferences much more bearable.

 

Anansi and the Gum Doll (recording)

I haven’t done these in a long, long time, but I just found a book of Anansi stories on Amazon, and I’ll be posting a few of these a week to practice for the interviews I need to do over the next few weeks.

So, to start, here is ‘Anansi and the Gum Doll’.

Those of you who grew up somewhere other than Africa might recognize this story as being the same as ‘The Tar Baby‘ which is the Uncle Remus version of the same story. Most of the Anansi stories have a matching story in Southern US folklore, although for a variety of reasons most of these have picked up racist overtones over the last 200 years. This is one of many reasons that I prefer the Anansi stories.

 

White Teeth, by Zadie Smith

White Teeth, by Zadie Smith

I just got done reading White Teeth, by Zadie Smith. I read it because I heard her acceptance speech for an award for her latest novel, Swing Time, and she was brilliant.

I recommended the book to my family before I got very far in it, because it was obvious that it was going to be a great read. I love books that are about the complexities of multi-cultural relationships, and “third culture” kids. That is, kids from one culture, living in another, and not truly part of either.

However, it quickly became obvious that it would be … uncomfortable to think of having recommended this book to one’s mother, as the subject material is often somewhat, shall we say, off-color.

Anyways, the story did end up being very beautiful. But like real life, it was also very ugly. And very sad. And very happy. And tragic, and funny, and … all other manner of contradictions. It also had the most beautiful ending of any book I’ve read for the last year, at least.

So, while I do indeed recommend the book, I can’t guarantee you won’t be offended by the subject material, since it does go out of its way to offend on matters religious, ethnic, moral, and political.