Dear GSOC candidates (and future MacPorters :), (Sorry for the slightly longer email.)
I would like to thank each and everyone of you for reaching to us in the hope to have a wonderful summer together, hopefully with a great learning experience and contributing something awesome to our project, potentially making a huge impact on all our users. There are only three weeks left until the final deadline for proposals. This is the deadline you **may not** miss in order to be eligible for the program. However one week from now is the deadline you **don't want to** miss if you want to increase you chances to get selected. I would strongly encourage all students to submit their draft proposal as soon as Google starts accepting them (or even earlier and send us a link), on March 25th. Keep in mind that this is still a draft: it doesn't need to be perfect on day one, but be prepared to work hard to improve it to perfection before the official deadline (9th April) is reached. Aim to have it finalized a few days before, just in case. If you don't show us your draft early, we cannot provide feedback about how to improve it. Tips: (0) Be available all summer Does your university requires from you to complete a compulsory internship this summer? Please ask them if you can make GSOC count as internship. If they don't allow you to do that and if you cannot avoid going on internship during the GSOC period, please spare the troubles to both you, your potential mentors, your company ... and don't apply to GSOC this year, you'll likely have another chance next year. You cannot do both full-time internship AND full-time gsoc coding at the same time. If you take the spot and don't complete the project, you don't get any money. but you take away someone else's stipend. That said, please let us know your university schedule (start and stop of lectures / exam period) and potential shorter vacation days, just to be able to plan better. (1) Plan to deploy your results before the first evaluation Create a clear timeline with clearly defined milestones. Ideally an important and standalone subset of your project should be deployed (documented, with test cases etc.) before the first evaluation period. This will then give you enough time to get feedback from users, fix all the issues that will arise while testing, improve the project according to feedback (something you probably didn't even plan initially), in case of statistics project actually be able to collect some data early enough to see what needs improvements ... Of course you would continue with active development for the whole summer, it's just that we don't want yet another project to end up at 70% by the end of the summer and then never get deployed (or, even if deployed at the end, never get a chance to fix the most burning problems). (2) Dream Add a section of all the things that might not necessarily be achieved in the given timeframe, but which you would like to add if you finish with the core application early, or things you would like to see implemented after GSOC is over. (Extension goals.) (3) Prove your skills Make sure that you show us your ability to solve the kind of challenges that you would be working with during the summer, either by some demo or by contributing some pull requests or other patches. If you still need guidance, let us know. Below is a special section devoted to interest in the same project. We try our best to keep the full process open and ask the students to communicate on the mailing lists rather than privately, unless it's a private matter or a one-to-one skype meeting / briefing. This year we seem to have multiple students interested in a single idea (web app for build & installation statistics), so I want to share some of my personal views (mixed with somewhat official guidelines, but most of them are not official). In case that more than one student apply for same project, there are the following possible outcomes: - none of the students gets selected anyway (none reach the high standards, or another proposal is a lot better and we run out of slots) - only one proposal is good enough and gets selected - two proposals are excellent, but we can only pick one student (the second one with still excellent proposal has bad luck) - we get two excellent proposals for the same project, but at least one student also submitted the second proposal for an alternative project, which might allow us to select both We cannot have more than one student work on the exact same project, since we don't want to end up with two solutions, out of which one would be thrown away, as that's waste of both our and student's resources. We should also not let the work of two students be too dependent on each other. Let's say that one student drops out: the second student should not fail (being unable to complete the project) just because the first one did not perform. We should also not end up in situation where one student fears to submit a proposal for the project he or she is most passionate about, and instead submit a proposal of a much lower quality for something else. There is enough work for multiple people for the web app project as well, it just that these boundary conditions make it a somewhat complicated situation. Please note that my email is not implying any of those four options mentioned above. I haven't seen any proposal yet, so we cannot even judge anything yet, and we don't know how many slots google will assign to us either. My **personal** suggestion would be that any student should submit a brilliant proposal for the idea that he's most passionate about. Include a longer section with extension goals. Then, explore and include also plan B if you feel that someone else might be in the game for the same project. You may keep in mind that the exact project might still change somewhat after the application period is over, provided that both mentor and student agree, so the exact content is not yet set in stone. A project with buildbot improvements is relatively tightly related to build & installation statistics where I can easily imagine one month of independent work, followed by some synergies to integrate stuff together. An alternative way is to start exploring macports base. If something is unclear, feel free to ask. Mojca (I explicitly CCed those who recently contacted us, but the same message should go to any student who might contact us later.)