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.

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.

An internship is a full-time job.

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.

Proposals must focus on one project only.

Proposals must identify a clear and measurable outcome.

Vague goals are difficult to assess, and therefore, unacceptable.
Granularity of intermediate steps must be encouraged along with the flexibility to amend plans.

The core tasks shouldn't take more than 50% of the available time.

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.

Proposals shouldn't depend on Wikimedia Foundation's short-term priorities.

Two mentors are required for each intern.

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.

Proposals must go through public community review.

Applicants must provide a small contribution prior to applying. (Known as "microtask".)

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.

We cannot assume technical people don't need a basic introduction.

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.

Interns must submit their contributions soon and often.

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.
By iterating regularly, it is easier to find problems sooner, mentor properly, and adjust plans accordingly.

Communications problems during the first weeks must be addressed urgently.

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.

Teams staying in touch on a daily basis via IRC have more chances to succeed.

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.

Interns using bug reporting and code review regularly have more chances of success.

These tools require more discipline, and open the project beyond the mentors to the rest of the community.

Weekly reports must be required and plugged to Wikimedia's pyramid of reports (example)

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.

There is no forgiveness at the mid-term evaluation, and interns must know this.

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.

Keep the community informed regarding your project updates.

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.

Interns must send a summary of their project to wikitech-l at the end of the program.

A blog post is good, but as a complement or "web version" of the mail sent to our main community channel.