Saturday Sessions 2009/Recruiting Awesome

This was a discussion session focusing on how to recruit and retain great contributors. It focused largely on GSoC students but also talked about new contributors in general.

Contents 1 Organizers 2 Goals 3 Summary 4 Session Notes 4.1 GSoC Retention 4.2 Getting new Contributors 4.3 Retaining Contributors 5 Judging GSoC Students/New Contributors 6 Mentoring 7 Audio recording of the session

[edit] Organizers

• Donnie Berkholz
• Christopher Perkins

[edit] Goals

• Keeping better contributors around
• Keeping new contributors active
• Getting new contributors

[edit] Summary

• Make it easy to join and an inviting atmosphere
• Have good communication
• Do not push contributors away actively

[edit] Session Notes

[edit] GSoC Retention

• For GSoC this year, we tried to keep a continuous pipeline to keep people committed all the way through. Before the end of GSoC, we had our students begin the process of becoming a committer. With that change, this year we had all of the students become committers.

[edit] Getting new Contributors

• Hang out in IRC. The people that ask lots of questions are potential contributors. Answer questions. When you don't have ansers, say something lik "We don't have the answer but if you figure it out, we will incorporate it into what we are doing." This can apply to documentation and to code.
• Distributed version control. Lessens the boundary of contribution.
  • Code review -- better to see the sequence of a persons commits than one big patch.
  • Producing a reviewable tree doesn't take them out of the version control system to have to learn about diff and patch. Just push their branch somewhere for a trunk committer to review.
  • Two people canwork on the solution to a problem. This lets you look at the ideas that both people bring to the table.
  • Less feeling of responsibility when making a branch to make a change. Making a branch in distributed version control is a natural part of using the VCS. Making a branch in svn requires commit privileges, etc.
    • If you have to ask for permission, chances are you won't ask permission.
  • Developer documentation. If people have to ask what a function does or parameter does, then it makes them slower to uptake because they have to ask more questions. Having documentation makes it easier. Used doxygen to prevent from field in the same question over and over.
  • Karl Fogel quote: bug tracker, irc, mailing list are each things that make things better.
    • Karl Fogel's book: Producing Opensource Software good except Toxic People chapter (video presentation "Poisonous People")
      • Danger in labelling a person as a toxic person and then discounting everything that they say in the future.
        • Potentially lose a contributor who could be good if they're given the right encouragement. (Theo de Raadt'sinteractions with NetBSD and later success of OpenBSD given as an example) (by someone with very little background knowledge, obviously).
        • Danger in ignoring negative criticism of your project because of who it comes from even if the criticism is valid.
        • Sometimes a toxic person is also a very productive contributor.
        • Relatively few English native speakers so sometimes people think someone is being insulting when it's not intended. Sometimes IRC is worse than email because you don't think as long about what you're saying. Sometimes something on IRC gets taken to the mailing list and people without the full context from IRC think that the person is being poisonous.
      • Being able to say your behaviour/last email/what you just said is toxic is better than saying you are toxic.
      • The problem with toxic behaviour that must be addressed is that it keeps other people from joining. Who wants to be on a mailing list where people are calling each other names?
    • What's the opposite of a toxic person -- the kind of person you want around your project?
      • Someone that can step in and smooth things over.
      • People that are just nice.
      • Being helpful is good. Example, if someone asks a question in IRC, having someone there who answers in any positive way (vs either mean or no answer even though there's lots of people in channel) is going to make people feel better. "RTFM" isn't very helpful. Getting people a link into the manual helps them to help themselves next time by telling them where the manual is and you are probably faster at searching the manual than they are. If the only documentation is the code, point out where the line is in the code... Read the source is the most off-putting helpful answer that you can give but adding just that much changes the user's impression of your project/helpfulness.

[edit] Retaining Contributors

• If your project can afford it, paying someone who deserves it.
  • Sometimes the project has funds, sometimes someone within the community has a business that can use the person as a consultant on a project/put them on the payroll for a specific job.
• Give them interesting projects to work on.
• Give them privileges (like the ability to commit to trunk).
  • In distributed VCS, commit isn't as powerful (or doesn't go to nearly as many people).
