Planet Olin

The Sugar Labs Oversight Board (SLOBs) has had trouble getting together on IRC recently because of everyone’s crazy schedule, so today some of us got together in-channel and got through the list of outstanding topics as best we could. It wasn’t an official SLOBs meeting – with only myself, Tomeu, and Chris Ball, we lacked quorum and couldn’t make any official decisions – but we moved things forward as best we could, because these issues are pressing.

Remember, nothing says that anyone (you don’t have to be a SLOB!) can’t move things forward, SLOBs-fu is only needed for the final formal vote! The full log is available, and I’ve added it to the list of past logs while noting that it wasn’t an official SLOBs gathering, for clarity. Here’s what we covered:

1. F11+0.88+XO-1.* as a SL project – Bernie had sent in a request on behalf of Paraguay Educa and Activity Central to make Fedora 11 with Sugar 0.88 builds for the XO-1 and XO-1.5 a new official project. It wasn’t clear to us what resources they needed; we pointed out that they could get infrastructure/hosting without being an official “SL project” (and indeed without asking SLOBs!) and asked what else they needed – trademark permission, etc? Tomeu brought up that SL projects were the ones that SL teams (Marketing, Design, Development, etc.) were expected to support, so it’s not clear that this would be the appropriate designation for the F11+0.88 builds – there may be a more appropriate upstream for the project to be under (Paraguay Edcua, Activity Central, OLPC, Fedora, etc.) and then SL could partner with that project instead of being the umbrella org for it.
2. Ooo4Kids logo display request – Ooo4Kids asked if they could display our logo on their “partners” page, but we’re blocked by not being able to find the original text of the request for this. If you know where to find this, or who at Ooo4Kids to contact about it, please let us know!
3. Trademark usage applications – A number of local labs have asked for permission to use the SL trademark, but again, we’re blocked by not having the original request text. If you’re from the Colombia, Paraguay Educa, Argentina, Chile, Peru, or DC Local Labs, please help us find your request!

Since all three of these are continuing discussions, and we’ll be continuing those discussions on-list, I’ve linked to those discussion threads from the agenda for next week. (The other two things on the list for next week are “Review of RM search” and “Motion and possible vote on Sugar certification,” – I am not sure what the latter means, so clarification would be great, what’s the motion we’re looking at?)

Question for all Sugar folks: what do YOU think the most pressing problems in our community are? That’s what SLOBs should be addressing – so please tell us what our biggest (non-code) bugs are.

