GSOC2019StudentGuide

From Nsnam
Jump to navigation Jump to 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

Application Guidelines

This webpage highlights the expectations and requirements for student applicants for ns-3's Google Summer of Code (GSoC) 2019 effort.

Project Expectations

The ns-3 team is looking for three things from every successful GSoC project:

  • Developing code that can be incorporated back into the main codebase, useful to future users.
  • Mentoring students that will remain part of the team and contribute to the ns-3 effort even *after* GSoC ends. That is, we're looking for long-term contributors and maintainers for the project.
  • Providing GSOC students with experience and ideas that will be useful to them in their careers.

Student Expectations

  • The student will be expected to commit fully to the project, the time effort required from the student will the same as a full time job. Applicants should recognize that being accepted into GSoC is a serious commitment and will be the focus of their time over the duration of the program. Any existing commitments for class, other jobs, etc *should* be discussed as part of your application.
  • At the beginning of the program, the student will be required to provide a detailed plan of work covering the 12 weeks of GSoC. This should be developed with the help of the mentor. Students will have to setup a wiki page for their project, and cover important aspects of their proposal's design, the strategy to implement it, a list of deliverables, and lastly, update the wiki page as and when each milestone is achieved. This page along with the code repository allows the community to keep track of the student's efforts.
  • The student will be expected to produce mergeable code (either merged completely at the end of the project, partially at the end of the project, or not merged yet but with no major roadblocks foreseen to merge shortly after the program ends).
  • The student will be expected to follow ns-3 design guidelines (follow coding style, write tests, documentation).
  • Students are required to submit weekly reports on the mailing list, covering the progress they've made or the obstacles they've run into. This will help the community keep track of the student's efforts, and help as needed.
  • The student will have his or her code reviewed three times by the ns-3 community. The first and second reviews will be taken prior to the Google evaluations and will look at issues such as scope, public API, test plan, and open issues. The final review will be close to the end of the program and will include review of the produced code for possible merge into the project main tree. All students will be briefed on a checklist of things to prepare for these reviews. Between these reviews, mentors will periodically (at least weekly) review the student's output and will provide guidance where needed, and track this progress in a public place such as a wiki entry or the mailing list.
  • If a student drops the project before the GSoC program ends, is under-performing, or isn't communicating enough with the mentor and development team, he or she will not be passed (will not receive final payment from Google).

Expected Background

ns-3 development typically requires proficiency in C++ and a debugger such as gdb or ddd. The valgrind suite of tools, and a system profiler such as oprofile, are typically useful. Python may be necessary for some projects dealing with the build system or that involve using Python to integrate ns-3 with other programs, but is generally an optional component. Domain knowledge of the components pertaining to the project is also expected.

The Selection Process

Selection of students for GSoC will be competitive; in 2013, for GSoC, this project saw a 13% acceptance ratio. In 2014, the project received four slots and fifteen applications (27% acceptance).

The students will be selected by a selection committee which will consist of the candidate mentors who are either past mentors or maintainers: Tom Henderson, Tommaso Pecorella, Abhijith Anilkumar, Ankit Deepak, Lorenza Giupponi, Mohit Tahiliani, Dizhi Zhou, Natale Patriciello, Biljana Bojovic, Alexander Krotov, and Zoraze Ali. Other mentors can participate in the application development phase and provide input to the final evaluations. Students projects will be evaluated and scored according to the following criteria:

  • 1) Eligibility criterion: fulfill the patch requirement (see Patch Requirement Guidelines).
  • 2) Overall technical quality of application, including whether the project seems feasible and properly scoped, whether the student appears knowledgeable about ns-3, C++, the models that are being proposed, and the project plan including proposed milestones.
  • 3) Availability of a mentor for the suggested project.
  • 4) Impact and relevance to future users of ns-3? (e.g. does proposed project support an active field of research? Are results of the project broadly applicable? Does it bring unique capabilities to ns-3?)
  • 5) Participation and involvement in the community and with prospective mentors.

High scoring applicants may be asked to discuss their project details over email or chat. When the evaluation process concludes, the organization administrator will determine the highest ranking applicants and if there are close rankings or concerns, hold a meeting among selection committee members to resolve tiebreakers.

Where to begin

Students are expected to have worked through the ns-3 tutorial and to have read through and executed the code in their areas of interest.

The project ideas that we list are starting points for students to develop further, with help from mentors, but we are not going to provide a specific checklist or plan; that is for applicants to develop. We are also open to ideas not found on the list; if you are excited to work on something specific, let us know and we will give you some feedback on it.

