Google Code-in/Mentors

From mediawiki.org

Note: Mentors must already be experienced Wikimedia contributors and need to know the community and "how things work". Mentoring newcomers who have not contributed to Wikimedia before requires a good understanding of the area of mentorship.

Responsibilities[edit]

Before the contest starts[edit]

During the contest[edit]

  • Create more tasks on the Google Code-in site at any time. An org admin will take another look before they get published. Org admins might not publish all your tasks immediately - we want to keep a good variety of tasks available.
  • Mentor students, answer their questions and review their work within 36 hours. (You receive email notifications.) If you need additional time, let org admins know to help you.
  • You can contact Wikimedia's org admins via mailing list or individually on IRC (e.g. to get specific tasks which you mentor published more quickly, or to get a task deleted).
  • If you plan to be off for a weekend or holidays, please tell the org admins. When creating tasks you could also simply put a (for example) "[DONT PUBLISH BEFORE Dec 31st]" prefix into the task summary.
  • Please share your feedback / lessons learned on "organizational" aspects in the corresponding Phabricator task (you will receive information about this when time comes; in 2017 it was phab:T181738).
  • As we need to choose six finalists (winners) from the top 20, please share your feedback in a non-public Phabricator task (you will receive information about this when time comes; in 2017 it was phab:T182509).

After the contest ends[edit]

  • Encourage students to write wrap-up blog posts sharing their experience, stay involved in projects and the community.

Task requirements[edit]

General instructions[edit]

  • Tasks can be of both coding and non-coding type (docs/training, outreach/research, QA, design etc.)
  • A typical task should take about 2-3 hours for an experienced contributor and about 2-3 days for a total newcomer to complete.
  • Mentor for any number of tasks at anytime during the contest.
  • Reply and review student contributions within 36 hours.
  • Students can also propose tasks themselves to potential mentors. Work already performed by students cannot retroactively become a Google Code-in task (contest rules: section 4.2).
  • You are welcome to add yourself as a co-mentor to existing tasks but you must understand the task sufficiently enough to review the student's work. If in doubt, please don't add yourself and let the "primary" mentor(s) decide instead.
  • Related to creating tasks on Phabricator & Google Code-in site:
    • It's recommended for a task on the Google Code-in site to be on Phabricator.
    • Please use Markdown in Phabricator instead of Phabricator's markup (e.g. [text](https://foo) instead of [[ https://foo | text ]]). It makes copy and paste to the Google Code-in website so much easier.
    • Ensure the task you are planning to mentor for is tagged with the corresponding #Google-Code-in year project tag on Phabricator (via "Add Action… → Change Project Tags").
    • Paste the link to the task on the Google Code-in site as a comment in the Phabricator task (remove "/dashboard" from the URL).
    • In the GCI site task, set the Phabricator task URL in the "External link" field.
    • Drag the Phabricator task into the "Imported into GCI site" column on the Phabricator project workboard (or use "Add Action… → Move on Workboard: Imported into GCI site")
    • Add a [READY] prefix to a task's title on the Google Code-in site to let org admins know that your task is available, as tasks do not get immediately published.
  • Also see the example tasks at https://developers.google.com/open-source/gci/resources/example-tasks.

Task template[edit]

While creating tasks on the Google Code-in site, use the hints below to fill out the information:

  • Title: Include project name. Begin the title with a verb (e.g. "Write a script that does …").
  • Description: Cover the following information, to make it easier for a student to get started on a task: 
    • Problem and expected solution.
    • Link to the task’s code base.
    • Link to corresponding task in Phabricator, GitHub, etc.
    • Useful resources.
    • Skills and knowledge required by students:
      • For example, make clear for design tasks: If you reuse (parts of) an existing design work of someone else, then you must provide sources (URL), you must understand licenses of that other work, and you must link to the license (URL). We will not accept any plagiarism. If you provide your work in SVG format, then please do not embed a bitmap image in an otherwise empty SVG file.
    • Mentor's preferred mode of communication (e.g. Phabricator, IRC, wiki page, Google Code-in site itself).
    • Where exactly you expect the work to be submitted (e.g. Wikimedia Gerrit, Wikimedia Commons (please provide tips on good file names!), attachment in Phabricator task, pull request on GitHub).
    • Note: You can only enter 1500 characters on the Google Code-in site. For more info, edit the Phabricator task description instead (via "Edit Task") so it will not get lost for future contributors if your GCI task does not get solved as part of GCI. Or link to a wiki page with more information.
  • Time to Complete: Enter number of days. Be generous! Remember, students might take more time, in the beginning, to complete tasks as they will be familiarizing themselves with the technology stack and rules of the contest.
  • Task Categorization Beginner Task (Yes/No):
    • Only meant for very simple and less technical tasks that help students onboard and learn how things work.
    • Note: Students can only work on a maximum of two beginner tasks in total - please think twice before you limit the number of students who can work on your tasks! More info.
    • Examples: Getting on IRC, making first wiki edits, setting up the development environment and providing a screenshot of it, triaging three bug reports, etc.
  • Instance Count: Set this as higher than 1 for a generic task so more than one student can work on it. For example: "Fix five template data issues from the list shown in this link." Students cannot claim more than one task instance, so if you want a student to be able to work on a task several times, you have to create separate tasks (e.g. number them).
  • Categories Choose one or more from below:
    • Code: Tasks related to writing or refactoring code.
    • Documentation/Training: Tasks related to creating/editing documents and helping others learn more.
    • Outreach/Research: Tasks related to community management, outreach/marketing, or studying problems and recommending solutions.
    • Quality Assurance: Tasks related to testing and ensuring code is of high quality.
    • Design: Tasks related to visuals, user interfaces or graphics or workflows in applications.
    • Translation tasks are allowed since GCI 2017 but please think carefully: if the task can be completed by machines or if the task cannot be reviewed by somebody who knows the language, do not offer it! No tasks asking for personal information about students are allowed!
  • Tags: Maximum 5 keywords. Add tags that make a task searchable (e.g. Python, wikitext, screencast, etc.)
  • Mentors: One or two (preferred). Let org admins know if you will not be available within a certain timeframe. 

Process: Life of a Google Code-in task[edit]

  1. Mentors create new task on the GCI website.
  2. Org admins publish the task to make it available for students to claim.
  3. Student finds a task relevant to their interests and skills and claim it. A student can only work on one task at a time until the mentor has accepted their work.
  4. Student works on the task, with guidance from mentors and other community members.
  5. Student submits their work for review through the contest website.
  6. Mentors must evaluate the work within 36 hours. Mentors must either click "Approve task" (if you are fine with the student's work) or "More work needed" on the GCI website. (Mentors can also add more time for the student, if the student runs out of time.) If you have reviewed a patch in Gerrit or Github as CR-1 or CR-2, please also set "More work needed" on the GCI website.
  7. Student then incorporates feedback from mentors and re-submits their work.
  8. Mentor clicks "Approve task".
  9. Student finds next task, and repeats from step 4.

Ideas for tasks[edit]