GSoC - Information for students¶
We will be participating in GSoC 2014!
- GSoC - Information for students
Here's the most important steps of applying for GSoC with GNU Radio:
- Read Google's instructions for participating
- Take a look at our list of ideas
- Come up with project that you're interested in (be it on the list or not!)
- Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)
- Submit it using Google's web interface
For accepted students, we have guidelines in place for during GSoC, see our rules of conduct page.
Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that!
It is also OK to use the ideas as a rough guideline for your project, but to vary from that.
Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.
You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. This will greatly increase your chances of participating.
The proposal, which you submit to Melange, is the single most important part of your application.
In the time before the proposal submission, you should contact the mentor(s) of the project idea(s) that you would like to work on during GSoC.
The mentors will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.
Because a proposal is a private matter (and you might not want to show the proposal to other applicants), there's no need to post it to the mailing list. However, if you're early enough, and want to get feedback from the community, a good way is to use your github (or whatever you use) to publish your proposal. That way you can more easily update it than using Melange.
The following things must be in the proposal:
If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.
Something like this is good:
Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" . They are based on the mathematical theory that...
Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:
In GNU Radio, there are codes available in the component
gr-fec. Having looked at the available blocks, it is clear that the available blocks in
gr-fec, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.
One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.
Important: This is the summer of code, not the summer of research! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!
Inside the proposal, your deliverables are the most important thing.
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).
Don't be vague! The following is not a good deliverable:
- Deliverable 1: Include Herring-Codes in GNU Radio
Rather, write it like this:
- Deliverable 0: Create on out-of-tree module for Herring codes (
gr-herring), using gr-modtool.
- Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (
herring_Y), with the specs shown in Fig Z.
Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:
Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in
In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this. If you want to use another license, do tell us and lay out the reasons.
Check the schedule for GSoC on the Google Melange website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changable during the course of GSoC (in coordination with your mentor!).
Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs!
Other things to include:
- How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.
- Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.
- Do you have other commitments during the summer that will take time away from coding? Tell us about that!
Include these things:
- Your name, place of residence
- Your university and students status (are you a grad, undergrad...)
- Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious).
Of course, check what Google requires you to reveal about yourself.
Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.
Background on yourself¶
Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!
Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?
Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.
Any proof of your technical proficiency is also good. Point us to your github, or show us any code you've produced in the past!
Finally, we want to know about your relationship to the GNU Radio community, such as
- Have you participated in GNU Radio before?
- How are you planning to contribute to GNU Radio after GSoC?
A neat idea on how to present yourself is to upload a video of yourself explaining something.
Being a community member¶
First of all: You do not have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded. Perhaps you just heard about GNU Radio through GSoC? That's fine!
However, we do want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).
Introduce yourself, tell us you want to participate and tell us about what you want to do.
Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.
Working with a mentor (before and during GSoC)¶
Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they won't be working full-time mentoring you, so don't expect them to micro-manage your project.
For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).
Before the GSoC¶
- Contact a mentor, show her or him your proposal, ask for feedback. Don't spam us, that doesn't look good.
- Make sure they know you're serious about GSoC by asking good questions.
- Make sure you have regular contact with your mentor.
How we grade proposals¶
The following points are considered when grading proposals:
- How well do we understand what the student exactly is going to do?
- How likely is success with this project?
- How much does GNU Radio benefit from this project?
- What are the chances of the student becoming an active member of the community after GSoC?
Of course, all the other things on this page must also be considered.