-
Notifications
You must be signed in to change notification settings - Fork 8
GSoC: Frequently Asked Questions
These were written for the 2015 version of Google Summer of Code. The list of Open Bugs and Projects on offer have not been updated since then. The projects for GSoC 2016 haven't yet been decided, please wait till they're announced or suggest your own.
Welcome to the community! We're happy you want to join us and contribute to a piece of software that most others simply assume always works. To start off, whether you're interested in our Python based projects or our C based projects, you should compile Wget from source and run all the tests successfully. In case you're stuck, it is because:
- You've not read the provided documentation thoroughly. Please go back and read it once more.
- The provided documentation isn't good enough. Reach out to us via an email/IRC. Also, submit a patch for extra brownie points.
- You're on a weird or unsupported platform. In this case, you can take a full GSoC project porting Wget to the platform you're running on.
Congratulations! You've passed an important barrier to working on GNU Wget. You'd be surprised how many others have tried and failed at the earlier step. Now, you should get your hands dirty. Dive into the Wget source and try to fix some open bugs. You can find a list of open bugs on the Savannah Bugtracker.
Ideally, you should try to close as many bugs on Savannah as possible. Not all bug reports are valid either. Oftentimes people complain about the behavior of Wget when the fault lies with a badly programmed web server. However, here is a set of simple bugs (In my humble opinion) that you could probably work on closing:
Please remember to also write a test case to show that the bug no longer exists.
There are lots of other open bugs and you're welcome to work on any of them. Just let us know if you're working on something so that there is no duplication of effort.
Python is only used to write our Test Suite. We use Python 3.x to write our Test Suite and it is located in the testenv/ directory. Please ping us if you need help navigating the source. We are not aware of any bugs in the test suite as of now. If you find one, please let us know and also try to submit a patch fixing the same. Otherwise, you could try to clean up the code and optimize it in places.
Remember, the program is called "Google Summer of Code". You are expected to code during this program. However, we do have a few non programming tasks available right now. Currently, we are in the process of updating and migrating our old documentation to something newer and cleaner. See the updated README file for example. Any help in improving this file will be appreciated! Also, you could document your experiences in setting up a development environment as a blog post for others. Or help in improving the CONTRIBUTING page.
You can also help us set up Continuous Integration tests on various platforms. Take a look at Wget: Continuous Integration for more information.
Remember, while these are great for community interaction, you must complete some programming related tasks for your application to be considered for GSoC.
There are two potential mentors for GNU Wget during GSoC 2016.
- Giuseppe Scrivano
- Tim Ruehsen
-
Darshit Shah(Backup Mentor)
We will split the mentoring load amongst ourselves based on the number of slots we get this year. If you have any queries or need help with your application for GSoC please do not hesitate to contact us directly. However, please remember to CC each of the mentors in all your emails so that everyone remains on the same page.
If you are interested in a technical discussion, want some code review or wish to submit a patch(Woohoo!), please direct the email towards our mailing list at [email protected]. This way the rest of the community gets to pitch in on any technical discussions and we identify design / implementation flaws a lot faster.
You may also ping us on IRC. Giuseppe(gscrivano) and Darshit(darnir) maintain a near 24x7 presence on IRC. If you need any help please ping us on #wget and we'll get back to you as soon as we can.
Remember, GNU Wget is developed entirely through volunteer effort. Most of the developers have other day jobs and hacking on Wget is only a hobby. As a result, you may not always get an answer to your mails immediately. Please allow for atleast 48 hours to go without an answer before you try pinging anyone about it. The same goes for IRC. Even though we're online on IRC, it doesn't mean we're active on it. Responses can take time especially on working days as most of the mentors are busy with their regular jobs.
Unlike a lot of the newer projects, Wget's development is not done on GitHub. Instead Wget sources are hosted on the Savannah servers at http://git.savannah.gnu.org/cgit/wget.git
We have a bunch of ideas that we have documented on the GNU GSoC page. We're also working on adding more information about these projects on this wiki. Visit GSoC: Ideas 2016 for an updated list of projects being offered this year
Apart from the ones that we have suggested, we also encourage you to come up with your own ideas.
The absolute most important part of your application for GSoC 2016 is the proposal that you submit. Spend as much time as you can working on writing a spectacular proposal. It should display a good understanding of the problem, your thought process for solving it, expected roadblocks and most importantly a timeline. However, a proposal alone does not a GSoC application make. We value people who we think will eventually join our community for a longer term and not disappear at the end of the program. Remember, worse than having a project not implemented is someone finishing it and disappearing; because now we need to maintain that codebase.
Ideally, you should also have atleast one commit merged into our code base or in the pipeline when you submit your proposal. This is a basic test that shows that you are capable of compiling the source, reading and understanding it and writing some code to fix a known problem. All very important traits.
Remember to choose your project of interest early on and make some strides in that direction. While you are allowed to submit multiple proposals for different projects to the same organization, it is not advised. Writing a proposal is a massive task that will take a lot of your time. Hence, you should rather concentrate on a single extremely good proposal about a project you're keen to work on rather than having three okay proposals about projects that you don't mind working on.
The answer to this question is a very emphatic YES!. Please apply! Google Summer of Code is a program where we try to get fresh programmers with little or no experience involved in the world of open source. The mentors are very well aware of this and we are willing to hold your hand, teaching you about the absolute basic steps if required. Only thing we ask for? Read, when given some material.
More experience does not automatically improve your chances of getting selected either. Think of this as a job interview. The most qualified person does not always get selected, but the one who best fits the team does. We expect you to learn something new when you join us for a GSoC project. For more information, take a look at this page in the Student's Guide, Am I Good Enough?. In fact we recommend that you go through the full guide, it will help you understand the GSoC program a lot better.
I have exams during the coding period / I have university project assignments / I'm going on a vacation for n days during the coding period. Can I still apply?
Once again, the answer is an emphatic YES!. However, with one caveat, you need to inform us about these potential time periods where you may not be productive. And you should account for them in your timeline when you draft your proposal. So long as you've informed us about potential periods where you may not be able to produce any meaningful work because of other commitments (This includes a vacation to Hawaii too), it's okay. Really. Of course, if its going to be a slightly extended period, we'll ask you to compensate for it by starting earlier / working a bit harder during the other times / anything else through mutual consent.