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

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 first contacting the ns-3 org admins by email, and then if approved, by submitting project ideas on the ideas page (or working with another mentor who has submitted a project idea of interest).

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 contributor projects selected.
  • Mentors may work for companies so long as they are able to devote the necessary time (5-10 hours per week is the typical load, 10-20 hours per week is the upper limit) to the project.

Mentor selection in ns-3 must align with contributor selection. We will select the strongest applications that have reasonable, credible mentoring plans. If a 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 applications, we will select the project that has a solid mentoring commitment over one that doesn't have any mentor identified.

Mentors are requested to contribute high-quality ideas to the ideas page, and by working with prospective contributors 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.

Conflicts of interest

For student applicants, mentors cannot be from the same academic institution as the student, or have a supervisory academic or professional role with respect to the student.

Can prospective mentors help contributors develop applications?

Yes. Mentors are expected to provide routine feedback to the contributors' 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 contributor 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 an applicant, 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 projects?

A selection committee will be formed by the organizational admin and this committee will 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 contributor, 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 contributor 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.

What are the requirements to be a good mentor

Besides available time, a mentor should ideally be:

  • Fluent with ns-3 and git, in the sense that he/she must know ns-3 quite well, as well as the way to handle merge requests, code branches, and revisions,
  • Have patience and communications skills, as mentors will need to collaborate as a team and with the contributor,
  • Speak fluent [enough] English.

Remember that the mentors team and the contributor will be from different countries, and (sometimes) this creates language issues. You *can* use a different language than English in the meetings, but it doesn’t happen often (that the mentors and the contributor can use something else than English).

How do payments work?

Mentors are not paid. Google pays the ns-3 project a $500 stipend per contributor, and the project deposits the funding to the the ns-3 SPI 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/