The GSoC Mentor’s Summit wrapped up as strongly as it started. The second day of sessions were also productive — although some last minute schedule changes kept cutting into the “mini distro summit” that Donnie Berkholz suggested for the second day.

Despite the changes, we managed to get some discussion in and plan to continue the discussion. Present at the summit within the summit were representatives from Debian, Fedora, Pardus, Gentoo, and (of course) openSUSE. We talked about common problems like the mirror situation (and had representation from OSUOSL to hear it from the mirror side too) and issues of cross-distro communication.

Overall, I think the FOSS community in general, and distros in particular, are pretty good at being willing to communicate and work together — the fall-down comes in when a contributor from Project A doesn’t know who to contact with Project B. (Hint: Start with the project leader or community manager if you don’t know who to start with…)

One of the larger discussions was — how do projects get picked for GSoC and how do projects get passed over. The GSoC folks were very frank about specifics, which I won’t relate here because attendees were asked not to. However, I can say that the Google folks emphasized that the primary concern is the well-being of the students, rather than whether the program generates X amount of code or Y number of projects make it through the program, or whether orgs get all their stuff in on time — though they did emphasize the importance of getting evaluations in on time. (Not that those things are entirely unimportant, but they’re not a big deal compared to the students having good and productive experience with the mentoring organization.)

They also mentioned that sometimes orgs are passed over simply for lack of room. Lots of organizations apply, and even though Google has a nice-sized budget for Summer of Code, it’s not infinite — so to make room for new orgs, sometimes organizations are turned down.

Anyway, it was some nice insight into how organizations are chosen (or not) for the summer. Also something to think about going into next year’s summer of code. I hope we can start very early putting together an ideas page and such for the program next year, so if openSUSE is chosen again we’re well-prepared to work with our students from Day One.

The summit was far, far less about the summer of code than it was an opportunity for all the disparate projects to get together and meet and make connections. (At least that’s my take.) We did talk about GSoC issues, of course, but I’d say that was less than half the summit.

The summit was, in my opinion, a great success. Did we get to talk about everything we wanted to in one sitting? No, but it would have needed to be much longer than a few days for that. It did kick off some useful discussions, though, and allowed some cross-pollination to happen that might not have happened anywhere else — so Kudos to Google for putting it on, and doing so well at it.

Some lessons learned from the Mentor’s Summit for future events:

• Any good summit or event should have leeway for hacking or ad hoc meetings. Having a complete, rigid schedule before the event? FAIL.
• Food and caffeine, food and caffeine, food and caffeine – provide in abundance. If you don’t have budget for it, find a way to at least allow attendees to provide for themselves.
• Old fashioned methods work best - the summit had a wiki and Google Docs spreadsheet for the schedule, but that meant that people had to have a laptop or other means to get to the schedule — of course the attendees were computer-enabled, but not everyone wanted to lug their laptop all day, and some batteries last longer than others… so a central, paper-based or whiteboard schedule is a good thing.
• Having said that, having an IRC channel for the conference was a good thing.
• Conference runners. Have people who tend to the attendees and conference only — this might sound obvious, but some conferences don’t do it.
• Encourage attendees to leave sessions if they’re not getting something valuable out of them. I think this raised the bar at the summit.
• Care. It’s obvious the summit was a labor of love for the organizers. It shows — and it shows at conferences when the organizers are just going through the motions. (No, I’m not going to name names… praise publicly, criticize privately…)

This entry is filed under Community, Events. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.