• Get the person linked into the social aspect of the community. (Socialmeans -- consider the other members your friends as well as doing non-coding activities together).
• Who has other mentorship programs -- only 5-10% of orgs do.
• Sprints (in IRC)
  • Getting students involved in sprints gives you an entrypoint to getting them involved after the summer. If they sprinted with you during GSoC, they aren't surprised when you tell them that there's a sprint going on now that the summer is over. Groups that got their students involved with sprints actually had a number of students show up to sprints after GSoC was over.
  • Tips: Real time (IRC, phone) is more important than physical (although that's also good). Keep a log of IRC so people who come back after dinner/sleep/the next day/etc can catch up on what's happening.
• What tools are available to help collaborate?
  • gobby/kobby, eclipse with cyrus, etherpad, other collaborative editors.
  • VOIP, mumble, asterisk, good for voice chat.
    • People like voice for probing about progress
    • Lowers the barrier of entry for asking a question.
    • Has the con of knowledge of English as a spoken language vs written language.
  • Everyone wants a way to share diagrams, design tools, flow charts, etc.
    • I talked to the inkscape guys -- they have a non-working plugin and think that it wouldn't be hard to work on it now that some changes have landed in their development branch. Everyone who knows a C++ programmer, send them over to inkscape!
• Story: The psychology of committed: Someone would walk around a neighborhood and survey if people were committed to a clean and safe neighborhood. Most people say yes. Next week, someone else called to ask for volunteers for cleaning up the neighborhood. More people would do something then than if no call had been made before.
• Give people things and they feel the need to give something back.

[edit] Judging GSoC Students/New Contributors

• Judge how much a person wants to be involved:
  • Some people just want to give something back. Give them a task that you've already evaluated and think can be solved in a reasonable time.
  • Other people potentially become a long time contributor. Only those stay very long, produce high quality work.
    • These people suggest tasks themselves.
    • Story: Two people who were this way in GSoC for this project were already part of the community. They were producing code way ahead of time. They produced the highest quality code, and they continued to maintain it after the summer was over. In contrast, the new students had a harder time getting started. They didn't have as easy of a time slotting in. They did stuff but not to the same degree.
    • How passionate is the person?
      • Detecting passion: "Self igniting fireworks"
      • Atmosphere and opportunities to bring in their new ideas.
      • give resources to do things.
      • Don't make suggestions on specific details.
      • Gives additional support if necessary.
    • How committed are they?
      • Ask questions on the Google Melange app. Some people with good proposals won't even respond.
      • Story: Last year we trusted how much experience people said they had. Everyone failed. This year we asked everyone to show that something had been done prior to acceptance -- you installed our system and got it to do something. You supplied a minor bugfix in a patch. Getting the student to do anything prior to acceptance worked much better.
      • Story: Two students who did exceptionally well had made small but actual contributions during the application process. Students who passed but were mediocre or failed had a good resume but hadn't done any work for us prior to GSoC.
      • Did you have committment to make even a trivial change?
• People who come up with their own ideas are important
  • More likely to stick around than those who choose from a list
• Evaluate a person's motivations:
  • Helping to make things better -- positive for getting them to stay.
  • Getting paid -- probably not going to stick around
  • Also evaluate your org's motivations:
    • Getting work done
    • Get completely new ideas
      • Story: We had the student research and design a new security framework and write a prototype. We wanted to have some potential ideas rather than something that we can just add to our code.
    • Get new contributors.
• Story: We had someone do a project that had failed a previous year. This time was good. The person doing the project made the difference.
• Sometimes an idea is also to help evaluate the person. So you read an application for how good the person is. Then even if the design isn't something that we want, work with the person who took the time to be able to figure out what your project does.

[edit] Mentoring

• Code review can be additional support even when someone is doing a great job.
  • Sometimes students just need the assurance that they have done a great job.
  • Avoid making code review seem like a list of things to be fixed. Make clear that there's good things about the code, there's things that need to be fixed, there's things that are just different from how you do things,and there's things that should be fixed but can't because of issues in code that you've done.
  • Showing the student where your code is doing things poorly is a good way to let them know you suck just as much :-)
  • Let the student know that the review is not meant to make them feel bad, it's just to make their code better and be an opportunity to learn.
  • Be able to point out thing like tickets in the bug tracking system where someone else had the same problem.
  • Beyond code review, just being able to pair off was good.
    • Gives real time feedback.
    • Better than writing down code review comments.
    • Summer over, more motivated because the student was involved with pairing off with multiple people: greater sense of involvement with more people in the community.
• Story: Asked someone to make a change to regular expression engine. Could do basic C. Interested in the stuff in this. Did well until halfway through the summer. By then, had the regular expression engine working but needed to optimize. Student hit a wall when came to optimizing and couldn't figure out what to do.
  • Possibilities: Something else was interfering with the student's availability.
  • Student had learned to program in school but they hadn't taught him how to optimize code. Sometimes there's no substitute for experience and, as a mentor, we have to guide them over the hump and teach them how to do things that we now take for granted.

[edit] Audio recording of the session

[1]