Re: [Fwd: Google Summer of Code Summit]
Hi Kevin, Sorry if this went through before, since there were issues with my list subscription. AFAIK it didn't - this is the first copy that I received. Here is my feedback as a mentor. I'll be talking about the three projects that we handled in Cayenne this year, as I have no idea how it worked out for the other 25. The focus should be on the students and ensuring that they have an enriching experience. The goal should be to introduce them to OS development and best practices. Sometimes this is lost as projects try to get more free work, so to speak. Just to clarify, there's nothing wrong with having students work on something that can be useful to a project, but the emphasis should be on the student, not the project. I disagree. You are right about the goals, but you are wrong about the focus. Two reasons: 1. *Abstract* altruistic motives (on the mentors part) don't work. It has to a be a *specific* altruistic (or not) motive for anyone to participate in that. 2. From my own student years and a few internship-type projects that I've done back then (more than a few years ago to be sure) - the most discouraging part is a hypocrisy of being told that you are working on a real thing, only to realize later that you were doing something that nobody ever intended to use. This is the most certain way to kill enthusiasm. o How can the ASF improve the student experience? Make sure the patches are reviewed and committed promptly. o How should the ASF use student projects? Depends on the project. Ideally it should be clear at the proposal stage where the code would fit in. So while it is unreasonable to expect most of the students to stick around past the end of the program, my personal feeling is that we should only accept the proposals that we know how we can use, and actually ask the students to put integration of the code in the product core item on the proposal (see my comments above on the reasons why). Or was it already on a proposal? :-) o Should students be given more development resources than non- committers? -1 I am glad we followed the advice from 2005 SoC mentors and didn't go that way. Still we diverted a bit by setting up the sandbox SVN outside Apache. The result was that 1 project never communicated anything to the community (I still have no idea what it does and how far it went in its development, as it was all done between the mentor and the student). Andrus On Oct 12, 2006, at 11:45 AM, Kevin Menard wrote: Sorry if this went through before, since there were issues with my list subscription. If not, please feel free to share your thoughts, as the Google SoC summit is in two days. I'll be flying most of tomorrow, but should be able to gather everything together tomorrow night. Best regards, Kevin Original Message Subject:Google Summer of Code Summit Date: Wed, 04 Oct 2006 13:50:25 -0400 From: Kevin Menard [EMAIL PROTECTED] To: community@apache.org Hi all, As I'm sure most of you are aware, the ASF partook in the Google Summer of Code (SoC) program again this year. We were granted 28 student projects, across a variety of ASF projects. Since the program has just recently finished for the year, we should hopefully start seeing some of that work integrated into the project codebases. Anyway, Google has been gracious enough to host an SoC summit, offering to pay travel for two representatives from each organization. Ross Gardler and I will be attending on behalf of the ASF. The format of the summit is going to be largely user- driven and likely will cover an assortment of topics related to the SoC program itself. What I'd like to do is solicit feedback from the ASF community in general so I can bring that to the table. SoC is an interesting program. The focus should be on the students and ensuring that they have an enriching experience. The goal should be to introduce them to OS development and best practices. Sometimes this is lost as projects try to get more free work, so to speak. Just to clarify, there's nothing wrong with having students work on something that can be useful to a project, but the emphasis should be on the student, not the project. In general, I think the ASF understands this and that the mentors did an excellent job. Surely, as a group, we could stand to do a little better though. So, having said that, I'm going to kick this off with a few questions and please feel free to add your own: o Is SoC a worthwhile program? o Should the ASF continue to participate in the SoC program? o How can the ASF improve the student experience? o How should the ASF use student projects? o Should students be given more development resources than non- committers? Anyway, you should get the general point. I'm seeking either positive or negative criticism, so long as its constructive. Thanks a
Re: [Fwd: Google Summer of Code Summit]
For this and other emails in the thread, I'm going to switch hats from my role of solicitor to one of fellow mentor. This is mostly to stimulate more conversation. I will do my best to represent all viewpoints fairly in the end, however. Andrus Adamchik wrote: Sorry if this went through before, since there were issues with my list subscription. AFAIK it didn't - this is the first copy that I received. Well, then that certainly sucks. Thanks for letting me know. I disagree. You are right about the goals, but you are wrong about the focus. Two reasons: 1. *Abstract* altruistic motives (on the mentors part) don't work. It has to a be a *specific* altruistic (or not) motive for anyone to participate in that. 2. From my own student years and a few internship-type projects that I've done back then (more than a few years ago to be sure) - the most discouraging part is a hypocrisy of being told that you are working on a real thing, only to realize later that you were doing something that nobody ever intended to use. This is the most certain way to kill enthusiasm. Heh. My own experience is that it can be really discouraging to just do all the crap work no one else wanted to do. Although, if SoC is to be like an internship, maybe it's not too far off the mark. o How can the ASF improve the student experience? Make sure the patches are reviewed and committed promptly. In my own experience, this turned out to be much easier said than done. The easiest patches to review are the small ones. Since many students essentially start from scratch, they're patches aren't exactly small ones to begin with. Sure, they could provide patches that do nothing, but no one wants incomplete patches either. Based on mentor feedback, the codebase may change considerably, and then the next submission is a patch against an old patch that's so radically different, it may as well have been a new submission to begin with. More on this below. o How should the ASF use student projects? Depends on the project. Ideally it should be clear at the proposal stage where the code would fit in. Agreed, but all too often things change. So while it is unreasonable to expect most of the students to stick around past the end of the program, my personal feeling is that we should only accept the proposals that we know how we can use, and actually ask the students to put integration of the code in the product core item on the proposal (see my comments above on the reasons why). Or was it already on a proposal? :-) Heh. Once that secret's out, everyone will be using it in their proposals ;-) o Should students be given more development resources than non- committers? -1 This goes a bit in hand with the previous discourse on patches. This could quickly degrade into a procedural firefight, but it does sorta irk me that we expect people to give us code, but don't give them adequate tools to do it. If I ever applied for a job somewhere and they told me the only tools I had for submitting code were diff and JIRA, I'd hazard to say I wouldn't be at that job very long. There's something of a culture of earning the right to commit, and for the main codebase I'd say it's warranted. For a throw away branch, however, it seems to me like an unnecessary hurdle that we put in the way of students completing their work. I am glad we followed the advice from 2005 SoC mentors and didn't go that way. Still we diverted a bit by setting up the sandbox SVN outside Apache. The result was that 1 project never communicated anything to the community (I still have no idea what it does and how far it went in its development, as it was all done between the mentor and the student). In my own experience, it's easier to stay on top of commit emails with diffs than it is JIRA issues with attached patches *shrug* -- Kevin Menard Servprise International, Inc. Remote reboot without pulling the plug -- http://www.servprise.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Google Summer of Code Summit]
On Oct 12, 2006, at 1:35 PM, Kevin Menard wrote: o Should students be given more development resources than non- committers? -1 This goes a bit in hand with the previous discourse on patches. This could quickly degrade into a procedural firefight, but it does sorta irk me that we expect people to give us code, but don't give them adequate tools to do it. If I ever applied for a job somewhere and they told me the only tools I had for submitting code were diff and JIRA, I'd hazard to say I wouldn't be at that job very long. There's something of a culture of earning the right to commit, and for the main codebase I'd say it's warranted. For a throw away branch, however, it seems to me like an unnecessary hurdle that we put in the way of students completing their work. No firefight - there is simply no other way to build karma on an open source project. And the fact that one of our projects was done with no community involvement simply sucks. Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Google Summer of Code Summit]
Andrus Adamchik wrote: No firefight - there is simply no other way to build karma on an open source project. And the fact that one of our projects was done with no community involvement simply sucks. My point was that if some sort of distributed SCM was used rather than SVN, then it wouldn't matter that much at all. Non-committers (in this case, the students) would still be able to pull and update from the main codebase while committing locally. They'd get the benefits of having some sort of endorsed code management system that they could easily generate patches from. The idea of SVK was batted around on the mentor list, but didn't get very far. Cayenne tried two different SVN installations, which made it rather difficult to keep on top of patches. Others used no SCM at all. Anyway, to get back where this started. Did we give the students everything they needed to work most effectively and productively? If so, then JIRA patches are the way to go for next year. If not, what could be done differently? -- Kevin Menard Servprise International, Inc. Remote reboot without pulling the plug -- http://www.servprise.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Google Summer of Code Summit]
o Is SoC a worthwhile program? Yes, no question about this. In Cocoon and FOP, SoC brought us at least two very good committers in 2005 and 2006, who might not have joined the projects otherwise. o Should the ASF continue to participate in the SoC program? Sure! o How can the ASF improve the student experience? By being very careful about the student selection - it is much better to have the wrong students fail very early in the process. From what I've seen (I was a mentor last year, not this year), we should only accept students who have been actively doing something to connect with our communities before the program starts. Others usually don't get the way we work, or get it much too late to do anything useful. o How should the ASF use student projects? If student's projects can be integrated directly in our codebase that's very cool. But in some cases this can also be an opportunity to try wild things which have little chance or being directly useful. o Should students be given more development resources than non-committers? Last year in the Cocoon project we opened an area of our SVN whiteboard (experimental zone) for the students, IMHO this was very good: it allowed us to see their progress in real time and it helped them learn the right way to work with a shared repository. If we want them to work full time on the project we have to give them good tools, IMHO. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
