Outreach programs/Life of a successful project

This is how we think successful projects look like 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.

Choosing Wikimedia
(Pros and cons, coming soon.)

Be part of something big.

Submitting your proposal
(Coming soon.)

Where to start.

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: The first payment comes after completing this phase successfully.
 * Detailed plan agreed with your mentors.
 * Phabricator project created (instructions).
 * Meetings with mentors started.
 * Bonding period report published.

Bootstrapping a project
The newly created Phabricator project is filled with new tasks as the planning process identifies them. This is how it goes:

After a new Phabricator project is created, interns and mentors should add themselves as watchers in order to follow all its activity. Then,


 * 1) One task is identified as main task of the project, and will remain open until the project is completed. This task is usually the initial project idea (if there was one) or the task of an accepted proposal.
 * 2) * The main task is assigned to the intern leading the project.
 * 3) * Only the main task is associated with the related outreach program project (GSoC, Outreachy...)
 * 4) If there are other proposals for the same project, they are marked as duplicates of the main task. This moves all the subscribers to the main task.
 * 5) Only the main deliveries of the project are marked as subtasks of the main task. This includes main features and the evaluation tasks.
 * 6) The rest of tasks can be created as subtasks of subtasks, or simply as tasks on their own, always associated with their project.

The main task should receive only few and general comments about the project. Ideally the day to day discussions should be posted in their own specific tasks.

The reasoning of this organization is to keep the amount of project labels and notifications sane. Users interested in the progress of one project can subscribe to the 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... 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

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: The second payment comes after completing this phase successfully.
 * 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

End of program evaluation
Requirements: The third and final payment comes after completing this phase successfully.
 * 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).

Consolidation as contributor
(Coming soon.)