I gave my presentation on "making your first open-source contribution" in Tog yesterday evening and I think it went down well; I enjoyed delivering the talk and received positive comments about it afterwards -- although I do need to speak louder. I'm enjoying lightning talks! Now, what to speak about next... :)

The slides are available on Slideshare (or PDF). I also gave a hand-out to give people a chance to check out the links afterwards.

- - -

On another note I think an evening of lightning talks was generally well received, and there is some motivation to run another similar event in 2 months. I'd love to have this be a regular thing. We need to be more strict on time-keeping though; surprisingly it seems people tend to feel bad for not speaking long enough, so they start just talking about random stuff or opening web links of cool things to show off... and interesting or not it feels like it's dragging on, particularly when one knows there's 3 or 4 more talks to go after.

I also got feedback from first time visitors that starting late "because people will be late anyway" makes it very sucky for people who don't know anyone yet, and also less likely that there'll be time to stick around after the talks to chat with the speakers and other attendees. I think we should start right on time next time (and to be fair, the 2 or 3 people who arrived between 7:00pm (announced time) and 7:30pm (actual starting time) were members... Not worth waiting for!!). It'd be nice to start on time and then encourage people to stay with drinks and cookies, or otherwise we need to find a social butterfly that is good at integrating people. :-)

Writing this down now, so that I can remember it in 2 months. Any other comments on the evening from people who were there, or general suggestions and tips on organising lightning talks?

