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