Lessons I’ve learned today whlie hanging out in the Sugar IRC channel (#sugar) and want to pass on to Bao (a student from Arlington who’s hacking on the IRC Activity this week):

Cloning a personal branch for development is really easy and a good idea so that unstable changes don’t get pushed to mainline. This is particularly important for developers running the bleeding-edge sugar-jhbuild code, since it pulls directly from the git repos, so an experimental commit there could break things for them. (Fortunately, the IRC Activity isn’t pulled into sugar-jhbuild by default, but it’s a good habit to get into, for when you start working on code that is.)

It’s difficult to interpret text communications when you’re new sometimes. What an experienced developer may regard as friendly suggestions for improvement (that they’ve spent their valuable time helpfully trying to write up) may be received by newcomers as a big stick smacking them down and discouraging their project contributions. By default, assume that people are trying to be helpful and put forth constructive criticism because they want your project to succeed, and for you to stick around.

git config –global color.diff auto enables diff coloring in git. Pretty! Secifically, the diff coloring will show you EOL (end of line) spaces – they’ll display as red blocks. These EOL spaces don’t really make a difference when you’re tinkering with your own code, but when you start upstreaming your work, they make patches very annoying for reviewers and people trying to merge your patches in. In general, it’s a good idea to set your editor to remove EOL spaces automatically.

Thanks to Sascha Silbe for teaching me (and others in the channel) about this stuff today. Sascha writes:

“I can remember the pains of going through the SL review process for the first time rather well, so I try to make sure new contributors learn how to do it ‘right’ early on. It means a lot less work and less waiting on yet another review iteration.”

I’m writing this up because I find that teaching something to someone else makes it more likely that I’ll learn it myself, and this is all stuff that I want to learn. Mm, hacking-fu++. Thanks, Sascha. This is the kind of knowledge-spreading that we need to do with new contributors in order to grow our capacity to hack on things – it’s how novice hackers (like myself) learn how to be productive.

The Sugar Labs Oversight Board has been talking about 2010 goals; I wrote down a first draft of mine and wanted to toss them out here (hey, release early, release often!)

My personal views on annual goals for Sugar Labs: Rather than having overarching goals set from the top-down that everyone in Sugar Labs runs towards for 2010, I’d like to see individuals within the community state and document their own individual goals for 2010, so we can easily find areas of intersection-of-interest that would advance the mission of Sugar Labs. If enough individuals pick up on the same goal and then pool together to accomplish it, then it becomes a de facto “community goal” – but one formed organically from the bottom-up, rather than from the top-down.

In that vein, here’s my current thinking on what my own goals within Sugar Labs for 2010 might be. This implies stuff that I am willing to take responsibility for – I plan on being involved in driving each of these goals forward.

1. An average contributor should be able to participate in SL on a minimum of 4 hours a week – that’s 1 hour for a team meeting, 1 hour keeping up with lists, and 2 (or more) hours actually doing stuff. (Prerequisite: having weekly team meetings, having all conversations for a team logged to its mailing list, etc.)

This goal could probably have a better final wording, but my intent is to make it so that when you decide to join the Sugar Labs community, you can quickly (without needing to spend weeks soaking up a lot of context that us old hands tend to take for granted) settle into the rhythm of a smaller group you can quickly get to personally know, that will mentor/coach/support you.

I’m currently stepping towards this goal via my work on a small local SoaS deployment (we’re waiting for the final administrative approval needed to announce it and make all our notes so far transparent – hopefully that will happen tonight; lack of transparency is totally driving me nuts, so it’ll be a relief for this to get resolved). We’re trying to keep the time commitment low for everyone involved, while still maintaining strong links between everybody in the project – it’s a small sandbox within which we can experiment with collaboration. This is only a start, but it’s a start.

2. A regularly occurring, annual (to begin with) and planned far (more than 6 months) in advance, Sugar Camp. We need a rhythm for our community to settle into, and since we have a much larger percentage of non-technical contributors than many open source projects do, we need to set our heartbeat around something broader than our software release cycle. More on this later.

3. Listen. Too often I sprint hard on Getting Stuff Done and shouting out as much of what I’m doing as I go along – which is all wonderful, but has a missing part that I sometimes forget. Listening. Finding out what other people are doing, echoing/reflecting/summarizing it back to make sure that I understand, and then – if there’s a chance to do so – finding those small opportunities for synergy between my work and theirs. I need to take more time to find out and keep up with what others are doing, ask them what they’d like, what sort of help they need.

This is actually something that’s motivating my second goal of having Sugar Camp – what I want from such an event is a way for all of us – at some point in the future that we can all aim for and schedule in – to come together and take a breath all at once and share and reflect on what we’ve been up to.

Those are my thoughts, more or less braindumped at the moment (though I’ve been mulling these in my head for a few weeks before forming them into written English sentences). What are yours?

First, a non-SLOBs update: a number of us (led by Walter) are working on a grant proposal for the MacArthur Foundation’s Digital Media and Learning Competition. It’s due at the end of the day – if you have a moment to read or edit or comment on the proposal, we’d greatly appreciate it.

Now: what’s up with SLOBs?

Finances:

Walter has written more notes on the state of our finances, but the short version is that we’ve got about $7000 USD discretionary funds and really need someone who’s not on the board to step up and be our financial officer for… well, ideally, a year, but I’d be happy with an interim volunteer for 2-3 months, which would give us time to figure out a better long-term solution. Email slobs AT lists DOT sugarlabs DOT org if you’re interested or know someone who might be.

Infrastructure:

We approved $300 for shipping of Wikipedia’s server donations – and since those machines stand a good chance of letting us not need to buy a $3000 machine, we deferred the motion to spend $3000 on that (the Infrastructure team will re-request the funding if it turns out that the Wikipedia server donations don’t remove this need after all).

Trademark:

We’re moving forward on the trademark process – here’s a background briefing on the current state of our progress on it, and we appreciate everyone’s patience (and simultaneously, everyone’s impatience, as it keeps us moving forward!)

You can help us with the next step, which is generating trademark case studies. There are instructions on the page on how to contribute – the wiki page we’re editing is called [[Trademark case studies]]. As I write this, the page is still a stub, but Sean Daly will be filling it in with a template and examples and instructions on how to contribute shortly (but feel free to leave notes and links there anyway in the absence of those instructions – we could use data to put through that process once Sean puts the process up).

That’s it – Walter should be posting meeting minutes/logs shortly.

From a thread on iaep some of you may have already seen – administrative stuff below. I’m trying to make it as interesting as possible, believe me.

In an attempt to line things up so that we can get efficiently through Friday morning’s meeting (and, I hope, nail those Trademark notions through), Walter, Bernie, and I started a meeting prep page.

It’s got handy-dandy background information references, discussion points, budget proposals with rationale, draft motions to be proposed after discussion points have been worked through, probable follow-up actions for if a motion passes, and the like. There are some missing bits we could use to improve this document so we can really CRUSH THINGS! on Friday.

1. Walter uploaded a quick status update on finances so we don’t need to spend a lot of time coming up to speed on the state of things at the beginning of the meeting. Where do our finances stand? Do we need to worry about taxes, etc? Any impending invoices? Who’s responsible for keeping track of this, where are they filing things, and when are we regularly checking in on financial matters? That’s all set for now. What we need is a volunteer to step up to continue keeping track of these things for the next 9 months. We’re in need of an interim treasurer until the next election cycle; if you’re interested, please inquire on iaep, in a response to this post, or somewhere that will give us the ability to contact you about this. If you know accountants who’ve been interested in open source but thought they couldn’t contribute if they didn’t know how to code, here’s a good opportunity. *wink*
2. Are we missing any discussion points for the trademark issue? Chris has already found a bug, which has resulted in a proposed code commit and a subsequent patch. Help us find more!

That’s all – thanks for your patience, everyone! Thoughts/comments/patches/flames extremely welcome.

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. :-)