(Irish Hackerspaces Week isn't over yet! Check out our other events.)

Link: talk description and video

A lot of user questions for the Google Code project are along the lines of "how do I hide code until it's ready", "how can I wipe the history and start from scratch" and so on: they are about people's insecurities.

When you have elitism and anonymity, suddenly everyone is elite. There's a whole mythology that gets built around programming heroes (Torvalds, van Rossum, Walls).

There are no genius. The only thing this has created is a fear of showing mistakes. This insecurity inhibits progress, makes the process slower, brings lower quality and a lower bus factor.

Avoiding the trap

• Lose the ego
• Criticism is not evil: give and take it politely. You are not your code. People criticising your code are not out to get you.
• Embrace failure (just don't fail the same thing over and over!)

The speaker shared an interesting story (probably an aphorism?) of an executive that makes a mistake that costs his company 10 million dollars. The day after, he starts packing up his things and when the CEO summons him to his office, he's ready to hand in his resignation, saying there is no need to fire him. The CEO replies "Fire you? Why would I do that? I just spent 10 millions dollars training you!"

• Iterate quickly
• Practice is key
• Be a small fish, as in don't be the smartest person in your company. You'll learn much more and faster
• Be influenced. "Alpha" programmers think they know everything and won't ever listen -- you may find that you actually gain more influence, by being willing to be influenced!
• Be vulnerable, repeated vulnerability becomes a strength long term.

Tools

Tools won't solve sociological problems, but they may influence behaviours. Pay attention to the tools, they can influence culture and moral, for instance by encouraging "cave" behaviour where developers work on their own for a long time and dump a big chunk of code: it's bad for collaboration, reviewing, etc.

You don't need to hide a project until it's "ready." Simply don't advertise it. People may find you because they are looking for something like this.

Don't let people collaborate until it's too late: they may help with code reviews, or pointing out to you existing libraries you missed. If it's too late in the project, they have no possibility to drive, to be a strong part of the project and it's less likely they will contribute.

Certainly get a prototype ready, some running code and some design, but let it still be something that you're happy to step back on.

Conclusion

• Don't try to be a genius
• Collaborate early and often
• Pay attention to default behaviours (the ones encouraged by tools especially)
• Pay attention to timing

...and if you do all this, people will think you're a genius!

Some of the questions/responses

Make sure to write a manifesto with the direction you want for your project from early development, so there are no major clashes or misunderstandings later on when people get involved.

If you don't care about credit, wow will you go places. If someone "steals" your idea and they have more reach (e.g. more clout/connections), it's great! It means it's more likely the idea will be implemented, and you'll have more ideas anyway.

On influencing a new team you just joined with best/better practices: start by doing good work and building up a good reputation, then you get to pay it back on something you believe matters. You have to choose your battles, you can't step in front of every train (resistance to change is like a very fast train! Hard to stop.)

I've been having a great time perusing through the PyCon 2011 video archives and watching some of the talks. Turns out most of them are 30 minutes long, which is a lovely amount of time -- a bus journey, a late afternoon break, etc, and exactly the length of my attention span :-)

Here's a link to an excellent talk on growing your community of contributors, with actual tried-in-real-life examples and how and why they work and what you can do to improve your own project. In case Python's not your thing, it's actually not very Python-specific ; there are many examples from different communities (Debian, OpenHatch, ...)

PyCon 2011: Get new contributors (and diversity) through outreach by Asheesh Laroia.

"Diversity" sort of remains in the background of the talk, rarely directly mentioned, and I think it makes sense. If you spend the time nurturing new contributors and making sure to create an environment where it's ok to learn, you're more likely to get people from different walks of life showing up.

Eek! Looking through my old drafts I can't believe I forgot to post this. I was waiting for the LWN link to become available to all -- but I guess it's never too late to share the awesome.

Article: GUADEC: Banshee project reaches out for contributors (LWN)

This is the summary of a very good talk, "Inside the Banshee Awesome Factory" from last GUADEC, describing a number of things that the Banshee project does to attract, welcome and nurture new contributors. For instance, they make sure to make plugin development fun, by automating away the boilerplate code -- kinda similar to starting a new project in Django (I wonder if that's something Sugar could use, to create new Activities...) Every contribution is equally appreciated, including the "typo" fixes that many people would start with. They're not afraid to welcome people with little programming knowledge, and walk them through how easy it is to fix a bug or add a new feature. I suspect this works fantastically to also attract good people who are not overly confident in their skills. The speaker wasn't scared to live-demo how easy it is to add a new feature, particularly if it's similar to something existing -- actually he was a very good speaker, if you have the time you might want to catch the video of the talk itself (day 3, Paris room, 10:15-11:00).

A very cool stat I forgot about, that's in the article: in the last 2 years and a half of development, Banshee has averaged one new contributor every week. That is awesome! It's worth looking into what it is they're doing right.

I just got home back from Berlin, where I participated in my first HackFest.

First day, first impressions

I was about 6 hours late for the first day, mostly due to weather related delays at Dublin Airport. I would have been a little late anyway (not enough days off left to fly in on Wednesday), but once there I quickly realised how beneficial it would have been to arrive a day early, attend the Welcome Dinner, and get to know people (at least names!) before trying to work with them. Lesson learnt for next time.

The first day was mostly discussions and planning what should be done, and toward the end assigning tasks to people for the following days. The whole HackFest thing is very focused, that first day was a lot of nerdy discussions except with a focus on getting things done (and thus not much patience for staying off topic). People were also careful not to make decisions for the whole community.

During most discussions, a few people were dominating/leading the conversation, which I wondered a little about at times. Some voices sometimes got ignored because someone louder started speaking or answering a question over them.

Being late meant that when a couple of topics I have an interest in came up, I didn't have yet a good enough grasp of the group dynamics to be able to chime in (my fault for being late and not speaking up anyhow). For instance someone mentioned the idea of a "Kid's corner" in the documentation for school students to learn about Gnome development. That's a topic dear to my heart, and what an awesome idea! There was no time to work on it during the HackFest but in case the idea surfaces up again I hope I will be around to listen in and participate.

In the end, the main plan became to work on a catalogue of "cool" demos to show and teach about different aspects of the platform -- first applications at a level a little bit above "Hello, World", for developers to try and expand on with their own cool ideas (the licence for the code in the documentation will allow for this, of course). Some people worked on other cool stuff.

The HackFest continues

I kinda messed up day #2. I can't help with writing code examples because I wouldn't know how to do most of them yet, and I haven't internalised best practices in Gnome Development either. So I kinda hid instead (I still had a good time! But I felt bad for not contributing enough).

I could have helped with writing, but it turns out most people wrote at fine to awesome levels all on their own already :) That left me with trying out tutorials and reviewing them with the fresh shiny eyes of a newcomer to the platform, which required the tutorials to be written first.

From day #3 I started jumping on people as they entered the office and constantly asking "Do you have anything you'd like me to look at?" so people knew to send things my way. Turns out some libraries (like libgda or webkit) couldn't build this week due to changes in gtk3 and I ended the day with Gnome Shell not starting on my machine, GStreamer behaving in the strangest way and also a better knowledge of Jhbuild ("Erm, could someone with a few minutes help me understand a Jhbuild issue?" - " *laugh* You do realise the maintainer is sitting besides you, right?"). Things merrily continued till the end of the last day, and I managed to test and review several tutorials and increase my knowledge of GStreamer, Javascript-the-Gnome-way, Clutter and Gtk, as well as learn about Mallard (the real question being, MAllard or mallARD?), glühwein, and how to say croissant in German (that's "croissant").

Sometimes someone would bring up a topic of conversation (intro to Mallard, what to include in the platform overview, how to revamp developer.gnome.org, ...) and people would assemble around the table, maybe use the projector and discuss what direction to take.

People did a beautiful job with the demo examples I got to test. They are simple, well explained, quick to try out and you do learn a lot when you go through them, while usually still getting a hint that there is more awesomeness to find if you dig further into Gnome. Most of the problems I encountered won't be problems when people run the examples on a stable Gnome 3 system in the future, as opposed to an active/fluid development version within a sandbox. I kinda failed at being a good representative of Python-as-a-first-class-citizen though: no example was completed in the Python language over the 4 days! C, Vala and Javascript will be nicely represented though.

People are very much "Work hard, Play hard" in a hackfest environment. Thanks to our Openismus hosts we got to work in a nice office, be introduced to lovely restaurants and visit a Christmas market among other things. People would go out at night and then come back to the office around 10 or 11pm and work longer into the night. I never stayed that late (happier working in the morning, as strange as it may be for a hacker).

As with my GUADEC experience, the Gnome folks are an incredibly nice bunch, very welcoming. An interested newcomer dropped by unannounced on Sunday and was taken under someone's wing to work on documentation tasks, mentor within arm reach.

I suspect it might have been a tad too early for me to attend a hackfest though (considering my lack of experience with the community and in general), even though I came here as one of the main targets for this documentation effort -- the Hobbyist, happy Gnome user and eager wannabe contributor. I'm still glad I attended and jätte-happy with my experience, and I hope my comments and feedback on the examples were helpful. Perhaps that is something I can keep helping with.

It's proven difficult to write up a summary of my experience as someone-who's-not-a-hardcore-open-source-contributor-yet-but-certainly-plans-on-becoming-one. There's an easy dialogue-killing answer to any anecdote I relate: "suck it up." I'm still trying to find a way to express all this though, because I'm sure there's something to learn from any newcomer's attempt to join a project, and also for my future self, when I'll be the one encouraging others to get involved with open-source and won't remember what it's like to stand on the edge, trying to understand how a community functions and how to find a space that fits you in there.

So. Two anecdotes on contributing to Sugar, then a description of the incredible level of confusion I've been experiencing looking at the development process overhaul, followed by some ponderings on "what's next" which I better follow up on in the future :)

Anecdote 1: Fixing a bug (InfoSlicer)

Sugar (and the XO!) had been on my radar for a while. Last summer I finally made the time to set up sugar-jhbuild on my laptop and start trying it out for myself. I was enthusiastic but despite the very good wiki I wasn't sure where I could make myself the most useful (Sugar core? Making a new activity? Fixing activity bugs?). I find fixing bugs to be a fantastic way to get familiar with a project and a code base, however I wasn't sure how to pick one because every ticket in bugs.sugarlabs.org is already assigned to someone. It wasn't obvious to me whether I was welcome to work on any or if there was some sort of "please may I work on this bug" process or if assigned people might be protective of their code (I've met a few virulent "It's my code/my bug!" people before, albeit mostly in college.) The sugar-love bugs were few.

Enters OSS BarCamp in September 2009, where I met Laura Cowen (thanks Jaime for pushing me to introduce myself!) who presented a lightning talk on a Sugar activity, InfoSlicer. Having met with a real person who was enthusiastic and sort of involved with Sugar, I thought I'd take a look at InfoSlicer. There was only one bug filed against it at the time, that quite seriously limited the capabilities of the activity. I set out to fix it. A few weeks later, I was attaching my patch to the ticket, discreetly sweating over the associated comment. Someone replied less than a day later, suggesting a different approach inspired after another activity I hadn't heard about and before I had come back from work that same day, the current maintainer had accepted my patch and also suggested another way to do it that we could work on together. I was double-elated and thanks to the "we" felt very welcome.

Unfortunately I hadn't enjoyed a lot working on the parsing code for InfoSlicer and despite promising myself I would update the activity with the new toolbar "soon" I didn't get back to it (yet, shall we say. I'd still like to do the toolbar thing sometime.)

Anecdote 2: Fixing bugs (Pippy)

'round the same time I had volunteered to show cool engineering things to a transition year (high school) student spending a few "work experience" days in my workplace. Although he was a bit older than the Sugar usual demographics, I gave him a usb stick with Sugar on it anyway: Sugar is cool and we all had unrealistic expectations of what a student could accomplish in a week. I thought perhaps he could get familiar with the project then investigate a bug. After he showed some curiosity about programming, I stirred him toward Pippy which he enjoyed greatly despite the occasional stracktraces some examples were invariably throwing up.

Most of these issues had already been reported so I thought, "I love Pippy, I'm gonna try to fix as many as I can." Along the way someone I know got a bit hyped up by my enthusiastic chanting of "Sugar Sugar Sugar" and had set out to fix a serious display bug in Pippy, #347, despite not being particularly fond of Python. I fixed a couple of other bugs, attached the patches to the relevant reports and hopped away, waiting for a review or update. Months went by. My friend lost interest. I began to pep myself up to ask about the Pippy maintainer on IRC. At the time I was trying to build up some confidence by getting my work accepted first before going about and expressing opinions or asking questions in public places (not the way people usually prefer things to be done in open-source, I realise.)

A series of coincidences happened and I suddenly was offered commit access to the Pippy repository (I mentioned that before.) Despite the best intentions, I wasn't comfortable pushing my patches to the mainline merely because I had the power to do so ; I find it preferable and better for patches to be looked at and approved by people who know what they're doing. Eventually I pushed #843 myself into the mainline, as Chris Ball kindly reviewed it as part of an email thread. I still didn't feel so good about it, managing the statuses in Trac was unclear (both status + resolution must be marked as fixed/resolved?) and the bug never ended up assigned to me (it looked like Trac's button would change both the status and assignee so I wasn't sure and then it was too late, I didn't want to revert the status back.) Basically, as I've stated before, I was still in dear need of a mentor, and I still didn't reach out. I fully understand and accept that this is my fault for not communicating well enough with the community.

Another bug I had worked on, I didn't fix correctly the first time around. When this was brought up I responded quickly, explaining where I thought the issue was and submitting a second patch a few days later. I won't be pushing this to mainline until someone else confirms it works, but I'm still happy with it because I proved (to myself, too) that in case of problems I am responsive and able to correct issues within a decent timeframe.

Meanwhile, I was also getting fidgety about #347 as without it, Pippy is impossible to use on my Eee and likely on other netbooks. Eventually I asked, still within the bug tracker, if people would mind if I pushed the current (working) patch to the mainline. Other unrelated requirements had come up in the bug report discussion, much less serious than does-not-work-at-all-unless-patch-is-applied so it felt fair to push the partial patch. Lots of people had popped up the first time around and subscribed to that bug, but there was no answer.

Not long after, someone submitted a duplicated patch to fix #347 as well as the other unaddressed aesthetic issues, using a new process still being defined. The patch got reviewed, no one mentioned the duplication (I didn't either) and soon after the patch was pushed to the mainline and the submitter became Pippy maintainer (yay! At least Pippy now has a more active maintainer, hopefully!)

It's great to see movement on the Pippy front but I felt so disheartened by the duplication of that patch that had been sitting there for 7 months and that I had to install manually on every stick I made for the past 7 months. I invested so much energy running in circles like a headless chicken, trying to do things right with my shiny commit access and waiting for feedback. I was very discouraged, the basic lesson being: I shouldn't have cared so much, especially when I knew I hadn't fully groked all the processes yet. This only (mostly?) happened because I did not reach out to the community through other channels than the bug tracker.

The new process

While I'm at it, I'd like to mention what's going through my mind with regard to development process changes that SugarLabs has been setting up lately. Sugar is basically moving toward a mailing-list only style of communication to submit patches and I've been endlessly confused since this started. I'm not sure it's the most inclusive process either though I understand the problems it's trying to solve -- mostly lack of code reviews as illustrated by anecdote #2 :)

I think it's more confusing than it used to be and makes the barrier to entry higher because as far as I can tell, now if I or anyone want to fix a bug:

• I go browse trac and find something interesting/that I care about to work on
• Now I also have to search through my inbox and patchwork (a new system I haven't totally figured out yet either, but it doesn't look any less confusing than my inbox with every patch/email thread thrown in there together) to see if the bug is already being worked on
• I need to join the mailing list to submit my patch (I'm assuming, but it's probably necessary if you want to be sure to get the answers) -- that's quite intimidating and a commitment for "just" a patch. The process should also be easy for passersby if you want people to stick around.

Reading the mailing list and the patches as they get submitted is also confusing because it's difficult to link a patch to a bug and understand the background/context. In most cases you'd have to go and dig it back up from the bug tracker.

I know people are working on it at the moment, so I will wait for the wiki to be updated with clear instructions on how to effectively use the new process and systems, as the wiki still only describes how to work with trac. For now I'm watching perplexedly and wondering if really, the mailing list will be the only way for people to contribute in the future? I worry that the new process is inspired from projects that focus on hardcore technical people (Linux kernel) rather than others that also welcome passionate beginners (Dreamwidth).

Other valid solutions were proposed to fix the patch review problem and I wish I had found the bug on re-creating a "patch need review" automatic weekly email so I could have tried to do my bit to help. Great Sugar contributors believe in the new process though, enough to invest their time setting it up and setting up the tools to make it work more conveniently. Now that I've finally written this post and digested what happened and where I messed up, I should be able to focus on how I can help the project with other contributions.

What now?

Step back, start from scratch with a clean state of mind. Probably stay away from code contributions for a bit. Talk with the community. Stop messing up brilliant opportunities when introduced to cool people by email ;) Be more pushy when it comes to asking for feedback.

Looking at the releases notes surrounding Fedora 13 and Mirabelle make me hopeful: the Sugar on a Stick (Mirabelle) wiki pages are awesome, vibrant with optimism and that sub-community within the community sounds like a great way into main Sugar. Quote from their wiki I love: "When you're stuck, and have spent more than 15 minutes trying to figure out what to do next [, email the mailing list / ask on IRC]." The weekly meetings where newcomers are welcome sound like a good idea as well, it gives some structure rather than let new people break into the main group on their own (or so I imagine, I wasn't able to attend the first meeting last Monday.)

Through a series of kinda mind boggling coincidences, meeting people and talking about what I have in mind and am passionate about, earlier this month I ended up with commit access to the Pippy activity (a Sugar application). Wow! Awesome. A few weeks back, I had decided to fix as many of the broken examples as I could after getting a bit embarrassed showing off Sugar to a teenager, last October. He was very interested but as we were using Pippy it felt like we were getting stack traces a bit too often (they weren't that many really, they just happen to be more memorable.)

So I fixed them and the patches sat there for weeks (I didn't set the "need review" flag to be fair, which I just discovered in a corner of the wiki last week), along with a patch not-from-me in #347 which I think should really-really make it into the next release because Pippy is completely unusable on my (all?) netbook without it.

Now, I've been granted the Power Of The Commit so it should all be fine, with me committing away and happily making the world a better place... but it's not so simple, because really, I'm still living too far away from the community to understand how they work and notably here, the interactions with and within the bug tracker. For instance, I didn't realise you were supposed to add the "r?" keyword when submitting a patch, I found it accidentally when looking for something else in the wiki. I'm not a maintainer either, so it's not entirely clear what I should be doing with the bug report after submitting a patch or the process to follow.

Although my patches are tested and too small (I believe!) to actually do great damage, I didn't commit them... which ended up being a good idea since one of them was incorrect :) Someone kindly commented on the bug report saying it didn't work, with details. Turns out I was so keen on removing the stack traces I didn't check if the error messages provided by other Pippy examples were actually correct (so I display "install this" instead of showing a stack trace, but the "install this" doesn't actually solve the issue for that example, nor for the example I took it from.) I've now attached a new, better patch to the report (...and set the proper review flag!)

It's probably a tad too early for me to have those commit rights, just yet. I need a mentor still, except individually everybody is incredibly busy being awesome already, which is fair. The truth is, I already have a mentor if I reach out to it: the community. So this is always something I will be working on in parallel, I really want to integrate with the community. It just takes time for someone not so comfortable with the "public speaking effect" of pouring thoughts, mistakes and ideas on public, sometimes archived mailing lists and channels. I'll figure it out, at my own pace. I have access to some pretty cool people individually in the meantime if I really need help. My first area of focus is grokking the bug tracker so I can contribute effectively there.

Sugar stuff I want to figure out:

• How to know when a patch is big enough to warrant the "r?" flag, or really should they all have it?
• The complete process for submitting a patch. Right now, I think, a lot of the information I am looking for is under the "Code review" wiki page which makes it not obvious to find, and it's still not a clear step-by-step process. As I progressively get a better understanding of how things work I'd like to improve on it and/or eventually make a case for a "Submitting patches" page aimed at brand-new contributors, ideally "drive by" contributors too. I'm thinking of something along the lines of Gnome's "Submitting patches" page, or Gnome's project specific guidelines, which I found really useful when I was getting ready to make my first open-source contribution.
• Find out what developers do with bug reports, the best practices. How keywords and the 5.000 status/milestones/etc fields are being used and who gets to set them. I suspect there's probably an established set of guidelines for Sugar core, and that activity maintainers kinda do their own things, but still, I'm sure a set of best practices has emerged, somehow, somewhere. Usually triaging guides are pretty good at indicating how the status field should be used and what it means up to a certain point (usually, up to when the developer takes charge of the bug which is when I started getting stuck) but for Sugar, what I've seen so far doesn't seem to match the wiki (for instance there are a lot of bug marked assigned that aren't being worked on, and I suspect they just automatically get assigned to the maintainer or something like this. To be investigated further.) Also for the non-creator/non-main-maintainer of a component, is it ok to simply close off a bug after pushing a patch, even if no one else confirmed it worked? (I guess any problem will bubble back up to the bug tracker anyway, eventually...)
• Code freezes. We're in one now, but I'm not sure how this impacts activities or if this is mostly about Sugar core, and when/which/how a version of an activity is selected to be shipped with the current release (and does that differ for "main"/fructose activities like Pippy?)

This article is about a year old, but it doesn't matter:

(Diaries of a Core Maintainer #6:) A tale of two developers

Re-reading that story is always a bit scary and cause for self-reflection because my approach is so similar to Pat's, particularly when starting out with a new idea.

I could say I'm posting this now for people considering getting involved with an open-source project but afraid to jump in, or ask questions, or wondering if they're good enough, and that's usually what I send it to people for but... this time, what I really want if for more people to know about it, so they can send it back to me when I really need it! It's okay not to know everything or get things perfectly right the first time. It's ok to learn new things along the way.

For nearly two weeks, I've been sitting on a (tested!) Sugar patch because I don't fully understand the intricacies of "why it actually works" (xterm magic, there'll probably be a post about that soon!). I probably still would be digging into the entrails of xterm, tty and whatever other dead-ends I keep losing myself into for this bug, had someone not reminded me of this story. The patch is now submitted, right beside a comment explaining where I'm stuck and asking for help. Looking forward to the next step :)

And if you know why a xterm control sequence documented since at least 1994 could be sending back an abridged output on a different (but recent) hardware / software stack, please do let me know...