Outreach programs/Lessons learned

We compiled these lessons learned after our first participation at FOSS Outreach Program form Women, in April 2013. We updated them in October 2013, after running simultaneously Google Summer of Code 2013 and OPW Round 6. The new lessons are marked with a star.

The point of the program is actually to build a productive relationship, not to deliver a feature. An internship is a full time job. Proposals must consist in one project only. Proposals must specify a clear and measurable outcome. The core tasks shouldn't take more than 50% of the available time. Proposals shouldn't depend on Wikimedia Foundation's short term priorities. Two mentors are required for each intern. Proposals must go through public community review. A first small contribution must be required to all unknown applicants. We cannot assume technical people don't need a basic introduction. Interns must submit their contributions soon and often. Awkward problems during the first weeks must be addressed urgently. Teams staying in touch on a daily basis via IRC have more chances to succeed. Interns using bug reporting and code review regularly have more chances of success. Monthly reports must be required and plugged to Wikimedia's pyramid of monthly reports. There is no forgiveness at the mid-term evaluation, and interns must know this. Interns must send a summary of their project at wikitech-l at the end of the program.
 * Being productive following the open source way of working within a community is what matters most.[[File:Inkscape_icons_draw_star.svg]]
 * Delivering the feature is important! But this is not an assignment or contract work.[[File:Inkscape_icons_draw_star.svg]]
 * Our main goal is to the keep contributors engaged in the community after the program. [[File:Inkscape_icons_draw_star.svg]]
 * Most interns won't be able to combine it with other activities, no matter how optimistic they are.[[File:Inkscape_icons_draw_star.svg]]
 * We had exceptions, but they showed exceptional dedication and skills since the beginning.[[File:Inkscape_icons_draw_star.svg]]
 * The term is too short for changing projects and/or mentors efficiently.
 * Vague goals are difficult to asses, and therefore unacceptable.
 * Granularity of intermediate steps must be encouraged, together with the flexibility to change plans during the program.[[File:Inkscape_icons_draw_star.svg]]
 * The other 50% is needed for testing, bugfixing, documentation and deployment.[[File:Inkscape_icons_draw_star.svg]]
 * A good rule: one week of an experienced community contributor equals 3 weeks of an intern.[[File:Inkscape_icons_draw_star.svg]]
 * Interns shouldn't be bothered by WMF teams' sudden changes of plans.
 * It is a lot less work for each.
 * The second mentor can be really secondary, but must be following the activity just in case.
 * If one mentor drops there is still another one to push until the end.
 * All the better if mentors are also in different locations, forcing good remote collaboration.
 * We had exceptions, but only with mentors with good record in previous mentorship programs.[[File:Inkscape_icons_draw_star.svg]]
 * They must be considered relevant by the related project maintainers.
 * Mentors' judgments are good! But not enough if they come alone.
 * Assessing newcomers based on a proposal and a code repository out of context is too tricky.[[File:Inkscape_icons_draw_star.svg]]
 * The first contribution must be related with the type of project proposed.
 * Our community is complex, and we use several tools and channels of communication.
 * Many people are not used to open source transparency, and we push it to the extreme.
 * Many people are not used to the wiki way, and for us this is a given.
 * Again, they must understand that the process, the regular flow, is more important than the final delivery.[[File:Inkscape_icons_draw_star.svg]]
 * Iterating regularly it is easier to find problems sooner, mentor properly and re-plan accordingly.[[File:Inkscape_icons_draw_star.svg]]
 * Lack of responsiveness, illnesses and multiple technical issues might be symptoms of deeper problems.[[File:Inkscape_icons_draw_star.svg]]
 * Interns reporting these problems must receive immediate and full attention from mentors and org admins.[[File:Inkscape_icons_draw_star.svg]]
 * It really makes a difference, even if they only share a regular time frame idling in the same channel.
 * Instant messaging options (GTalk, Skype...) also work partially but you are missing the wider community awareness.[[File:Inkscape_icons_draw_star.svg]]
 * These tools require more discipline, and open the project beyond the mentors to the rest of the community.[[File:Inkscape_icons_draw_star.svg]]
 * Difficulties coming up with a decent report or delays delivering it are a good symptom of deeper problems.
 * Learning to explain your work is sometimes as important as the work itself.
 * A pattern to avoid: intern under-performs in the first half, but promises to over-perform in the second, or later.[[File:Inkscape_icons_draw_star.svg]]
 * The first half is indeed more complicated, but the right approach is to plan the proposal accordingly.[[File:Inkscape_icons_draw_star.svg]]
 * A blog post is good, but as a complement or "web version" of the mail sent to our main community channel.