GSOCMentorGuide

From Nsnam
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

GSOC2016Projects

ns-3 mentor guidelines

Below are some specific guidelines and FAQs to applying to be a mentor in ns-3's GSoC program. These guidelines apply above and beyond what you will read on the GSOC site and on other wikis [1,2]. If you want to propose ideas and become a mentor, please read the below and the references cited.

How do mentors apply?

Mentors apply by submitting project ideas on the ideas page, or by contacting the ns-3 org admin directly via email.

How are mentors chosen?

If someone is qualified and interested to mentor, the org admins will try to work them into the program somehow, either as lead or backup mentor. The rules for mentor selection are as follows:

  • Projects will have one lead mentor but may have backups or assistants.
  • At least one mentor on the mentoring team must be a maintainer of some sort (commit privileges on the code server, or equivalent). This policy will allow us to also shepherd new mentors into the ns-3 project.
  • Mentors will be selected based on the student projects selected.
  • Mentors may work for companies so long as they are able to devote the necessary time (10-20 hours per week is the typical load) to the project.

Mentor selection in ns-3 must align with student selection. We will select the strongest student applications that have reasonable, credible mentoring plans. If a student project proposal is exceptionally strong, but has been developed with no mentor or suggested project proposal, the selection committee or organizational admin will try to find a mentor during the application selection phase. However, all things being equal in the student applications, we will select the student project that has a solid mentoring commitment over one that doesn't have any mentor identified.

Mentors can improve their chance of being selected by contributing high-quality ideas to the ideas page, and by working with prospective students to try to define quality applications, so that at application review time, strong applications exist within the mentor's area of interest.

Can people form mentor teams?

See above.

Can prospective mentors help students develop applications?

Yes. Mentors are expected to provide routine feedback to the students' proposals during the application phase. That said, mentors are expected to adhere to the following guidelines:

  • Mentors should take reasonable steps to ensure that a student does not develop an unfair competitive advantage from private conversations with mentors.
  • During the application phase, it is best to hold project development discussions on the ns-developers list so that any prospective applicant can benefit from the discussion.
  • When discussing a proposal with a student, the mentor must ensure that the proposal is scoped appropriately. That is:
    • the projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
    • the proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
    • there should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply or they directly apply to an ns-3 module that is in the process of merging with ns-3-dev.

Do prospective mentors have any role in selecting the student projects?

A selection committee will be formed by the organizational admin (Lalith) and this committee may be composed of some prospective mentors. Please contact the org admins if you would like to serve on this committee.

How much time does it take?

We are asking mentors to commit to a minimum of 10 hours per week helping their student, and it may be more time in spots (such as around midterm and final evaluations). The amount of time required to make the project successful depends on the student and the degree of difficulty of the project. Almost daily interaction is needed on some projects.

It has been our experience that mentors underestimate the time required to do a good job and make the project successful. For this reason, mentor teams are encouraged; although one person needs to be named the lead mentor, having 1-3 other mentors around to help can make a big difference.

Please also note that Google has high expectations for mentor time commitments. In a past year-end multiple choice questionnaire that Google provided to mentors, mentors were asked "How much time did you devote weekly to your project?" and the choices were a) 20-30 hours, b) 30-40 hours, c) > 40 hours, d) other. One can infer from the choices that Google provided that they have high expectations for mentoring commitment. While it hopefully does not take 40 hours per week to mentor, please keep in mind that this is not a 2-4 hours/week commitment.

As a guideline, we would encourage at least two meetings per week, where the meetings occur on Skype, IRC, or other interactive media.

How do payments work?

Mentors are not paid. Google pays the ns-3 project a $500 stipend per student, and the project deposits the funding to the the ns-3 Consortium gift account (funding to support the open source project). If you would like an exception and to take payment as an individual, please contact the org admins about it.

What if a mentor has some summer vacation planned?

Mentors must arrange for backup mentoring during the period that they are unavailable.

[1] https://summerofcode.withgoogle.com/rules/

[2] http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/