On Nov 22, 2007 3:38 AM, Kai Blin <[EMAIL PROTECTED]> wrote: > Hi folks, > > from what we discussed at the last WineConf, we wanted to work on our > procedures for the Google Summer of Code a little. > I'm sending this email in hope to start some discussion about this, so we have > it out of the way until the 2008 version is announced so we can talk about > proposed projects then. > > The goal of Wine's SoC procedures should be to get high-quality proposals that > can be completed by the student proposing the project in the time allocated > for GSoC, so both scope and difficulty should be checked.
>From my understanding, the SoC site specifically says that you do not have to work on a project that has to be completed in the allotted time. I think the idea is that google wants to encourage people that were already working on a project before to apply and to encourage people to continue working in the community after the session is complete. Now the mentoring organization could set their own requirements, based on difficulty and scope, but I would be concerned with making time a limiting factor. > I haven't been on the mentoring side of things, but my understanding from the > WineConf side of things was that we had some problems getting this right the > past years. > > I was thinking about strongly encouraging people to post their project > proposal to wine-devel prior to applying, so more developers can have a look > at it and see if it's doable or not and offer suggestions. > > I know some projects did an introductory quiz to figure out the student's > coding skills, I'm not convinced the knowledge needed for Wine can be tested > in a quiz. What do you think? The best alternative to the quiz would be to have the student begin working on the project before the application. He can discuss it on the the mailing list and hopefully show some code. This would be a good way to judge coding skill and the project's scope. Now in order for this to work well, we would have to encourage people to get started early, which really hasn't happened before right? > > Another thing that didn't turn out too well last time is that it was really > hard to figure out what was going on during the summer. I have a few ideas on > how we could address this. > > Lots of other projects had their student write a weekly public progress > report. I think we should require the same. This will probably help keeping > people updated, and might help spotting problems early. I did write a weekly progress, but only to my mentor. Now if there was a website, then I could have submitted it there. > > According to the wiki page, we already require a post-mortem report on the > project, however I can't remember seeing much of those this year. We should > make sure those are written next time. We might think of a better name for > the report, post-mortem sounds like the project is dead after the summer, we > want people to keep working. > Maybe I misunderstood that. I only submitted my final report to google/mentors. > Last year, some of the students set up a public git repo on repo.or.cz. I was > thinking about making that a requirement for next year. This would allow > people to review work in progress. This is probably the most important thing, and then the web log. Jesse
