Google Summer of Code/Mentors

From MediaWiki.org
Jump to: navigation, search

If you are considering to become a mentor for the Google Summer of Code program next year, learn more below.

Responsibilities[edit]

 Before the program[edit]

  1. Read the GSOC mentors manual to get an overview of your responsibilities.
  2. Add a #Google-Summer-Of-Code-20XX tag to a project on Phabricator that you would like to mentor (example).
  3. Accept the invitation in the email sent by Google to become an official mentor.
  4. Add yourself in our Mentors Bench, if you are okay with potential candidates reaching out to you for a idea of their own.
  5. Talk to interested candidates. Share with them project details, goals and some ideas for implementation.
  6. Point them to self-contained, easy and newcomer-friendly bugs to fix.
  7. Review proposals on Phabricator and give feedback.
  8. Assess proposals by following the selection process tips indicated below.
  9. Inform organization administrator about your decision.

During the program[edit]

  1. Set development & communication plans with your mentee.
  2. Encourage them to participate in the community bonding period following our guidelines.
  3. Set aside time in your schedule for a weekly meeting with your mentee via video call.
  4. Aim to get a Minimum viable product (MVP) out the door. Fine-tune plans as needed.
  5. Stay in close communication with your mentee.
  6. Require your mentee to submit new code for review often, ideally every alternate day.
  7. Require your mentee to submit weekly reports.
  8. Submit timely project evaluations to organization administrators.
  9. Before the program ends, make sure to document any open tasks, file known bugs or merge left over code.

After the program[edit]

  1. Share your conclusions of the project in communication channels, wherever appropriate.
  2. Suggest or help with any improvements of our outreach program guides.
  3. Communicate to organization administrators any lessons learned.
  4. Recommend next steps to your mentee in the current project or wherever you think they might fit in our community.

Selection Process Tips[edit]

  1. Seek long-term contributors, not just new features. It probably takes more time to mentor a project than to complete it yourself.
  2. Choose the best candidate, not the one that arrived first.
  3. Don't choose a candidate based only on a convincing proposal and past experiences. They must complete our recommended program guidelines.
  4. Be transparent in your communications with contributors and treat them all fairly.
  5. Don't share any information about final results with your candidates before the official announcements. This also means:
    • Do not assign a specific Phabricator project, or its dependencies to any potential candidates before the official announcement.
    • Don't make up your mind on a candidate before the submission deadline. Allow all potential candidates to submit proposals for the project until the official deadline.
  6. Do not share a single project idea between two candidates. Try breaking it up into individual non-overlapping modules for better evaluation of individual efforts.
  7. Look for feedback and endorsements on the proposal from the community members
  8. It's recommended to interview your candidate via an online medium.
  9. Ensure that participant would be able to put the number of hours as expected of them from the outreach program.
  10. Score your mentee and report to the organization admins. You could use the system below to rank them on a 1-5 scale (adapted from the Outreachy program):
    • 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(s)
    • + = 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
  11. In case of a GSOC/Outreachy overlap -- consider a female GSoC applicant for Outreachy only if they are best or only candidate for a project that is not receiving a GSOC slot.

Resources[edit]