Making Small Contributions Simple

It needs to be easier for community contributors to find out how they can help. We’ve had this discussion in Ubuntu before at past developer summits, and the ideas were generally things like “improve the participate link on the front page.” Sorry, no one’s clicking that link anyway, and even if we did create an elaborate AI-powered survey system behind it we couldn’t possibly do better than an actual human providing an encouraging suggestion about what’s really needed.

Human responses

Over the past few months, at least five separate people have reached out to me personally asking about specific ways they could help. I’m happy to answer, of course, but this tells me that it’s not at all obvious for them to figure out on their own. Likely, there’s five more who never emailed me since it was too much of a hassle to talk to an internet stranger, even a blogger who IMs more than a 13 year old girl.

What’s needed, then, is just a simple encouragement of human interaction. The open source community is a strange concept to newcomers, even the computer-savvy. You really can just dive right in and start offering help wherever you’re useful, and developers will just treat it like it’s the most natural thing. Maybe you’re from another project, or deploying the software in a business, or just bored around the house. There’s no such thing as an imposter in open source.

Many people who aren’t used to this kind of openness find it intimidating – there are too many people, so it’s not obvious who to go to for help getting started. We try to have mentoring programs and the like, but these are for people who want to be serious developers solving big problems. Small problems don’t need serious developers – they need a serious amount of small help.

Practical things for getting small help

At the Developer Summit, we discussed the idea of using more helpful bug tags to help contributors find where they can help. Our goal isn’t to sort half a million launchpad bugs into forty tiers of type, importance, and difficulty – our goal is to get them fixed.

So, here are the brand new bug tags, based on a simple discussion from the developer summit:

Most bug trackers don’t really use tags like this because the system is obvious – if you’re looking at Wine’s bugzilla, then pretty much every bug in there really could be tagged “needs-coding-c”. Launchpad is different: we’ve got a whole mess of bugs, and half of them aren’t even in the code.

Now we’ve got a real answer to the question “I want to help, what can I do?” We just tag some bugs and say click the link: Launchpad will instantly tell them dozens of places where they’ll be useful. That’s important, as they’ll not only be able to help, but they’ll also see that they can fill a real need and feel good about themselves. Make contributing simple and rewarding, and users will do so eagerly.

7 Comments 11th, 2009 at 6:00 am

Hopefully Ubuntu Wanted will make it easier for people can “meet”.

CaseyJune 11th, 2009 at 7:43 am

As a non-developer LONG time Ubuntu supporter/user (I’m a sys admin….who cares for the feeding and handling of devs hardware -grin) I’d LOVE to see the tags implemented. As it is I occasionally surf launchpad to see if there’s something I might be able to assist with, but, egads pages on pages on pages of stuff without a simple way to sort for just the things you listed.

Hope something will come of this, as its my bet that some of us non-code jockeys could help clean up a bunch of the gunk currently cluttering the ‘pad’. :)

Eric PritchettJune 11th, 2009 at 8:45 am

Heh, I’m in the same situation as Casey. Long time Ubuntu user and IT admin. I couldn’t agree more Scott and I think you hit the nail on the head. I often feel like people miss the point when it comes to getting people to contribute and they try to make the process as automated as possible thinking it will be easier, but I think the better way is to get people involved as much as possible to make the process easy, fun and enjoyable. I think it would be great if Ubuntu had a Contributor Mentoring Program where lets say at the beginning of every month people could sign up and get mentored for a month, so users can talk and ask questions, to people get to know other new contributors, learn the ropes and feel welcomed. If there was a human face instantly to contributing with real people and “arms” reaching to new contributors out I think we would get much more contributors.

phiphiJune 14th, 2009 at 2:17 pm

Shouldn’t there also be a needs-discussion, ideas, or needs-decision ?

That’s probably where i could contribute most. and like that you could get more (user-)response, new approaches, methods. Because that would take a part off the shoulders of the coders.

Brainstorm has something of this, but I stopped contributing there, as it seemed not to reach a person who will take care of this.
Where’s the (back-)linking from Launchpad to Brainstorm?

Or are there Forums where such things are discussed? Again, there’s a lack of linking to launchpad and it’s not accessible, if you don’t know what you actually do want.

jmarsdenJune 29th, 2009 at 12:22 pm

The suggested tags are only likely to be useful if there are a significant number of bugs reported in LP that each tag applies to. I’ve yet to come across a bug that would be considered a “needs-sound” bug, but that’s just anecdotal.

Did anyone try taking a random sample of a few hundred bugs on LP and determining which of these needs-* tags would apply? If it ends up with 98% of the sample being either a bug report to which none of these tags apply (perhaps because it can’t be reproduced?) or a bug which could be tagged “needs-coding”, then I suspect the suggested tagging scheme is not likely to produce the hoped-for results.

My instinct is that there will be relatively few LP bug reports in the “needs-sound” and “needs-artwork” categories. Most LP bug reports I see either need to be triaged and confirmed, or are confirmed and need coding and/or packaging work to fix them.

On a related note: There are many bug reports that need confirming — they need someone to reproduce them, and then clearly document the exact set of steps needed to reproduce them. Many bugs in the new, incomplete, or triaged states could use this kind of help. It may not give the contributor who confirms them the ability to say “my artwork is in Ubuntu” or “my sound is in Ubuntu”, but such bug confirmation is very useful indeed. If a “needs-confirmation” tag would help encourage people to confirm such bugs, by all means let’s add one.

My personal experience in getting started was/is that the #ubuntu-motu IRC channel is full of helpful and friendly MOTUs; if you’re willing to learn Ubuntu packaging, they are very willing to help you as you learn. #ubuntu-bugs is similarly friendly for those wanting to learn bug triage. There is a mentoring program for wannabe MOTUs, too.

I used the “bitesize” tag (which I discovered while reading the Ubuntu wiki about bug triage) to get me a list of (supposedly) smaller items I could work on, to get started. I’m not sure further subdivision into artwork/sound/code would have been helpful to me at that stage. Going from “here is my artwork” (or sound, or man page wording change, or three-line patch to a shell script, or whatever) to “here is a debdiff that adds my artwork/sound/whatever to this package” is a *huge* step forward in getting a bug closed, and is not something that is out of reach for an experienced sysadmin, IMO.

YokoZarJune 29th, 2009 at 2:24 pm

jmarsden, that is of course true, but these tags are not for the experienced sysadmin. Needs-artwork is a tag for artists, who so far haven’t been using launchpad to find places where they can jump in and contribute. If you’re a packager, or a bug triager, or even and experienced sysadmin you can likely navigate the bug system fairly well; you may, however, be unable to create your own art.

That’s where the tags come in – they essentially say “help me out with this” so we can all work together more easily. If one person is taking care of the entire bug, then we hardly need tags at all.

kathyJanuary 13th, 2010 at 11:50 am

well, i’m gonna install wine on a mac, i needed it to run a library windows based, I’m not familiar with wine, since i switch from pc to mac, not long ago, ether am i a computer “savVy” so i hope, and will test your wine application.

now, i understand you have two versions, i understand the first version is better? or do i need to install the latest version?
as you can read, dont know much about programs and stuff…

but trying to learn as much possible, now if you can i would love to know what to do in this case.

thank you

Leave a comment

Your comment