Enabling New Contributors

I had a random idea today and wanted to share it in case anybody has thought about this too, or tried something like it, or could add on to the idea.

How We Onboard Today

I onboard, mentor, and think a lot about enabling new contributors to open source software. Traditionally in Fedora, we’ve called out a ‘join’ process for people to join Fedora. If you visit join.fedoraproject.org, you’ll get redirected to a wiki page that gives broad categories of skill sets and suggests Fedora teams you might want to look at to see if you could join them.
I started thinking about this because I’m giving a keynote about open source and UX at Ohio Linux Fest this weekend. One of the sections of the talk basically reviews where / how to find UX designers to help open source projects. Some of the things I mention that have proven effective are internships (Outreachy, formal Red Hat intern program, etc.), training, and design bounties / job boards. Posting UX assistance on say join.fedoraproject.org? Didn’t come up. I can’t tell you if I’ve actually onboarded folks from that workflow – certainly possible. My best success ratio in onboarding contributors in terms of them feeling productive and sticking around the community for a while, though, is with the methods I listed above – not a general call for folks of a certain discipline to come to the design team.
In fact, one of the ways we onboard people to the design team is to assign them a specific task, with the thought that they can learn how our team / processes / tools work by doing, and have a task to focus on for getting help from another member of the team / mentor.

Successful Onboarding Methods are Task-Oriented

Thinking about this, these successful recruitment methods of new contributors all focus on tasks, not skills:

  • Internships – internships have a set time period focused on the completion of a particular project, scoped for that duration and complexity, that has been documented for the intern. This is such that digging through archives of proposed Outreachy and GSoC projects unearths (if it were still current) a great set of directions that any new contributor could use to get started.
  • Training – in my experience, when training folks without UX experience in UX, they had a specific task they were working on already, knew they needed the skill to complete it, and sought out help with the skill. A task was the driver to seek out the skill.
  • Job board postings – (e.g., like opensourcedesign.net/jobs) – they are focused on a specific task / thing to do.
  • Bounties – super task-focused!

If onboarding new contributors works well when those new contributors are put to work right away on a specific, assigned task with a well-defined scope, why do we attempt to recruit by categories of skills with loose pointers to teams (that get out of date), instead of tasks? You might have someone fired up to do *something*, but they’re redirected to a wiki page, to a mailing list, to wait a few days for something to respond and tell them “hi, welcome!” without actually helping them figure out what it is they could do.

An Idea For join.fedoraproject.org

If you’re with me here, up to this point… here’s the idea. I haven’t done it yet. I want to hear your feedback on it first.
I thought about redoing join.fedoraproject.org as a bounty board, really a job posting board, but let’s call it a bounty board. Bounties are very well defined tasks. I did a talk on how to create an effective bounty a while back, here’s the high-level crash-course:

  1. Set the Stage. Give the narrative around the task / project. What is the broader story around what the software / website / project / etc. does? Who does it help? How does it make the world a better place? Most importantly, what’s the problem to be solved that the bounty taker will work on, and how does it fit into that broader narrative?
  2. State the Mission. Make a clear statement at what exactly the bounty is – state what the successful completion of the bounty would look like / work.
  3. Provide a Specification with Clear Examples. Give all the details needed – the specification – for the completion of the work. Is there a specific process with steps they should follow? Provide those steps. A specific language,or a specific length, or a certain number of items? Make this all clear.
  4. Provide Resources and Tools. What are the resources that would be the most useful in completing this bounty? Where is the IRC channel for the project? The mailing list? Are there any design asset / source files they will need? How about style guidelines / specifications to follow? Will they need to create any accounts to submit their work? Where? Are there any tutorials / videos / documentation / blog posts that explains the technology of interest that they could refer to in order to familiarize themselves with the domain they’ll be working in? Link out to all this stuff.
  5. Outline the Benefits. Clearly and explicitly state what’s in it for them to take on this bounty. Job sites do (or at least, they try) this too. You’ll become a Fedora contributor! You’ll get a Fedora account and membership in the team, which will get you an email forward! When I did bounties, I sent handwritten thank you notes with some swag through the mail. You’ll gain skills in X, Y, or Z. You’ll make life better for our users. Some of this is obvious, but it helps to state it explicitly!
  6. Ground Rules and Contact Info. How does someone claim the bounty? Do they need to get an account and assign it to themselves? What happens if they don’t do anything and time has passed, can it be opened up to others interested? (We had a 48-hour rule before we passed on to the next person when we did this on the Design Team.) Who is the contact person / mentor for the assignment? How can they contact that person?
  7. Show Off the Work! – After a bounty is completed, show off the work! Make a post, on a blog or mailing list or wherever, to tell the story of how the person who took the bounty completed it and give a demo or show off their work. (This is a big part of the benefits too 🙂 ) This not only gives the new contributor a boost, it’s encouraging to other potential new contributors as they can see that new contributors are valued and can achieve cool things, and it’s also helpful in that it shows folks who haven’t set up bounties that maybe they should because it works!

