Outreach programs/Life of a successful project

How to have a successful project in the context of GSoC or Outreachy.

Definition of success

• Intern completes the project goals as defined in the proposal (they may or may not have evolved over the course of the project), has built a network of friends and contacts in the community, and has a plan to continue contributing as a volunteer.
• Mentors integrate the outcome of the project, get the new contributor involved in other initiatives, and want to mentor again.

Getting there

Choosing Wikimedia

Choosing the right organization and a project of your interest is primary for the success of the program. Following some basic steps, if you want to spend your vacation with Wikimedia, would be:

1. Join the #mediawiki^connect and #wikimedia-dev^connect IRC channels on Freenode. Developers and community members hang out there, and if you want to get noticed, this is the best place. You can introduce yourself as a beginner over there (if applicable) and ask for guidance. English Wikipedia has a tutorial on how to join an IRC channel; see the complete list of Wikimedia IRC channels.
2. Join the Wikitech-l mailing list. This is important so that you get updated with various announcements regarding Wikimedia in general and your GSoC/Outreachy program. You should also consider joining the mailing list for GSoC and/or Outreachy themselves.

You can always checkout the handouts for starters:

• Starter kit for new Wikimedia tech volunteers.
• How to become a MediaWiki hacker is a good place to start learning your skills and becoming a better candidate.
• Lessons learned for mentorship programs is particularly useful when you start writing your application.

Answering your questions

You can make queries

1. about organizational aspects of an Outreach program: On the Discussion page of Outreach programs
2. about general Wikimedia development/technology questions: On the #mediawiki^connect and #wikimedia-dev^connect IRC channels
3. about technical questions related to a specific idea/project itself: Every project is connected with a Phabricator task; ask your explicit questions (bad example: "Can you tell me more about this?") by adding a comment on the task. You can subscribe to the task.
4. Please do not repeatedly ask your possible mentor(s) to review your proposal. Mentors (and anybody else) are welcome but not obliged to give feedback on applications by adding comments to your corresponding Phabricator task. The fact that your possible mentors are busy developers (humans) should be taken into account.

Welcome, and be part of something big!

Coming up with a proposal

With literally tens of thousands of open tasks in our backlogs, experience tells us that most candidates have more chances of success if they bet on an existing proposal. You can check the list of featured project ideas below and our incubator of possible projects.

You can also search in Wikimedia Phabricator for tasks fitting your interests and skills. If you find an interesting task, you can suggest the idea in the task itself (a simple paragraph is enough for a first contact). When commenting, please associate the task with the tag Possible-Tech-Projects.

Another interesting place to look for projects is Community Wishlist which features a list of projects supported by the community. Comment on the relevant phabricator tasks with your questions if you're interested!

Bringing your own idea is also possible, but usually this requires a good knowledge of our community and starting to plan months before the call for submissions. Before investing too much time on it, create a new task in Phabricator with a simple draft. We will share our first impression in the task itself. A good internship project should take about two weeks for a senior developer to complete.

If you have questions about using Phabricator, check Phabricator/Help.

Find two mentors, usually one more technical oriented, the other one more product/community oriented. For mentors, it takes approximately from 2 to 5 hours a week depending on the phase of the program (onboarding, mid-term evaluation and end of project are more demanding times). Few steps to help you get the right mentors would be:

1. Comment on the project task that your project lacks a mentor, and you are in search of one. Ignore this step if you already have someone already listed in the task description
2. If no-one turns up, craft an email to Wikitech-l mailing list: Describe your project in a sentence, explain that it lacks a mentor, ask for volunteers to come up and help you, and provide a link to the project task
3. If you are still stuck, contact one of the organization admins for GSoC/Outreachy programs for Wikimedia, and put up your concern.

Start working on microtasks

Once you are ready with a project of your interest, and have mentors agreed to help out, working on and fixing "microtasks" improves your prospects in the Outreachy/GSoC round. Microtasks help candidates and mentors understand the skills required for a project and whether the candidate has these skills. They are also a good opportunity to start working together, show communication styles, and other practical details that your project application alone will not show. The best microtasks are existing open bugs related to the area of the project idea. Mentors should ensure there are a combination of easy and not-so-easy open bugs, but never tasks that would take more than, say, a full day of an experienced contributor to fix. micro-tasks. :) Mentors should list these microtasks in the description of the project task. There is no upper limit for the number of microtasks you can fix – the more, the better.

If you see that your project task does not have any microtasks listed in its description, you can get more microtasks by:

