We want to change our requirements from students this year based on our past experience. The biggest change is that we will divide all projects in to merge-able sub-projects and actually merge them to master during the project. This way people will test your code already during the summer and you can be sure that we will use your work. Our aim with this is that you feel included in our community and get the most rewarding experience at the end of the summer.
To achieve this, we have to change our requirements. This list should help you understand what we expect from students this year. Communications ============ - write us at least once a week a short report - commit early commit often and push to github so that we can see it - actively work on your project plan and communicate with us during the community bonding period - Communicate every working day with your mentor. Just say "hello" If you like. It can be via email,IRC or github comments. - If there are good reasons, for not communicating please announce them early. - If you don't communicate with us regularly we will fail you. Midterm Goals ========== - set a realistic goal for mid-term. If you fail to meet your own goal we are more likely to fail you in the evaluations. Merging Code to master ================= - have some code merged into master at the end of the summer to pass the final evaluation. - This is a hard requirement this year so make sure that your time plan includes it. The communication rules should be clear. The best way meet the other requirements it will help to break your projects into small pieces and play with the code base a bit to get a feeling how much time you need for a task. Getting code into master ------------------------ The easiest way to have part of your project merged into master before the end of the summer is to divide it into small subtask that can be separately merged. And plan to merge at least one of them into master around mid-term. For example the Cover Art project can be done these 3 steps 1. reading/storing cover art 2. displaying the covers 3. fetching missing covers These points build up on each other but can be merged individually in this order For the track-management I could imagine something like this 1. change artist/album/genre/... for more then one track at once 2. cue-point editor ... It is usually possible to divide a project into separate problems or there are also minimal solutions to a problem. Try to go for the minimal solution first and then build on top of the for the rest of the summer. Another way to contribute code to master is fixing bugs that you encounter along the way. You'll likely encounter some small bugs or find that a small code refactoring would help you implementing your ideas. So instead of fixing them in your branch and having a massive pull request at the end fix them immediately in our master branch and make life easier for all of us. As a nice side effect you'll likely already get feedback from our brave beta-testers that use the current master branch. Since this is a hard requirement we as mentors will also have an eye on that and check if your proposal incorporates it and also warn you ahead of time during the summer if we see that you might not make it. Communicating with us on a regular basis is vital for that though. Having a realistic Mid-term goal -------------------------------- To get a feeling for the code and get some experience with our code you can go and tackle some of our easy bugs. Look at the code that you want to change, check if it follows our coding guidelines. Do some research on the API's you want to use, plan what classes you will add and how their public API will look. Write down your algorithms in pseudo code. The better your research is and the better you plan ahead the easier it will be to judge how long a given task will take. For your time estimates you should also consider that you can do less stuff during exams and try to be a bit conservative. If you have never done anything like GSoC before you will tend to underestimate the time to complete a task. I know that giving these estimates is not easy and that also professionals have problems with it. But having a good plan, knowing its weak and strong points are can help a lot, which is also the reason why I nag so much and try hard to find pitfalls in your proposals. best Max ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
