Commit access | Contributing to Sugar

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

Want to receive a weekly digest of new articles?