I was thinking about setting this up as a pagure repo, and using the issues section for the actual bounty posting. The notion of status that applies to bugs / issues also applies to bounties, as well as assigning, etc. So maybe it would work well. Issues don’t explicitly manage the queue of bounty takers (should the 1st claimer fall through) but that could be managed through the comments. Any one from any Fedora team could post a bounty in this system. The git repo part of the pagure repo could be used for hosting some general bounty assets / resources – maybe a guide on how to write a good bounty with templates and cool graphics to include, maybe some basic instructions that would be useful for all bounty takers like how to create a new FAS account.

What about easy fix?

We do have a great resource, fedoraproject.org/easyfix, that is similar to this idea in that it uses issues/tickets in a manner geared towards new contributors. It provides a list of bugs that have been denoted as easy to fix by project owners all in one place.
The difference here though, is that these are raw bugs. They don’t have all the components of a bounty as explained above, and looking through some of the active and open ones, you could not get started right away without flagging down the right person and getting an explanation of how to proceed or going back and forth on the ticket. I think one of the things that makes bounties compelling is that you can read them and get started right away.
Bounties *do* take a long time to formulate and document. It is a very similar process to proposing a project for an internship program like Outreachy or Google Summer of Code. I bet, though, I could go around different teams in Fedora and find projects that would fit this scope quite well and start building out a list. Maybe as teams have direct success with a program like this, they’d continue to use it and it’d become self-sustaining. I don’t know, though. Clearly, I stopped doing the design team bounties after 4 or 5 because of the amount of work involved. 🙂 But maybe if it was a regular thing, we did one every month or something… not sure.

What do you think?

Does this idea make sense? Did I miss something (or totally miss the point)? Do you have a great idea to make it better? Let me know in the comments. 🙂

4 Comments

  1. Hi! As a recent newcomer to the Debian project (which also has a similar wiki entry for newcomers) I must say that the ‘Bounty’ ideas you’ve laid out will prove beneficial to many projects and certainly would have expedited my first contribution. I feel I was lucky enough to find a component of Debian to work on which had project members who also work with the ‘on-boarding/newcomer’ groups. In my experience one is most often left to their own devices and hunt around in Bugzilla looking for easy newcomer tagged bugs which aren’t often as structured as what you’ve described above.
    It does, on the surface, seem to be quite a bit of upfront work for the project, but I’d imagine that if a project is *really* looking for assistance and team growth it will be worth the additional effort. I could see a system by which one is on-boarded via a bounty and then later develops a bounty of their own – feeding the system that brought them aboard.
    Hope to catch your talk at OLF!

  2. Tuomas Kuosmanen says:

    Hi 🙂
    One quick thought: Looking back to my own history with free software in the early days, it was the sense of belonging to a group that is doing awesome things.
    The fact that I could talk to the people working on GIMP for example, and they listened to my ideas — and were actually thrilled to have feedback from someone who used GIMP in their work — this was the big spark for me.
    Once I was regular in the community, it was easy to offer help when partially the same people started the GNOME desktop project and needed design help.
    I guess we all have our story, and it would be interesting to hear them somewhere.

  3. Not only do I think this is a great idea, I’d want to point new designers/career changers to it for possible design projects to work on. 🙂
    (given that one of the major problems for people new to UX in the boston area is getting experience, design bounties would be fantastic)

  4. Zach Villers says:

    Super idea! I hung out in the Fedora-Infra meeting today for the first time in a while. There is always an apprentice Q&A at the end of the meeting. The new/potential apprentices wanted to know when there was an apprentice workday, what they could work on, and how they could get started.
    I was at OLF on Saturday and loved your talk, but wasn’t sure what I could do afterwards. Two nights later, I was up until 130A trying to make sense of how to use Deja Dup/Duplicity. After a several search, try, and repeat cycles, I finally got the CLI version to work. Your talk started to come back to me. Most of the search answers were, “user entered wrong options.” The man page had a tone of, we made this coding choice for this reason ( with an implied NOT because anyone could use it ).
    The flow of joinfedora, or whatever its called, is sort of generic, in a department store kind of way. I think that’s good for an experienced contributor, “oh you need X? yes I do X.” For a NEW contributor, or someone that wants to learn, it can be pretty defeating. Smaller tasks are great for coaxing new contributors out of their comfort zone, the hard part is getting them started. Tasks have to be inviting, a task for a new contributor needs to say “Its ok if you screw this up, but can you make it better?”
    I remember seeing those “draw this bear” things in the backs of magazines that got you into some kind of pay for an art school by mail course ( I think ). They were inviting because there wasn’t a cost for screwing up the bear drawing. The promise was, if you did something decent, you could get more lessons or coaching ( of course you probably paid for it ).
    Your idea about bounties is good, but I think it needs to eliminate some of the risk or fear of making a mistake or not having the right skill set to contribute.
    PS – you said that UX designers like new converts…tonight I started reading http://thehipperelement.com/post/73602783776/daily-ux-crash-course-17-of-31 and as you can see, made it halfway through. You may have a convert…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.