First things first (so you can stop reading if you disagree here):
- If you question Outreach Programs in general: I consider diversity an important goal in distributed software development communities.
- If you dislike that the Outreach Program for Women only targets people who do not define themselves as male and that it does not target different or other minority groups in a community: I don’t see why you have to try to cover all possible aspects when you start tackling a problem. I will not stop anybody from setting up an Outreach program for <insert language/region><insert ethnicity><insert economical class><insert sexual orientation or gender self-understanding><insert disability><insert religion><insert what I’ve forgotten> folks. That might be some work though and not just talking and criticizing from the sidelines. ;)
Outreach programs need to scale and be sustainable to be a long-term success. Is that the case? I’m not sure myself; depends on the criteria you come up with.
As Jim wrote, “the program grew to a size that overwhelmed our administrative staff person” (to simplify it).
Outreach Programs need to run without putting the GNOME Foundation or any other involved entity into financial or legal problems. I don’t follow closely enough, so I wonder if GNOME Foundation and organizations taking part in OPW have considered creating a separate legal entity with a dedicated mission to facilitate more diversity in free and open source software projects (as OPW has grown and is bigger than what GNOME is about)?
Do OPW participants (and GSoC participants) keep participating in our community after OPW is over, and do some become mentors themselves? (And if participants had sufficient time and financial resources, would they also participate if no money was offered?)
I consider the GNOME Documentation project to be a rather successful project keeping OPW’ers involved: Of those 14 OPW participants who worked on GNOME documentation, 6 pretty much vanished after OPW. 2 have mentored, 2 will likely mentor soon, and the rest is still around or around a bit. I don’t have numbers to compare and interpret (Marina posted some) but other GNOME teams feel less successful to me.
I’ve been wondering why. I’m sure others see other criteria and practices and I have not investigated other organizations who take part in OPW – feel free to add your impressions to the comments.
What to consider best practices?
- Responsibility: GNOME includes dozens of software applications. The user documentation area provides identifiable smaller chunks (“the help files for application XY”). If you can well-define what your “area” is and others can recognize your area, you might get the feeling that others in the project rely on you and your work. You will be rewarded with responsibility (if such intrinsic motivation works for you) as you progress and prove that you are capable. An encouraging tone (“your patch is nearly ready, there are just a few smaller issues to fix”) and getting patch reviews from numerous persons instead of a single point of failure makes you realize that many people are interested in and follow your contributions.
- Peer group size: The GNOME docs team has its IRC channel (#docs on GIMPnet IRC) with an overviewable peer group size. It might be less intimidating and overwhelming to ask your question into the void on such an IRC channel than on a channel with hundreds of people. It’s also easier to create friendship and trust than in larger channels. But when there are some non-doc related questions coming up, you are asked to interact and become involved with other members and teams of the larger community, in public. If you see that the rest of the community is also friendly and welcoming, you form further ties and friendships that make it attractive to stay.
- Visibility: After you got accepted in an outreach program you get added to Planet GNOME (a website that aggregates blogs of GNOME community members) and are expected to write regular blogposts. (I hope there is some backpatting via blog comments that your work is appreciated but I’m sure this is an area where every community can improve.)
GNOME wants you as an outreach program participant to attend GNOME’s annual GUADEC conference so you are provided partial sponsorship for travel costs (partial to avoid freeriding mentality and as GNOME isn’t rich). You will have to give a short presentation about your work. Latest GUADECs had a dedicated session for it with no other talks running in parallel – no excuses for missing it.
- Learning curve: Learning to manage tools efficiently and understanding workflows of teams takes time. If you handed it in a late application for the program you might get rejected as the learning curve for you would still be too steep. You will be encouraged to continue contributing, learning more, and to apply again for the next round. And to avoid that, better start early. :)
- Spreading the word, multiplicating the message, encouraging others to also get involved: I don’t know if GNOME asks applicants whether they actively engage with their local User Group or Hacklab, whether they can imagine giving talks about the FOSS organization and their experience working in FOSS at that User Group, their university, or a conference, and whether applicants get “warned” early to think about becoming a mentor themselves in the next round to help making the community grow and become a more diverse and welcoming place.
Statistics: Wikimedia has some statistics (beta) on community contributors joining and leaving. Which does not tell you why people join or leave of course. Could organizations be better to find out the “why”?
For example, I kept in contact with my OPW participant after OPW was over, but she got busy with her new job and moving to a new location (socializing). And I don’t want to be too be pushy and expectant towards volunteer contributions. Could I have done something better or differently? I don’t know. We all have our own lives and make our own decisions what to invest our time on.
Thanks to my team (Sumana, Quim, Guillaume) for discussing diversity in general and thanks to Kat for discussing best practices and numbers about OPW in GNOME Documentation.
And obviously everything written here is my personal opinion. As usual.