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. 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?
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.
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.
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.
Comments? Kai
Hi Kai,
Kai Blin schreef:
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.
Sounds like a good idea, the work you have to do in a SoC is usually underestimated by a factor of 2. :-)
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?
I don't like the idea of a quiz as well, what would be a better test is to get a small patch into wine, perhaps adding a testcase to the component they want to work on. It shouldn't be big, but it proves they can get code into wine.
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.
Personal experience here, it might be good for some people, but for me I just told when I made some progress. Perhaps setting up a wine SoC blog where you post every week what you're doing?
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.
I'm all for it. Perhaps call it reflection report?
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.
Agreed, I'm for a public git repo. If it's needed I can write some instructions on how to set a repo up in the wine wiki.
Cheers, Maarten.
On Thursday 22 November 2007 11:48:10 Maarten Lankhorst wrote:
Sounds like a good idea, the work you have to do in a SoC is usually underestimated by a factor of 2. :-)
That is common industry practice. I want to prevent factor 10 or worse.. ;)
I don't like the idea of a quiz as well, what would be a better test is to get a small patch into wine, perhaps adding a testcase to the component they want to work on. It shouldn't be big, but it proves they can get code into wine.
This probably could work, provided we have enough people to give feedback we tend to have to give all new comitters. Might really be worth the effort, though.
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.
Personal experience here, it might be good for some people, but for me I just told when I made some progress. Perhaps setting up a wine SoC blog where you post every week what you're doing?
There's multiple options for that. There's http://planet-soc.com/, student's could use their own blogs, or send a weekly email to wine-devel. Personally I'd like to collect that stuff and give a short weekly digest of those posts to give the students some more exposure. WWN GSoC edition or the like. Unless someone reanimates WWN anyway, that we could just piggyback there.
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.
Agreed, I'm for a public git repo. If it's needed I can write some instructions on how to set a repo up in the wine wiki.
I think a tutorial for setting that up would be a good thing. We just need to make sure they still submit their stuff to wine-patches early and often.
Cheers, Kai
On Nov 22, 2007 3:38 AM, Kai Blin kai.blin@gmail.com 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
On Thursday 22 November 2007 17:44:09 Jesse Allen wrote:
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'm not saying that we stop people from working on their stuff afterwards, nor forcing them to e.g. implement the full dll if their project is "Start an implementation of dll x". I was talking about shrinking their proposal so they can actually manage to implement all the features they promise in their proposal in the proposed timeframe. I know that this was really hard for me.
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?
Well, depends on how you want to do this. I think this is overly restrictive, unless you're just talking about a patch or two like Maarten proposed.
I did write a weekly progress, but only to my mentor. Now if there was a website, then I could have submitted it there.
Yes, that's the idea. :)
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.
In 2006, students were asked to send the reports to wine-devel, and there was some WWN coverage of the projects. That really made it really easy for people to follow.
Cheers, Kai
On Nov 22, 2007 10:00 AM, Kai Blin kai.blin@gmail.com wrote:
On Thursday 22 November 2007 17:44:09 Jesse Allen wrote:
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'm not saying that we stop people from working on their stuff afterwards, nor forcing them to e.g. implement the full dll if their project is "Start an implementation of dll x". I was talking about shrinking their proposal so they can actually manage to implement all the features they promise in their proposal in the proposed timeframe. I know that this was really hard for me.
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?
Well, depends on how you want to do this. I think this is overly restrictive, unless you're just talking about a patch or two like Maarten proposed.
Well then it sounds like we want better written proposals. Yeah the goals for my project were very broad. I didn't intentionally do it that way, but it was more like at first, get it to work, sort of thing. And the design wasn't complete until a month in. The only way I could have done better was to have started earlier. Mind you, I actually did start in April almost two months early. If I get to do it again, I will probably have a much more interesting proposal and have goals that I will know will have specific results in the timeframe. This is what I'm already considering, but that is because I am experienced in the program already. For new people, we will have to reach out to them and help them get ready early because they won't know what to do. Maybe we need pre-SoC mentors?
Jesse
the FFMpeg project was very successful with it's qualification tasks http://guru.multimedia.cx/googles-summer-of-code-2007/
regards, mark
On Nov 23, 2007 6:30 AM, Jesse Allen the3dfxdude@gmail.com wrote:
On Nov 22, 2007 10:00 AM, Kai Blin kai.blin@gmail.com wrote:
On Thursday 22 November 2007 17:44:09 Jesse Allen wrote:
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'm not saying that we stop people from working on their stuff
afterwards, nor
forcing them to e.g. implement the full dll if their project is "Start
an
implementation of dll x". I was talking about shrinking their proposal
so
they can actually manage to implement all the features they promise in
their
proposal in the proposed timeframe. I know that this was really hard for
me.
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?
Well, depends on how you want to do this. I think this is overly
restrictive,
unless you're just talking about a patch or two like Maarten proposed.
Well then it sounds like we want better written proposals. Yeah the goals for my project were very broad. I didn't intentionally do it that way, but it was more like at first, get it to work, sort of thing. And the design wasn't complete until a month in. The only way I could have done better was to have started earlier. Mind you, I actually did start in April almost two months early. If I get to do it again, I will probably have a much more interesting proposal and have goals that I will know will have specific results in the timeframe. This is what I'm already considering, but that is because I am experienced in the program already. For new people, we will have to reach out to them and help them get ready early because they won't know what to do. Maybe we need pre-SoC mentors?
Jesse
On Thursday 22 November 2007 21:26:49 mark cox wrote:
the FFMpeg project was very successful with it's qualification tasks http://guru.multimedia.cx/googles-summer-of-code-2007/
If we want to do this, I think the only sane approach is to have people write tests. That's a good idea anyway, and will get them to dig into the windows api.
Cheers, Kai
On Thursday 22 November 2007 20:30:46 Jesse Allen wrote:
Well then it sounds like we want better written proposals. Yeah the goals for my project were very broad. I didn't intentionally do it that way, but it was more like at first, get it to work, sort of thing. And the design wasn't complete until a month in. The only way I could have done better was to have started earlier. Mind you, I actually did start in April almost two months early.
That's what I was talking about. We can't expect the students to know this. They're just starting out working on real projects. But we as mentoring organization should have more clue about how hard a project could actually be.
If I get to do it again, I will probably have a much more interesting proposal and have goals that I will know will have specific results in the timeframe. This is what I'm already considering, but that is because I am experienced in the program already. For new people, we will have to reach out to them and help them get ready early because they won't know what to do. Maybe we need pre-SoC mentors?
Well, that's why I'm beginning to discuss this now, and not a week before the deadline. :) Thanks for your feedback so far.
Cheers, Kai
On Thursday 22 November 2007 11:38:19 Kai Blin wrote:
Comments?
Thanks for the comments so far. I'll just go and flesh out the wiki page some more during next week, then we can talk about the individual steps if people think they need discussion.
Cheers, Kai
On Thu, 22 Nov 2007, Kai Blin wrote: [...]
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?
Maybe just asking them to compile Wine and submit their include/config.h or make test results. This can be used to check that their config does not have big problems like a bad fontforge or 64/32bit issues that could cause them problems when they start their project.
Asking them to submit conformance tests is an interesting idea too, but depending on the area it can be quite a bit of work. For some projects it may also not be possible to write relevant tests (e.g. we cannot test ExitWindows() or KDE/Gnome theme integration). But for those projects where it makes sense it could be a good idea.
The other ideas, public git repository, public blog / more frequent public updates, all seem like good ideas that could address the relative opacity of past SoCs.
On Friday 30 November 2007 12:30:56 Francois Gouget wrote:
On Thu, 22 Nov 2007, Kai Blin wrote: [...]
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?
Maybe just asking them to compile Wine and submit their include/config.h or make test results. This can be used to check that their config does not have big problems like a bad fontforge or 64/32bit issues that could cause them problems when they start their project.
Well, that's something we should take care of, ideally in the one-month period after being accepted and before the student is supposed to start working on SoC code.
Asking them to submit conformance tests is an interesting idea too, but depending on the area it can be quite a bit of work. For some projects it may also not be possible to write relevant tests (e.g. we cannot test ExitWindows() or KDE/Gnome theme integration). But for those projects where it makes sense it could be a good idea.
Well, the way I'd like it to work is like this:
1. Student sends application draft to mailing list for review. 2. Wine developers with experience in the area covered by the application review the draft giving feedback. (Repeat steps 1 and 2 until application is suitable) 3. Students apply via Google web-app. 4. We contact students with request for a test case or the like. 5. Students send test case 6. Mentors review test cases, possibly asking for improvements (back to 5).
Of course, I'm afraid it's unlikely that it actually will work like that, at least if we define test case as something that will fit right into the wine test suite. But I think a test case like a simple program that will use parts of the API that should be implemented and works on windows should be sufficient, and people will want to have something like that anyway later.
I think it's also worth investing some time to help people get the initial code submission right. That's a point where we can teach people about code style, dos and don'ts, etc. If we get this right, it will benefit all the developers starting off with Wine, not only the SoC students.
Cheers, Kai
-
Francois Gouget -
Jesse Allen -
Kai Blin -
Maarten Lankhorst -
mark cox