Once upon a time, we had a Trac keyword called "sugar-love," which was a marker that we used for "easy bugs, good for beginners looking to make their first code contribution." It was great, because when a coder came up to me and said "how can I help?" I'd simply point them to that keyword, and zoom - off they'd go. (Well, theoretically - there was usually some wrestling with jhbuild involved, but the target was at least clear.)

We do not seem to do this any more. There are still some tickets marked with sugar-love, but the keyword seems to have fallen out of widespread usage, and is also not noted anywhere on our Trac frontpage or on the links we maintain for those looking to start helping with development. As a consequence, when beginners come in eager to help, it's that much harder for them to figure out where to start aiming.

This is an opportunity for someone who would like to ease the way for new coders looking to get involved. There are many such opportunities -we just need to find them and run at them. Do you want more developers involved in Sugar? Are you a programmer who'd like to get involved in Sugar development but thinks the activation energy is just too high right now? For that matter, are you a non-programmer who'd like more programmers to get involved in Sugar development, and want to make it easier for them to do so?

If so, here's what I'd do:

First: Get a small group of new developers together - people who have at least a little Python development experience and are willing to be vocal testers for Operation: Make It Easier For New Developers To Get Started Contributing. (Possibly with a catchier name.)

You are a team. You're going to go through learning this together; you can swap questions and stories and tips you're finding, support each other in chugging through inevitable moments of frustration, chorus together to the rest of the community when you find something that Needs To Be Fixed that you should not be spending your time on. Your job is to make life easier for new developers, and you need to decide where your efforts there are best spent - sometimes you'll want to go down a yak-shaving chain, sometimes you won't. Finding your own balance and constantly telling people what that balance is and why is very important.

By the way, if you've written a 50-line Python program, that counts; everyone starting with Sugar development will have to learn more Python as they go along, so start from where you're at. Besides, if you can figure out how you can help, and document that process, you've just opened the doors for everybody else with your skill level to be able to contribute - so in a way, the less you know when you come in, the better!

Just make sure you're ready to be extremely patient with yourself - you're about to tackle a very, very hard problem. Making it easier to contribute to something can far harder than simply contributing to it - but also far more valuable in the long run. To make it easy to contribute, you also have to contribute, so if you set your sights on smoothing the road for others, you will learn how to walk down that road at some point along the way.

Second: Pick a first small project. Go to the sugar-devel list and introduce yourselves. Let us know what you're interested in, what questions you have, what things you've tried doing in Sugar Labs so far. Point to this blog post, if you want, to let people know you're interested in both contributing and making it easier for others to contribute. Ask for help picking a first project - or if you have an idea already in mind, ask if that makes a good first project and whether people can help you figure out a good first step. Seriously, ask! We're sitting here on-list waiting and dreaming for people to come and say those magic words: "What can I do to help?"

If you know how much time your group has to spend working on this, it's great to say that too - it helps us to know whether you can probably spend 2 hours a week for 3 months working on something or whether you'd prefer to spend a 40-hour week during your winter break sprinting on it instead. I'd say (somewhat arbitrarily) that for a first attempt you'll want to budget at least 4 hours of work, in blocks of at least 1 hour in length, where you can be on IRC (chat - ask about this in your introduction email if you haven't used it yet) and asking questions.

And please be patient with us! We've forgotten what it's like to be a newcomer, how hard it is to get started, how difficult (and exhilarating and valuable) learning to walk in a new world can be. We make assumptions, and sometimes we don't remember that this once was hard for us, too. We need you to teach us, and we need you to remind us what you're teaching us. Sometimes we are slow learners; please be kind. We're trying, too.

Third: Start running, loudly. Simply start working on your project and telling us what you're up to every time you do something. "I'm stuck on X, please help!" is just as valuable a cry as "look, it's working, TRIUMPH!" In fact, it's probably more valuable; if you post something and don't show how you did it, we can't figure out how to do it too, but if you post the blockers that you're hitting, we can learn from it as well. This way, when you solve your problem, you also solve that problem for everybody else. We need to be open-source in our practices as well as in our code.

That's the "start running" part. How about the "loudly"? Well, here are the ways we talk to each other right now (and you should, too!) Your to-do list for this:

  • Get on IRC.
  • Join the Planet. Try to blog about your project once a week.
  • Join the mailing lists for things you're interested in. Introduce yourselves. Try to write an update on your project once a week. An email that simply contains a link to your blog post and 2 sentences of explanation totally counts.

If there's something on this list you can't figure out how to do in 15 minutes, that is a bug. It's a participation bug, and it's our responsibility to fix it. Email iaep and report it. We will help you patch it. In fact, I'll personally take responsibility for making sure these bugs get fixed, so if you don't get a response from iaep within a week, drop me a line at mel at sugarlabs dot org with a link to your iaep thread, and I will Do Something about it. (Offer good until September 2010.)

Fourth: Welcome newcomers. "Wait," you say. "I'm new myself. How could I possibly do this?" Answer: it's simple. When someone else who's new posts to the list, or shows up in the chatroom, or otherwise encounters you in real life, you say the following:

"Welcome! We're glad you're here!"

That's all. You may want to follow that up with an introduction...

"I'm (your-name-here), I'm also new - I'm working on (your-project-here), we've just (something-you've-recently-done)."

...and possibly a few questions.

"What are you working on? Can I help you get started? If we can't figure something out, we can always ask the others. Do you have any questions? How did you decide to start getting involved? Do you want to help us with our project?"

You get the idea. Sometimes, it's actually better for a newcomer to welcome another newcomer - you've just been down the same road yourself, and can help others through it far better than us old-timers who have forgotten. So yes - as a contributor to Sugar Labs, helping others get started is your job as well.

Fifth: Say thank you.

We become what we celebrate. If we want to be a vibrant and growing community of contributors, we need to celebrate those around us who are doing the things we'd like to see more of.

If someone helps you, thank them. If they do something awesome - even if you didn't ask for that help, if what they did helps or inspires you - thank them. Tell them exactly why the thing they did is awesome, and explain the difference that it made to you, if you can. If there's room for improvement, give feedback to that effect - but thank them.

Alright. Start running, then. :-)