Nils, thanks for the questions. Hopefully not too long a reply as I do tend to go into detail, but responses in following.
> I just had a look at those documents. Thanks For posting these, > some more > comments below the specific sections You're quite welcome, hopefully it ends up being useful. > This document is really nice since it does also give some nice > overview of the > general procedure. Really nice to see how it does work. But how is > the number of > slots assigned? Do we have to say a number of max-slots that we can > host, or how > does this happen? Basically, slots are assigned *completely* at Google's discretion. They have an algorithm that takes various factors into account like how many submissions you receive, how many mentors you have, etc, that sets up an initial slot allocation but then those numbers are manually tweaked (by Google) up and down for all projects over several days. Previous participant orgs will almost always get priority -- and will generally get what they ask for as they really do tend to "know better" as to their capacity after having participated once before. Our expectations and upper-limits were very much wrong -- this year we know better what to expect. For that reason alone, new mentor orgs will generally be the first to see their slots decrease or be fewer than they might want but it's generally a good thing (for them and for the students). It's hard to have too few slots as you just tend to coordinate and communicate better -- it's very easy to have too many. Many of the student failures discussed at the mentor summit basically boiled down to poor/inadequate communication. That said, the org does specify a maximum. We specified 10 for example .. which would have likely been a disaster had Google given us that many and we wouldn't be welcomed back. We were initially allocated 5 slots, but then decreased to 4 after the adjustments. The students dictate heavily how much time/effort is required as well as the experience of the project in "running" the program effectively. In hindsight, we would have done great with just two, but highly likely we would have been able to *properly* coordinate and integrate code from more than five without something paying a price. That's why one of my tips was to aim low. It's of the utmost importance as a first year project to be "successful" else you won't be invited/allowed back. > Yes, this is *very* helpful, indeed. Shows some things that we > really should > take care about, especially in respect of the various personalities > and that > some need more "monitoring" and encouraging than others. One > question in this > regard: > > How have you manage to select the people? That is, have they > submitted some > code, too, or was it just some plain CV including their interests > and stuff? That's a really complicated question. It's a somewhat involved process but is based mostly on the students ability to communicate, the quality of their proposal, the perception of their capacity to complete what they say, mentor interest in a given area of development (very important), and our overall project priorities. We knew even before getting started that communication is highly important for our project's development style. Students that were quick to respond, receptive to criticism and feedback, open to suggestions, and seemed comfortable talking with our existing developers was pretty darn important during the proposal/application review process. We spoke with every student we accepted extensively via IRC before going forward. This year we plan to expand on that even further and have them do some technical tasks just to help weed out the few that are very good at writing proposals and communicating but may not have the technical expertise necessary. Unless you do something very wrong, you will very likely have *considerably* more student proposals from well-qualified students than you will have slots to fill. That's the hardest aspect of the entire selection process. We had over 50 proposals and more than 20 of those would have probably made *great* enhancements to BZFlag from students that were more than qualified to follow-through. The vast majority will be rejected so you have to internally decide what works best for you. For BZFlag, I actually came up with a ranking system that our mentors applied that purely ranks the submission itself. All mentors reviewed all submissions and applied the ranking criteria as they understood them: http://my.bzflag.org/w/ Google_Summer_of_Code_Evaluation (this will very likely be adjusted for this year) That evaluation attempts to characterize the mentor interest, then their cumulative rankings are weighted against our project priorities and student communication skills. Our GSoC admin then unilaterally re-ranked the applications to fit those priorities for the final sorting. For example, since several of the ways BZFlag has been put to academic use was one of our justifications for applying and participating, that was the basis for a higher ranking bias on several applications (including two that were accepted that related to artificial intelligence and procedural city generation). > Okay, we will try to take care of. This is why I personally don't > think that we > can manage more than two or three students. That sounds like a completely sensible count. More than one in case you get a dud student (which does happen), and low enough that you should be able to focus attention on integrating them with your dev team. > Okay, will try to point out why they should explicitly chose Wesnoth. Particularly as our postmortem article has been hitting other news channels, I wouldn't be surprised if Google has a lot more game submissions this year. I'd suggest characterizing your niche in gaming (in terms of genre, quality, growth, etc), provide statistics if they're impressive to a lay-person, demonstrate applicability in fields outside of gaming if they apply, and be sure you have a pristine application (in terms of grammar, diction, structure, etc) that goes into detail yet gets the point across concisely. Remember they have to read *hundreds* of these, only to pick one in five at best. You may have a *perfect* application but still not get selected (this year). Org selection is similar to the slots in that it's openly shared that previously successful projects tend to get priority. So try to stand out, communicate early/often, get to know the Leslie and the rest of the Google staff. The same way you would likely pick a student that is really easy to work with, they do the same for orgs. > I think regarding production quality and efford we are already one > of the > exceptional projects out there, we will just have to show this, too. Yeah, I wish more open source games paid as much attention to "release quality" issues like compatibility management, stability, aesthetics, gameplay, etc. You guys put BZFlag to shame in several areas (*cough* website *cough*) and we're often looked at as one of the best in open source for whatever reasons... ;-) > I hope we will get accepted. We are currently already work on > setting up a list > of possible ideas. What is your experience regarding what has to be > listed from > a project for ideas, is the amount of information sufficient (for > the first two > ideas it should be rather complete already): > http://www.wesnoth.org/wiki/SummerOfCodeIdeas I certainly wouldn't claim to be an authority on the ideas list -- but I think there is a balance of too much vs too little information. If you have requirements like you *really* prefer it to be implemented using some technology/technique/language/etc then I'd suggest just saying that outright. If you are willing to be flexibly, I'd suggest just leaving it off altogether. I wouldn't include the *process* of implementation in the idea as that's really what they're supposed to propose unless that is also a strong preference/requirement. Some projects go into excruciating detail, some expect the ideas to mostly come from the students (generally very well-known popular projects) but the end result seems to be about the same. I will say that the more the idea comes from the student, the more passionate they will generally be about it. Two of the students we slotted last year came up with proposals that were entirely not on our list of ideas but were such impressive proposals that they quickly jumped to the top of our rankings -- the students talked with us about the ideas beforehand as a sanity check and had a reasonable pulse on our community that they were able to propose something that wasn't on our radar but was still an outstanding proposal overall. The last comment about the ideas is to be very careful about the scope of the task. They're still "students" and are generally *far* less experienced than your average core open source developer when it comes to working on a community project (and usually completely unfamiliar with your codebase) -- particularly one with big visibility and community requirements. If it's something it might take one of your core devs two months to complete on their own, it's probably way over-scoped. We're adjusting our suggestions to ideas we think we could probably be managed in a month or two at most which allows ample time for implementation discussions, sharing progress, debugging, informing other devs, and getting the player community providing feedback -- most students *love* the immediate aspects (e.g. seeing their first commits from CIA, is usually a huge excitement moment). Have to say that I love the game (having just discovered Wesnoth last year) and hope to see you guys get accepted.. If you do, a round of drinks are on me at the mentor summit! Cheers! Sean _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
