Outreach programs/Lessons learned

These lessons learned were compiled after our first participation at FOSS Outreach Program for Women in April 2013 and updated them in October 2013, after running Google Summer of Code 2013 and Outreachy Round 6 simultaneously. 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 focus on one project only. Proposals must identify 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. Applicants must provide a small contribution prior to applying. (Known as "microtask".) We cannot assume technical people don't need a basic introduction. Interns must submit their contributions soon and often. Communications 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. Weekly  reports must be required and plugged to Wikimedia's pyramid of reports (example) There is no forgiveness at the mid-term evaluation, and interns must know this. Keep the community informed regarding your project updates. Interns must send a summary of their project to wikitech-l at the end of the program.
 * Being productive by following the open source way of working within a community is what matters most.
 * Delivering the feature is important! However, this is not an assignment or contract work.
 * The main goal is to keep contributors engaged in the community after the program.
 * Most interns won't be able to combine the internship with other activities, no matter how optimistic they are.
 * Among the interns we had exceptions, but they showed great dedication and skill since the beginning.
 * The term is too short for changing projects and/or mentors efficiently.
 * Vague goals are difficult to assess, and therefore, unacceptable.
 * Granularity of intermediate steps must be encouraged along with the flexibility to amend plans.
 * The other 50% is needed for testing, bugfixing, documentation, and deployment.
 * A good rule: one week of work by an experienced community contributor equals three weeks of work by an intern.
 * Interns shouldn't be affected by WMF teams' sudden changes.
 * Two mentors can share responsibilities and workload, better covering different skills.
 * The second mentor can act as a backup, but must be following the activity just in case.
 * If a mentor leaves the program suddenly, the other one can support the intern and look for help, if needed.
 * If mentors are in different locations this forces good remote collaboration.
 * There were exceptions, but only with mentors with proven success in previous programs.
 * They must be considered relevant by the related project maintainers.
 * Mentors' judgments are good! However, not enough if they are without support.
 * Assessing newcomers based on a proposal and a code repository out of context is risky.
 * The first contribution must be related to 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, a concept that we push to the extreme.
 * Many people are not used to the wiki way and, for us, it is a given.
 * They must understand that the process, the regular flow, is more important than the final delivery.
 * Define a minimum viable product and focus in getting it deployed as soon as possible. [[File:Inkscape_icons_draw_star.svg]]
 * By iterating regularly, it is easier to find problems sooner, mentor properly, and adjust plans accordingly.
 * Lack of responsiveness, illnesses, or multiple technical issues might be symptoms of deeper problems.
 * Interns reporting these problems must receive immediate and full attention from mentors and org admins.
 * It really makes a difference, even if they only share a regular time frame idling in the same channel.
 * Recurrent and properly scheduled weekly meetings are useful to make sure that the team stays focused and aligned, as long as they don't substitute the regular communication in public channels. [[File:Inkscape_icons_draw_star.svg]]
 * These tools require more discipline, and open the project beyond the mentors to the rest of the community.
 * 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.
 * The first half is indeed more complicated, but the right approach is to plan the proposal accordingly.
 * It is recommended to send an email to wikitech-l at the beginning of your project and right after mid-term evaluations. Keep it simple: A project summary/short description and a link to where the weekly reporting can be found.
 * A blog post is good, but as a complement or "web version" of the mail sent to our main community channel.