The best applications are provided by students who have a desire to accomplish specific goals in the project (usually aligned with their own research or interests outside of GSoC), who can articulate an understanding of the issues involved, who get involved with mentors during the application process to help refine the application, and who provide some evidence that they have a reasonable plan and the coding skills to make progress on the goals.

After you decide which ideas you would like to explore, join the development mailing list or enter the ns-3 room on Zulip chat to discuss ideas with us.

You are more likely to get help if you ask specific questions that demonstrate that you have tried to make progress on a topic. A question such as "I am interested in ns-3; can you tell me how to begin?", or one that just asks generically about a project idea (e.g. "I am interested in the project idea 'DSR RFC compliance' on the wiki; can you please guide me as to how to begin?") is not likely to generate helpful guidance. A better example of a question more likely to generate good feedback would be something like: "I have read the code in the DSR module, and run the examples, and I have reviewed the RFC. It seems to me that sections X, Y, and Z of the RFC are not aligned with the ns-3 model, and I also found some comments in the code that state that something is not supported yet. Can you give me some feedback about which of these features might be the most useful to prioritize?"

Please note that all first-time posters to the ns-developers list are moderated to filter out inappropriate posts, so don't be alarmed if your email does not immediately post to the list; it will within 24 hours.

How to apply

For more information on how to apply, please look at the Google program site. Applications for students end on April 9, 2019.

While students are encouraged to discuss their technical plans with potential mentors on the ns-developers list, they are under no obligation to share their application details on the list.

Student benefits

  • GSoC is an excellent opportunity to gain experience working on an open source project.
  • Working with the ns-3 project will allow you to improve your networking knowledge, C++ skills and to be in contact with a highly skilled team of developers and user group.
  • This is a great opportunity to contribute to our open source community.

A piece of advice

Based on the ns-3 team's experiences in the previous Google Summer of Code programmes, the most important factor in the success of an application and project is communication. That process begins in the application phase. Without joining the mailing list and initiating a discussion of your ideas, it is unlikely that your application will be complete or rich enough to be competitive. Please feel free to discuss your proposed technical approach, plan, and other factors on the mailing list while developing your application. In addition to helping you develop the necessary details, focus, and priorities to write a good application, this will also demonstrate your commitment and willingness to dedicate time to the effort. During the program, every student is expected to communicate regularly with their mentor, announce weekly updates of their projects and participate on the development mailing list and discuss their work over chat.

Additional information about ns-3

Please review the main project web site.

Student guidelines

These guidelines are for students working on ns-3 summer of code projects.

Goals

This is a 12-week program for you to develop and merge code to ns-3. Your mentors will help guide you through the many steps required to position yourself for a successful final review and merge. While writing code is the main activity, it must be supported by good documentation, good examples, tests, and good communications with the rest of the project.

Guidelines for accepted students

Here is a brief checklist of things you should try to familiarize yourself with.

  • ns-3-users forum. Please plan to read this list daily during your project. Please also try, from time to time, to answer questions that you feel comfortable answering. Soon you will have more expertise than many of the people posting questions to this list, and you can start to help share the load of answering questions for new users.
  • ns-developers mailing list. Please plan to read this list daily during your project. This will be the list where you communicate with the developers to get your code reviewed and merged.
  • wiki. Please read through the wiki. Contributions and edits are welcome, to fix stale information or to create new topics.
  • Python bindings. Do you know how these work? Please have a read of this page.
  • Test framework. Do you know how the test framework works? Can you write your own test code? Please read this documentation.
  • gdb and valgrind. Can you run your code through gdb and valgrind? Can you run your tests through that?
  • Coding style. Do you know how to format your code properly? Do you know how to run the auto-formatting program check-style.py? Have you added Doxygen properly? Please read here.
  • Code reviews. How to survive ns-3 code reviews.
  • Emulation. Did you know that you can test your code against real implementations (if applicable to your project)? Read more here.

Planning

Some advice:

  • Refine your plan of what you want to accomplish. The plan should start out slow with some low-risk, easy to accomplish milestones, and work towards harder milestones. It is really important to think and revisit these three issues:
    • Scope. What use cases should your code support, and what is specifically out of scope, when you are done with your project?
    • Usability. How do you expect users to use your code? What kind of API would users find the most natural and easiest to work with? Is it extensible by future developers?
    • Testing. How can you test that your code works as expected? What tests should your code pass when it is done?
  • Decompose your project into small mergeable chunks. A good workflow would be to code something new, test it, document it, post for review, and iterate. If you don't accomplish all of your technical goals because you run out of time, make sure that what you have done is mergeable (i.e. it is better to accomplish 50% of your goals, with documentation and testing completed, than 80% or 100% of your goals that does not have good documentation and testing. The latter will not be merged.)
  • Commit early, commit often. This will make it easier for your mentors to track your progress.