One of the worst things a project can do is ignore its contributors. How we treat incoming contributors is very important to us. It’s an area we’ve been hitting pretty hard in Ubuntu for the past few cycles. It can be tough, especially with busy developers with tons of work to do and a bouncy Daniel Holbach reminding people who important it is.

And let’s look at how this has worked out for the distro:

I love January 2011. We might as well have put a big middle finger image on Launchpad. “Welcome to Ubuntu! Send us stuff so we can ignore it.” Look at how that’s improved over time.

When we were working out how we were going to manage incoming charms for juju we were cognizant of creating a process that was too complicated for people. So we went for “loose and light”.

The problem with “loose and light” is that it doesn’t scale. While we want to be cool guys in IRC that can just do reviews on the spot this leads to people missing things. So we tightened it up:

Juan Negron reused some of the code that Daniel uses for the Ubuntu’s sponsorship queue and Kapil integrated it into the juju charm store itself. And here it is.

The first(!) thing we noticed that the queue had 34 items in it. We thought we were doing so well; we knew we had a bunch of items from the UDS charm contest, but this showed not only things that needed review, but easy loose ends that we had just forgotten about. Ends up when you’re “loose and light” it’s easy for things to fall in the cracks. So, now that we had a queue we got to work.

And we have a ways to go here. As you can see we’ve not only added incoming bug reports for charms, but also improvements to the tools itself. One queue to rule them all. We now have scheduled reviews, just to hit the queue with dedicated time. Once we drive this down we’ll be in better shape to be more responsive to incoming submissions.

As it turns out, with the tools in place our new “tight and heavy” process is actually easier for contributors to use, so really, it’s “tight and light”.

So why is this important?

OSS projects live and die according to contributions. That “first response” to a contribution is critical. Is it timely? Is it friendly? Are you mentoring or just blah-blahing the process?

To me a new contributor is like hanging out at BBQ, and each person brings their own drinks and food. This makes for good times. And like a BBQ people might need to know where the cooler is so they can put their beer in it, some people want a hand at hitting the grill, some people like to organize the table for everyone.

It’s the same with software. Every person is still are part of the BBQ and sharing the meal, even if nobody eats my terrible homemade potato salad.