1. Ping your mentors on the task/IRC asking them to add in more microtasks, and in the worst case, ping one of the Organization admins
2. Start fixing up bugs related to the implementation area of your project ( you can find more in searching for project-related tasks in Phabricator, and in Annoying little bugs ).

Submitting your proposal

After you've identified this project task you want to work on, then create a proposal task. For example, there was a project task phab:T89287 "Graph editing in VisualEditor", several people authored proposal tasks to work on it, and the successful proposal task was phab:T93585 "Enable VisualEditor support in Graph extension (GSoC 2015 Proposal)".

The steps to get your proposal up for evaluation are:

1. Create a wiki user account, if you haven't already
2. (Optional:) After creating your wiki user account, you are encouraged to set up your (basic) user page (click your user name in the top bar on mediawiki.org to go to your user page). It can just be one or two sentences but allows others to find out who you are and what your interests and plans are in the Wikimedia community.
3. Register a Phabricator account using your mediawiki.org username, if you haven't already
4. Create a new task for your proposal. If your proposal addresses an existing project idea in Phabricator, then you need only click "Create subtask" in that project task, which automatically adds its projects and subscribers to your proposal.
   • Pick a short, memorable and catchy title which communicates your core idea on how to tackle the issue/project you chose.
   • Follow the application template in your proposal's description.
   • Associate your proposal to the Phabricator project(s) for the outreach program you want to apply: In the "Projects" field in a Phabricator task, enter either "Google-Summer-of-Code" or "Outreachy-Round", wait for the autocompletion to show available projects, and choose accordingly.
   • The GSoC student guide is a good resource for anybody willing to write a good project proposal. And then there is a list of DOs and DON'Ts full of practical wisdom.
5. Officially apply in the outreach program's main site (e.g. https://summerofcode.withgoogle.com/ or http://outreachy.gnome.org/), linking to your specific Phabricator task.
6. Create a user page about yourself for your wiki user account. Mention the Phabricator project task and your proposal task. If you don't already have a global user page on Wikimedia wikis, then create one on meta-wiki.

Mentors select participants

More details at Outreach programs/Selection process. See also phab:T117686, "Select participants for Outreachy round 11 by 2015-11-11" as a historical example.

Community bonding period

All accepted interns go through a community bonding period prior to the official start of the project. The purpose of this phase is to familiarize yourself with the tools, mentors, and the community that will help you during your project.

Requirements:

• Detailed plan agreed with your mentors.
• Request creation of Phabricator project (instructions).
• Meetings with mentors started.
• Bonding period report published.

Google has listed down few Community bonding period activities in their official announcement:

• Becoming familiar with the community practices and processes. (This often involves a mix of observation and participation.)

• Participating on Mailing Lists / IRC / etc. (Not just lurking.)

• Setting up their development environment.
• Small (or large) patches/bug fixes. (These do not need to be directly related to their GSoC project.)

