On 2019-01-09, Software Freedom Conservancy ran a Google Summer of Code (GSoC) advice session for projects. The session occurred in the #conservancy channel on Freenode IRC.
Below is a summary of the advice followed by a complete transcript of the advice session.
- This list is very important for the committee selecting projects to participate in GSoC.
- Things to consider while building the list:
- Does the idea fill an empty niche in the software?
- Does the idea increase the quality of the software?
- Does the idea not involve project infrastructure?
- Does the project have a developer right now who would be willing to do the work if there weren't a student?
- Is this idea achievable by a student during a single season (summer in the Northern Hemisphere)?
- Projects that have not participated in GSoC before are limited to 2 students in their first year of participation.
- Consider whom you wish to attract to apply, then build your ideas list and other documents for that audience.
- Advertise the project's participation in places where your desired applicants hang out.
- Be clear up-front about what's expected of students (commitment, delivery, communication, etc.).
- Discover what an applicant can actually do, not simply what they say they can do.
- Include one or more qualifying tasks (basic coding, git knowledge, etc) in the application process.
- IRC interviews of short-listed applicants can help weed out the less qualified.
- Consider having a video call between the mentor and their potential mentee.
- Please see the Mentor Guide: https://google.github.io/gsocguides/mentor/
- Make sure they're both qualified and committed.
- A good mentor not only knows the code but also can connect the mentee with the community.
- Therefore people with a passing interest or only peripheral involvement with the project are not good options to be mentors. They do not have the necessary community connections.
- It's usually best if people mentor for ideas that they themselves suggested.
- Ensure that mentors know what's expected of them (commitment, delivery, communication, etc.).
- Being a mentor typically takes more time than people think. Therefore, prevent mentors from taking on too much (like handling multiple students, especially if they've not mentored before).
- It's better to mentor a small number well than a larger number badly.
- Try to get students to structure projects as a series of subprojects, each merged in turn.
- Release early, release often.
- This keeps students motivated (yay! my code is merged! let's do more!).
- It also prevents having a branch that's 3-months-diverged from master at the end.
- Avoid the code-code-code-test-test-test-document-document pattern.
- Coding, testing, and documenting should be interspersed and ongoing.
- This prevents having a pile of undocumented and poorly tested code at the end.
09:23 freedeb: 2pm (aka 90 minutes or so from now) we'll be doing Q&A on how your project can apply for GSoC in here.
09:23 freedeb: ...thanks to some lovely volunteers who have done it before. 3
09:32 Mc: my question will be "how to attract good applicants ?" ^^
10:45 bluesomewhere: o/
10:46 bluesomewhere: I'm loaded up with meetings but I'll be lurking during the Q&A and am happy to jump in as needed ^_^
10:49 freedeb: thanks bluesomewhere!
10:51 xavier-houdini: Hi folks, xavier from Houdini. I've been the admin for civicrm GSoC for 4 years, and mentoring a few years. I went to a GSoC summit and we discussed a lot about how to have a successful GSoC, and what are the key things Google look at to select projects.
10:51 Quozl: bluesomewhere: welcome.
10:57 olly: morning
11:01 olly: it's time, should we begin?
11:02 — Quozl attends (Sugar Labs)
11:03 xavier-houdini: Olly, I got my beer, I'm ready ;)
11:05 olly: i've been involved with GSoC as a mentor and org admin since 2008, with SWIG, Debian, and (mainly) Xapian
11:07 xavier-houdini: Has someone else already participated at GSoC? are you considering applying this year?
11:08 Quozl: xavier-houdini: sugar labs has participated regularly, and has decided to participate again this year. (decided 4th jan meeting).
11:08 Quozl: xavier-houdini: i've not participated directly as a mentor, but expect to this year.
11:09 jaylett: I've mentored and admined for Xapian alongside Olly.
11:11 wwahammy: I've been a mentor before twice but done the mentoring organization side
11:11 wwahammy: *never done the mentoring organization side
11:12 h01ger: same here
11:13 olly: we had one advance question: Mc: my question will be "how to attract good applicants ?"
11:13 olly: you can try to think about who you want to appeal to when you put together your ideas list and other documents
11:14 xavier-houdini: so if you have already community members that happen to be students, these are obviously going to be good applicants
11:15 olly: and potentially advertise your participation to places where you might find good applicants - e.g. for xapian we usually send a message to an academic information retrieval mailing list, and have found at least one good student that way
11:15 olly: a lot of it comes down to filtering though
11:16 xavier-houdini: Beside that, having a good project list, and being good a filtering the less good applicants
11:16 jaylett: xavier-houdini it's worth thinking in that situation about what the purpose of GSoC is for you. If it's growing the community then that's less helpful than other things you could do. (Also, I'd assume your existing community members are more likely to apply without prompting once you announce.)
11:16 Quozl: i once thought that good project ideas attracted good applicants, but sometimes it doesn't. also we've had one or two seemingly manufactured identities demonstrate amazingly good capacity for coding during the lead-up, and their capacity mysteriously dries up once the task begins.
11:17 olly: for example, most orgs include some sort of simple "qualifying task" in their application process
11:17 olly: sadly there is some fraud going on
11:18 xavier-houdini: GSoC is big enough and will bring you candidates, with motivation and competence that are variable
11:19 wwahammy: Does anyone have experience with fraudulent students as it relates to your potential to get GSoC in future years?
11:19 xavier-houdini: Beside the qualification tasks (basic coding, understanding git...) we do have a video call between the potential mentor/student
11:19 wwahammy: i.e. if you accept students who are fraudulent, even in good faith, are you going to get blacklisted?
11:19 olly: one thing to be aware is that if you're a new org to gsoc then you're likely to be limited to two student slots so you don't need (or really want) to attract dozens of good applicants
11:20 olly: wwahammy: i doubt that's an issue, unless you tried to collude somehow
11:20 Quozl: wwahammy: i've not had that level of experience, i've only been suspicious. we also attract mentors who haven't been more than peripherally involved with our project, and we had one gsoc student call us out on it last year. we want to tighten up mentor acceptance as a result.
11:20 olly: you may see mentors turn up you've never heard of, which seems likely to be a scam
11:21 olly: i'm guessing it's often a student trying to mentor their friend
11:21 Quozl: we have tried in the past to pair these new mentors with our regular contributors, but they outnumber us.
11:22 olly: a mentor who doesn't know your code or your org isn't going to do a good job anyway
11:23 xavier-houdini: For all the projects, we always have at least one mentor that is active and known in the community. If you don't have enough in your community to mentor all the potential projects, I wouldn't take them with an unknown one
11:23 olly: at least in the first year, number of mentors isn't likely to be your limiting factor anyway
11:24 xavier-houdini: beside knowing the code, the mentor needs to connect the project/student with the community. She needs to be part of it already to be a good mentor
11:24 — Quozl waves at karen
11:25 olly: wwahammy: related to your question, google say that failing a student doesn't work against you (unless the org was negligent perhaps) and from experience that seems to be entirely true
11:26 olly: we failed 3/6 in 2016
11:26 olly: sorry, 2014
11:28 Quozl: with me, a criteria for ideas was proposed by one of our most successful students last year, for this year; does it fill an empty niche in the software, does it increase the quality of our software, does it not involve project infrastructure, and do we have a developer now who would be willing and able to do it if we didn't have a student. the criteria are not yet clearly accepted by all involved, but it's an interesting view.
11:29 olly: Quozl: is the last one a positive or negative?
11:32 Quozl: olly: both. it was a response to mentors who didn't seem to know enough about the technology (python, gtk, javascript) to effectively mentor.
11:33 olly: ok
11:33 Quozl: olly: but my guess also is that mentors hadn't been involved enough in the idea creation.
11:34 olly: it's often best when people mentor ideas they proposed
11:34 bluesomewhere: wwahammy olly Quozl: on the question of what happens if you accidentally accept a sketchy student without realizing -- we never penalize orgs and mentors who are acting in good faith :o)
11:34 jaylett: We have ideas which we'd be happy to see, but I doubt anyone else would actually get round to. But those ideas did largely come from us.
11:34 xavier-houdini: For us, the main criteria is the mentor, if we have someone in the community that is willing to commit the time to mentor, the project is good and useful enough. The only extra criteria is "is this doable by a student in the summer?"
11:34 Quozl: olly: we also have a fractured community, so these controls would not be necessary in some other projects.
11:35 olly: the worst seems to be when someone proposes an idea "but I don't have time to mentor it" and then someone else is persuaded to mentor after a student writes a proposal for it
11:36 Quozl: students are sometimes like home made rockets ... you light the touch paper; some fizzle, some bang, some launch and fly high.
11:36 bluesomewhere: that is a magnificent analogy.
11:36 olly: (bluesomewhere is with the team at google who run gsoc, for those not aware)
11:37 bluesomewhere: olly++ thanks for clarifying, I should've said as much earlier :D
11:37 xavier-houdini: We only list ideas for projects were we have mentors we know already, almost always projects they proposed
11:39 olly: before i forget, https://google.github.io/gsocguides/mentor/ is a great resource, and also #gsoc on freenode has a lot of experienced mentor and org admins who can answer many questions
11:40 wwahammy: Does anyone here have experience with a UI design-heavy GSoC project?
11:40 olly: (disclaimer: i co-wrote the original version of the first one)
11:41 xavier-houdini: It's a great resource indeed, thanks!
11:41 olly: no, though we have found that projects which rely on the student creating a public API often struggle with that part, so I'd worry that UI design might have similar issues
11:43 Quozl: wwahammy: most of our project ideas are UI design-heavy; sometimes we get a student to use mockups, or walkthroughs, and then critique what is built.
11:44 Quozl: wwahammy: sometimes whatever the student does is just accepted because nobody has an opinion, and later on we might change it once someone pays enough attention to have an opinion. ;-)
11:45 wwahammy: Quozl: could I see what you've done before as well as what students have submitted?
11:46 Quozl: wwahammy: prior years are in our wiki, https://wiki.sugarlabs.org/go/Summer_of_Code/2018 is last year's page. we're thinking of github instead this year, and the parent page points there.
11:46 Quozl: wwahammy: but i'm not administrator for gsoc, so things may change again.
11:50 olly: were they any further questions?
11:50 wwahammy: So, I have to ask: is everyone happy with the results you get from GSoC?
11:50 olly: it varies I think
11:50 Quozl: wwahammy: sometimes. depends on the rocket.
11:51 Quozl: wwahammy: i'd say it's not a substitute for fixing anything that ails your community or project. it amplifies failures you may already have. ;-)
11:51 wwahammy: Pshah, I can aplify my failures just fine on my own :)
11:51 Quozl: heh.
11:52 @vmbrasseur: For projects that have never done GSoC before, what are the three things you think they should know? (number selected arbitrarily)
11:52 @vmbrasseur: (the 2-intern limitation is already known)
11:52 olly: the ideas list is very important
11:52 olly: for selection
11:53 olly: find out what a student applicant can actually do, not just what they say they can do
11:53 jaylett: Ensure your mentors understand what's expected of them. Ensure your students do too. (Repeating these things regularly seems to help.)
11:53 olly: some will promise the world to get selected, but that doesn't really help anyone
11:53 xavier-houdini: mentors preparation. it takes longer than you think to mentor
11:54 olly: we've been doing IRC interviews of the shortlist in recent years, which takes a lot of time but i think has avoided a few bad choices
11:54 olly: and don't overcommit as a mentor
11:55 olly: it's easy to see all these promising applicants and think it's a shame not to accept another one
11:55 olly: but it's better for everyone to mentor a smaller number well than a larger number badly
11:55 olly: the 2 limit helps enforce that the first time around though
11:56 olly: i'd also suggest trying to get students to structure projects as a series of subprojects to get merged in turn
11:56 olly: that helps to avoid having a branch that's diverged from master for 3 months at the end
11:57 olly: and avoid the code-code-code-test-test-test-document-document pattern
11:57 xavier-houdini: I would suggest at short video interview too between the potential mentor/student as part of the selection process
11:57 olly: which goes badly when things overrun and you have the code written, half tested but undocumented
11:58 Quozl: i'd also suggest having release-early release-often in the list.
11:58 Quozl: so many projects end up being released by others later.
11:58 freedeb: we're getting to the end of the hour
11:59 freedeb: thanks to our volunteers, olly and xavier-houdini for helping out today!
11:59 olly: the very first gsoc project i mentored in 2008 for SWIG got merged in 2018 after being worked on by a second student in another year and other contributors over time
11:59 pintoch: it was very insightful, thank you all :)
11:59 olly: lesson there is don't overscope I guess
12:00 wwahammy: Thanks so much everyone!
12:00 Quozl: thanks for your time, everyone.
12:00 freedeb: cool, I think we'll do another one of these next month on submitting talks to conferences
12:00 olly: if you think of further questions later, here or #gsoc are probably both a good places to ask
12:01 freedeb: in the meantime, tell your friends we are awesome and that they should donate to Conservancy
12:01 freedeb: we have 6 days left on the match
12:01 freedeb: so your help is appreciated
12:02 Quozl: oh, wasn't aware, thanks.
12:02 freedeb: also, in the meantime if their are other skillshare style topics, you'd like to see us host in here, let me know
12:03 freedeb: you can email deb@sfconservancy.org especially if your idea is lengthy and well-documented
12:04 freedeb: Quozl, we are a non-profit
12:04 freedeb: https://sfconservancy.org/supporter/
12:04 freedeb: we host nearly 50 community-driven free software projects