Outreach programs/Selection process

From MediaWiki.org
Jump to: navigation, search

The Goal[edit]

We want to nurture long term contributors, either recruiting new people or consolidating current members.

We want to increase diversity in our community, promoting different types of candidates, projects and stakeholders.


These are the community priorities that all mentors and org admins must assume beyond their own priorities:

  • Multiple stakeholders: we want to offer chances to projects pushed by different Wikimedia projects, indepedent developers and any other communities promoting MediaWiki software.
  • Multiple topics and technologies: our community works on multiple areas and we want to give opportunities to all of them.
  • Diversity of candidates: in addition to the usual suspects (gender, origin...) we favor the distribution of bets among known technical contributors, known editors going tech and absolute newcomers, with and without prior free software development experience.
  • Distribution of risks: we encourage the combination of relatively safe bets with risky ones, both for projects and candidates. Deliveries are important, but they shouldn't push experimentation away.

FAQs for candidates[edit]

Do I need to submit a proposal on Melange and also make a Phabricator task for it? (for Google Summer of Code)

Yes. We want all proposals to be public, so everyone can view and comment and help polish your proposal to perfection.

Do I need to keep both Melange and Phab proposal updated? (for GSOC)

No, we encourage you to focus only on the Phab proposal since that's the one your mentors will look at for your proposal evaluation. Your submission in melange must link to your Phabricator proposal though.

Can I complete microtasks after the submission deadline?

Yes, you can, but you don't *have* to. If your proposal is complete and you have done one or more relevant microtasks, then you can sit back and relax. If your mentor(s) ask you to work on more microtasks or fix existing ones, then you can work on them, by all means. If your proposal is incomplete or you haven't done any microtasks yet, then we encourage you to work hard and submit microtasks as soon as you can after the deadline.

Until when can I edit my Phabricator proposal task?

We'd rather you not make any major changes after the deadline. Fixing spelling errors or adding further microtasks completed is fine, but completely changing the implementation plan, not so much.

Selecting the right teams[edit]

We are not selecting candidates alone, we are selecting teams. The success of a project is based on a good candidate and a good proposal, but also on a good combination of mentors and a good flow of collaboration between all parties.

The community is an important part of the team. Having explicit supporters in the community giving feedback and helping in other ways (for instance, reviewing your work quickly) shows a shared interest, more brain and muscle for your project.

A good team must work on a good plan. A good plan is expected to define a minimum viable product (the content of your first testable release) and build the rest of features on top of it. A first release is expected already in the first half of the program. We have seen how projects missing this checkpoint have a lot more difficulties to be completed on time. A good plan also assumes that it will change during the program, adapting to new problems and opportunities.

Assessing candidates[edit]

IMPORTANT: good mentors don't make up their minds before the submission deadline. Candidates working publicly on their proposals increase naturally their chances, but anybody applying on time deserves an opportunity.


Mentors and community members are encouraged to help candidates improving their proposals. Sharing the same criteria helps us evaluating teams.


  • Has your proposal been submitted on time at $OFFICIAL_DESTINATION?
  • Is your data in the table of candidates up to date?
  • Did you announce your proposal at the wikitech-l mailing list?
  • Did you announce your proposal in an existing or new Phabricator report? If required by the program, is your proposal available in a particular program wiki page?
  • Have you completed one or more microtasks?
  • Does your user page contain information about you?
  • Can you commit to the amount of time estimated by the program?
  • Are there two mentors (or at least one) committed to support you through the program?
  • Are the related project maintainers aware of your proposal, and are they interested in integrating your work?
  • What skills and experience do you have to complete the project? URLs welcome.


  • Why are you interested in joining this program?
  • Does your plan include a realistic deployment plan, allocating time for addressing community feedback, merging your work, testing, documentation...?
  • Have you planned for the delivery of a minimum viable product during the first half of the program?
  • Is there an emergency plan to be applied if the project is not completed by the end of the program?
  • Have you got a chance to meet your mentors in real time? (video call, call, or IRC chat)


  • Who else wants to help and see this proposal succeed? We will look for feedback and endorsements.
  • Have you contributed to Wikimedia projects in any way before?

Concurrent GSoC & Outreachy[edit]

To avoid double standards when Google Summer of Code 2015 and Outreachy overlap:

  • GSoC evaluation goes first, without any gender bias.
  • Female GSoC participants are considered for Outreachy when they are the best or the only candidates for a project that is not receiving a GSoC slot.

To be clear:

  • Women considered best candidate for a specific GSoC project with a slot available can't be pushed to Outreachy.
  • Women not considered best candidate for a specific GSoC project can't be selected for Outreachy either.


The selection process starts right after the deadline for submissions.

  • Community members are encouraged to leave feedback in the proposal's discussion page. Don't forget to sign your comments.
  • Mentors are expected to keep assessing the candidates with practical assignments until having a clear opinion about each of their candidates. Having an interview is highly recommended. You are going to work more than three months together.

Mentors and admins of the program will meet privately and will decide which candidates are selected. Depending on the complexity of the selection a private online spreadsheet might be put in use.

Candidates are selected by consensus, taking the selection criteria as main reference. In case of dispute the program admins have the last word.

(Outreachy internships are paid from the budget of WMF's Technical Collaboration. GSoC internships are paid by Google.)

Program Specific Guidelines[edit]

Outreachy December - March Round[edit]

The internship clashes with the academic calendar of most of the Universities, and mentors need to make sure that:

  • Participants should be able to put in 40 hours a week into the internship. 
  • It's expected that people might have other part-time commitments or schedules which don't line up perfectly with December 7 to March 7 internship dates, but please make sure that participants do not have full-time jobs or school during most of the duration of the internship
  • If the applicant is in a traditional college or university program, taking more than half of typical credits and having classes or exams for more than 6.5 weeks during the 13 weeks of the internship duration, they are not eligible to participate.
  • Please use the status "Contribution, full-time commitments" in the Outreachy application system, if such an applicant applied with your organization and made a contribution and feel free to ask us at outreachy-admins@gnome.org about any situations you are not sure about.

Applicant rating[edit]

Mentors should rate the applications in the Outreachy application system in a 1 - 5 scale as :

5 = amazing applicant, could become a maintainer on completing the program, made extensive contributions of high quality

4 = strong applicant, will certainly do a good job, made substantial contributions of high quality (> ~50 lines of code or equivalent)

3 = good applicant, but is somewhat inexperienced

2 = is unlikely to do a good job

1 = not a good candidate

Additional free software experience indicator[edit]

Applicant doesn't need to have prior experience with Wikimedia project to be evaluated with a "+" here. Instead, what this is looking at is whether the applicant has shown their enthusiasm for technology and free software and ability to get stuff done by engaging in some other technology communities and projects that are publicly documented.

+ = enthusiast based on past actions (e.g. has a blog, has been to conferences, has an active GitHub account, or contributed to free software for some time)

0 = proficient user of free software

- = no experience or very new to free software