• Participating in code reviews for others. (Even someone who isn't familiar with the project can contribute by pointing out potential inefficiencies, bad error handling, etc.)
• Working with their mentor and other org members on refining their project plan. This might include finalizing deadlines and milestones, adding more detail, figuring out potential issues, etc.
• If the student is already familiar with the organization, they could be helping others get involved in the community.

• Reading (and updating!) documentation they will need to understand to complete their project.
• Reporting or replicating bugs.

The first payment comes after completing this phase successfully (see the outreach program's schedule for details).

Bootstrapping a project

After the new Phabricator project is created, interns and mentors should add themselves as watchers in order to follow all its activity. Then they should add new tasks to it as the planning process identifies them. This is how it goes:

1. Identify the main task of the project that will remain open until the project is completed. This task is usually the initial project task (if there was one) or the accepted proposal task.
   • Assign this main task to the intern leading the project.
   • Only the main task is associated with the related outreach program project (GSoC, Outreachy...)
2. If there are other proposals for the same project, mark them as duplicates of the main task. This moves all the subscribers to the main task.
3. Create the main deliverables of the project as subtasks of the main task. This includes main features and the evaluation tasks.
4. The rest of the tasks can be created as subtasks of subtasks, or simply as tasks on their own, always associated with the new Phabricator project.

The main task should receive only few and general comments about the project. Ideally have day-to-day discussions in specific tasks.

The reason for this organization is to keep the volume of project labels and notifications sane. Users interested in the progress of one project can subscribe to its main task only, and those willing to follow it closely can become watchers. Meanwhile, those interested in the general progress of a GSoC or Outreachy round can just watch the program project, receiving notifications only when one of the main tasks has updates.

Reporting

Reporting is very important for the followers of your project, your mentors, and yourself. Investing a few minutes reporting on a weekly basis will save you a lot of time and energy.

For the weekly reports, please create a Phabricator task and associate it with your project. Insert a table with the date and report columns in which you'll write your weekly report. Write your reports as telegrams, always linking to the areas of progress: tasks, patches, demos, documentation pages etc. It is better to deliver short or even incomplete reports on a weekly basis than trying to elaborate the best deep weekly report but then get stuck and not deliver it at all. Two good examples of weekly reports can be found at

• User:Sputniza/OPW Progress Report
• User:Ankitashukla/Progress Reports

Weekly reports might look like:

Dates for the week, say, 1 June - 7 June 2015	Work completed (in brief, bullets, mention blockers if any)	Link to blog-post (not mandatory)

There are three special reports to be delivered at the end of each evaluation period: community bonding, mid term, and final evaluation. These reports should be more extensive, like blog posts, targeted to readers having no clue about your project. Add a bit of background information, all the basic links, and if possible screenshots or other graphical elements. Again, you will see that these reports are not just useful for other, but also for yourself. They help you reflecting about your own work, and they usually help you realizing what went well, and what did you learn.

A typical community bonding period report might contain:

• Work done (environment setup, links to patches merged etc.)
• Lessons learnt
• Problems faced and solutions found
• Any changes to the original plan
• Minimum Viable Product for the project decided
• Communication plan with mentor decided

Mid-term evaluation

Requirements:

• Weekly reports up to date.
• Patches published and accepted (or equivalent for non-coding projects).
• Regular meetings with mentors.
• If there is a delay in expected deliveries, plan updated accordingly.
• Full-time routine established

The second payment comes after completing this phase successfully.

End of program evaluation

Requirements:

• Weekly reports up to date.
• In sync with mentors.
• Full-time routine.
• Project completed, or at least a functional prototype.
• Tasks created for known bugs, missing features, and suggested improvements.
• Documentation for users and contributors.
• Wrap-up report.
• Summary in Past projects page (GSoC, Outreachy).

The third and final payment comes after completing this phase successfully.

Consolidation as contributor

(Coming soon.)

For possible mentors

Before

1. Read our Selection process and Lessons learned.
2. Become a mentor officially
   • for Google Summer of Code
     1. login to GSoC 2016 application website
     2. click "Create profile" on the home if you see such an orange button,
     3. then "Start connection" (with Wikimedia),
     4. once you are accepted as a mentor: "Wish to mentor" the proposals you want to mentor.
   • for Outreachy
     1. login to Outreachy. WMF staffers can login with their @wikimedia.org Google account
     2. visit December 2016 - March 2017 Internships and click [Apply to mentor]
3. Seek long-term contributors, not just new features. It probably takes more time to mentor a project than to complete it yourself.
4. Choose the best candidate, not the one that arrived first. Early birds have more chances indeed, but we must respect the timeline.
5. Don't choose a candidate based only on a convincing proposal and past experiences. They must complete microtasks related with their project.
6. Communicate transparently in public channels, allowing fairness among candidates and involvement of other community contributors.
7. Require from all candidates public documentation and regular participation in the community channels of your choice.
8. Score your own candidates and report this to the org admins.
9. Don't share any information about acceptance with your candidates before the official announcements. This also means:
   1. The mentor/co-mentor should not assign the specific Phabricator project task or its dependencies to any potential candidates before the official acceptance announcement. This avoids misinterpretation and wrong expectations.
   2. The mentor/co-mentor should keep the gate open for potential candidates to submit in proposals for the project until the official deadline.
10. A single project idea shouldn't be shared between two candidates, but try breaking up the large project to individual non-overlapping modules, allowing better evaluation of individual efforts.

During

1. Aim to get a Minimum Viable Product out the door. Fine-tune plans as needed. Don't leave any code merge to the end.
2. Require your contributors to release soon, release often, and report in the project wiki page on a weekly basis.
3. Be in touch regularly, between daily ping and weekly calls.
4. Encourage them to participate in community spaces and to ask there for help, with or without you.
5. Before the end of the program make sure all the open tasks are documented and all the known bugs are filed.

After

1. Share your own conclusions of the project, help improving our lessons learned.
2. Recommend new tasks to the not-so-new contributor, in your project or wherever you think they will fit in our community.

Guides for mentors

• GSoC Mentoring manual.
• The DOs and DON’Ts of Google Summer of Code: Mentor Edition.
• Federico's HOWTO
• "What makes a good mentor"

An inventory of past mentors, and the area they are ready to help is available in our Mentors Bench.