- ns-3 GSoC Student guide
- GSoC Student application template
- GSoC 2012 Ideas page | GSoC 2012 Accepted Projects
- NSoC 2011 Ideas page | NSoC 2011 Accepted Projects
- GSoC 2010 Ideas page | GSoC 2010 Accepted Projects
- GSoC 2009 Ideas page | GSoC 2009 Accepted Projects
- GSoC Organization Administrator guide
- Get in contact with the ns-3 team: ns-developers mailing list | IRC #ns-3 on freenode.net
- 1 Application Guidelines
- 2 Student guidelines
This webpage highlights the expectations and requirements for student applicants for ns-3's Google Summer of Code (GSoC) 2012 effort.
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 and utilized by a variety of users.
- Developing new members that will remain part of the team and contribute to the ns-3 effort even after GSoC ends.
- Providing GSOC students with experience and ideas that will be useful to them in their careers and/or research.
- 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 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 twice by the ns-3 community. The first review will be taken prior to the mid-term evaluations and will look at issues such as scope, public API, test plan, and open issues. The second review will be taken at least two weeks prior 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, he/she will be failed.
Students have inquired about what software development background and tools are required. 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.
The Selection Process
Selection of students for GSoC will be competitive; last year, for GSoC, this project saw a 12.5% acceptance ratio.
The students will be selected by a selection committee which will consist of the candidate mentors and selected active maintainers. Students projects will be evaluated and scored according to the following criteria:
- 1) 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.
- 2) Availability of a mentor for the suggested project.
- 3) 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?)
- 4) Participation and involvement in the community and with prospective mentors.
High scoring applicants may be asked to discuss their project details over email or IRC. 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.
List of 2012 mentors and reviewers
Mentors will be paired with students depending on the student applications selected. In 2010, a total of 12 members volunteered to help mentor student projects and/or review student applications. We had more mentors than available student slots.
The list of mentors and reviewers this year are: Tommaso Pecorella, Guillaume Rémy, Nicholas Loulloudes, Hajime Tazaki, Michele Weigle, Frederic Urbani, Tom Henderson, Vedran Miletić, Daniel Câmara, Nicola Baldo, Marco Miozzo, Adrian S.W. Tam, Lalith Suresh, Andrea Sacco, Ken Renard, George Riley.
Where to begin
A good starting point would be to read the GSoC 2012 Ideas page. After you decide which idea you would like to work on, join the development mailing list and enter #ns-3 on freenode.net IRC chat to discuss your ideas with us.
How to apply
For more information on how to apply, please look at the GSoC 2012 FAQ. Application for students begin on March 26th, 2012 and end on April 6th, 2012.
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.
- 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 2008, 2009 and 2010 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 IRC chat.
Additional information about ns-3
Additional slides about the ns-3 GSoC project (from 2009) are also available, from a GSoC Infosession at the University of Washington on March 5th, 2009.
These guidelines are for students working on ns-3 summer of code projects.
This is a 10-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.
Here is a brief checklist of things you should try to familiarize yourself with.
- ns-3-users mailing list. 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.
- 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.