SoC 2009: We need a team (or, webchick's braindump about SoC)

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
webchick's picture

While Google hasn't officially announced anything to my knowledge, word on the street is that the Summer of Code program will be running again in 2009. If it runs as it did in 2008, then it would be publicly announced next month, and applications from mentoring organizations (that's us - Drupal) to participate will be due the first week of March (just in time for everyone to be distracted by Drupalcon! ;)).

Traditionally, I've sort of headed up the administrative, getting-the-ball-rolling process at the beginning of SoC, and making-sure-things-are-chugging-along during the middle, with the help of Drupal's tremendous mentoring team. There is one BIG snag this year though -- last fall I got named Drupal 7 core maintainer, and have had to cut all other "extra-curricular" duties, and that includes SoC. :\ We therefore urgently need to look at a sustainable way to spread this responsibility across the mentoring team so it doesn't create a "single point of failure" in our organization.

So let's pre-preemptively start talking strategy about how to tackle managing SoC moving forward. Here's a brain-dump of everything related to managing SoC that will need to be looked after, preferably by a team of former mentors, students, and ardent summer of code fans.

Want to help? Sign yourself up!

What happens during SoC?

SoC is roughly broken up into 6 phases:

  1. Pre-applications: There is a bunch of up-front work that needs to be done in order to submit an application to be a mentor organization in SoC. Among the tasks here include recruiting mentors, coming up with potential SoC projects for students to work on, and working out logistics about how the later steps are going to happen. Work should ideally start on this now, or very soon.
  2. Submitting mentor application: Each organization that takes part (Eclipse, Drupal, Apache, etc.) needs to submit an application in order to be accepted into Summer of Code. There are a variety of questions, about motivation, about plans of attack for various problems that come up, etc. Here is our application from 2008, for reference.
  3. Reviewing student applications: If we're accepted as a mentoring organization, about a week later applications will start coming in from students. These need to be reviewed and voted on by the mentoring team. Voting ranks the applications, and the number of slots we get from Google will give us the top N applicants.
  4. "Community bonding" time: There is a 2-month period before Summer of Code officially starts that's intended to be a bit of 'dipping baby toes' into the water of a community. Things like getting a CVS account, setting up a wiki page / drupal.org project. Beyond that, we didn't structure this last year (for example, write 3 core patches) and I think we should seriously think about doing something this year.
  5. Summer of Code: Here's where the actual coding and mentoring happens, over the summer. The biggest thing to do here is to make sure students (and mentors!) are keeping on track and not falling off the face of the earth. Constant communication is key. Be aware that Google will require a mid-term and final report from all mentors and students, and the mentors never follow through, so you will need to beat them.
  6. Post-Summer of Code: Here's an area where we've traditionally kind of failed miserably. Far too often, students get to the end of SoC and we never hear from them again. We should start envisioning ways we can entice students to stick around for the long-term.

About Mentor Recruiting

The more mentors we have in the more diverse areas, the more of a chance there is we can take more students. Mentors should be knowledgeable in their subject matter, kind and patient with new people, and available for at least 5-10 hours/week over the summer. You'll need gmail addresses from all of them, because they'll need to be added to the mentor panel on Google's side. If the timing works out, recruiting at Drupalcon would be ideal.

Traditionally, Drupal has had a system where each student is assigned two mentors, in case one is unavailable. I believe there's some contention around how well this works in practice, so we could talk about changing this if we want. The downside of the two-mentor rule is that if we end up with 20 slots again, that means you're essentially managing 60+ people and making sure no one's slipping through the cracks. This is really challenging, and is worth putting some thought into from the outset on how to deal with this.

Experience has shown that lots of people want to be mentors in theory, but can't actually hack it when the time comes (almost universally, due to unforseen unavailability). I recommend pairing a known experienced mentor with a new keen one. More often than not, the new keen one will be the superstar, but the old experienced one can lend guidance when required.

About Project Proposals

A good proposal is challenging. It needs to be specced out, but not too specced out. It needs to be do-able within a 2 month timeframe, bearing in mind that about half of these students are coming in with no Drupal experience. It needs to have community support. And, it needs a competent mentor (preferably more than one).

Last year, we handled this by asking community members (and students!) to propose their projects on http://groups.drupal.org/soc-2008. This allowed them to be vetted, which was actually kind of nice because it weeded out a few that were never going to be accepted. It also helps when ranking the applications if something has a lot of people excited about it.

Once a proposal is vetted (and if it did NOT come from a student), we added them to a "official" ideas list at http://drupal.org/google-summer-of-code/2008/ideas-list. I think this might've been confusing for people, but I couldn't really think of a better way to balance the community vetting process and an official reference we can point to in our application.

About Application Ranking

This process has traditionally always been messy... you'll end up with 10 or 15 applications with +10 votes, 10 or 15 at the bottom with -10 votes, and everything else (100+ applications) hovering around +2 to -2 until you start begging and pleading with people to rank the dang applications. Furthermore, experience has shown that applications only are in no way a bullet-proof way to judge a candidate. We've had to fail people from SoC for going completely AWOL or otherwise losing touch. This looks bad for us, and bad for the program. Furthermore, our SoC student retention rate after SoC is pretty so-so.. we either end up with complete rockstars or we never hear from them again.

Ideas on how to optimize this process to ensure we're getting quality students who are going to stick around are GREATLY appreciated. Other mentoring organizations have done things like requiring IRC interviews, quizzes, and "assignments" (code a simple module) prior to accepting students. This might be an avenue to explore.

About SoC itself

Students you have to worry about going AWOL but more than that you need to worry about mentors going AWOL (or at the very least not checking in with the normal announcement channels that point out when reports are due, etc.) I have yet to find a good solution to this problem. The only thing I can think of is requiring that all interaction be held publicly in the issue queues or g.d.o. No e-mail correspondence. If there's no posts to the queue in a day or two, slam an e-mail at the mentors and student and ask what's up.

What I did last year was make this horrendously awful table which was a complete PITA to update so I never ended up keeping up with it. But something like that is probably the only way you can keep everything straight, or at least it was for me.

We might also want to think about requiring daily commits (or at most twice-weekly). Another huge problem is students who are bright tend to be perfectionists and think that code needs to be perfect before they show anyone. Breaking them of that habit early (and often!) is important, not only for transparency and to make sure they're staying on track, but also to help them break out of the "school assignment" mentality and more into the "contributing to a living, breathing ecosystem" mentality.

One thing we tested this year was having each student use a wiki page to post status updates, etc. In retrospect, kind of think this was a mistake. We should probably just have them use their drupal.org project pages for current status, and use the SoC group for posting announcements, weekly status reports, etc.

It's possible that the two of these might help our student/mentor AWOL rate. I'm not sure.

About Planet SoC

http://planet-soc.com/ is a site that the Drupal community has traditionally provided each year to aggregate student/mentor blogs. As you can see, it's become horribly neglected. :P But during SoC, students really seem to like this.

Robert Douglass has the domain and the current server it's hosted on, and I know that he would like to have it moved off his machines. If someone wants to keep up the tradition this year, that would be awesome.

Hm. I think that's everything I know about SoC in one big brain-dump. :P Feel free to ask any other questions.

Okay, so how are we going to do this?

Comments

Sign us up

Alex UA's picture

I just sent you an e-mail, but I'll post it again here. Basically, my business partner (Jody Lynn here and on d.o.) LOVED working on the GSoC last year, and we were thinking that helping out would be a great way to get our entire staff (we're now up to 11 people,, including the student--jtsnow--we mentored last summer) more deeply involved in the community. Anyway, here's the e-mail I sent. As I asked in the e-mail: "what can we do to help?" We're ready to take the lead, take on a bunch of these tasks, or whatever else is needed. Go GSoC!!!

Here's the e-mail I sent:

It was great to hear today that the GSoC is happening again this year! We really loved mentoring last year and hired our student immediately afterwords, and it's obvious how amazing it's been for improving Drupal and expanding the community!

Anyway, Jody and I have been planning on mentoring again, and we've been considering having all of our employees give a hand with the program in some way as well. Given your current role as the maintainer of Drupal 7, and given the fact that it doesn't seem like it will be done before the summer, we were wondering if there were other ways we might be able to chip in. At the moment our firm is up to 11 people, and it's highly likely we'll be somewhere around 15 by the time the summer roles around, and while I'm sure it will have to be one person who is actually "in charge" for what we do, we are willing to put everyone here to work for the program.

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

I'm in

gdd's picture

I would definitely like to be involved again, and I would be more than happy to get involved with the administration / cat-herding aspects of the program. However I'm slammed with work until after Drupalcon so I can't help much with the rampup. After that I should be clearer though.

As far as improvements over last year, I really liked the way we vetted submissions on g.d.o before pushing them to the "official" ideas list. While there was some confusion around it, it also weeded out a lot of things quickly, while also making many submissions much stronger through a revision process and community feedback. Perhaps the workflow/documentation of it could be improved, but the concept as a whole was, I think, great.

I like all the suggestion for the process of the actual program, especially forcing students into frequent commits as well as using their project pages as the place for status updates. If we end up with a group of people administering the program this year instead of just one (which seems reasonably likely) it will be important that everyone can get an idea of where a project is at quickly, and without having to dig around or send out emails "Anyone know what's going on with "? This goes for the mentors too.

One thing I suggested to Angie in IRC last night is the possibility of having a Drupalcon session on SoC to help build excitement and share some success stories from last year and/or years past, both from the student and mentoring sides. This would be great exposure for the program and hopefully would build some excitement.

Woo! Bring it on!

I created a GSoC 2009 Group

Alex UA's picture

http://groups.drupal.org/soc-2009

I figured it was a small step to get the ball rolling.

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

I also added the GSoC 2009 book page

Alex UA's picture

There isn't actually a site for this year's GSoC yet, but I figured I'd post the book page for this years contest here: http://drupal.org/node/356993

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Awesome!

webchick's picture

Thank you for getting the ball rolling! :)

我也来试一下哈。

renjunok's picture

我也来试一下哈,不好意思。

Hi, I'm new here

emmajane's picture

I haven't participated in SoC before, but I'd like to be on your team. :) I'm happy to participate at the "meta" level of coordination.

Sign me up as a mentor. I'd

David Strauss's picture

Sign me up as a mentor. I'd also be happy to host Planet SoC on a Four Kitchens server.

do what i can

add1sun's picture

I'd love to help out and the docs team may even have coding tasks we can put forth, and I'd be willing to mentor on. Beyond mentoring I'd have to say that, as much as I'd love to, I've got too much on my plate this year to help much with admin stuff. :-/

Lullabot loves you
Our O'Reilly book is out! Using Drupal

Learn Drupal online at Drupalize.me

Created a sign-up wiki

webchick's picture

http://groups.drupal.org/node/18127

This documents all of the various "we need people to do X" roles, as well as the timeframes in which they need to be available. I haven't quite finished sketching out all the profiles (the ones we need in the next month or two are there, though). I will try to finish that up in the next couple days.

So, if you want to help out with SoC, go pick something from that list of people that looks interesting and a good fit for you and slap your name on it!

HUGE thanks to Alex and Emma Jane for stepping up to take on Organization Administrator roles. Hope to see lots of people step up to fill in the rest! :)

(Note: I didn't fill in the names of people who'd commented here because I felt like it was best if you read the descriptions first to make sure it's still a good fit, and then did so yourself.)

You are welcome, but...

Alex UA's picture

...I'm not trying to step on anyone's toes. I (really 'we') would be happy to help in any way I (we) can. With that said, if nobody else wants to take the lead we certainly are willing and able.

Also- in regards to the various roles- should I be signing up for any roles I might fill? For example, I'm a fairly good whip cracker, and would be happy to sign up for this as well, but I also don't want to put myself down for everything.

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Oh by all means!

webchick's picture

Sign yourself up for as much as you think you can handle. I only suggest that you don't sign yourself up for everything because it does us all no good for you to get burnt out by mid-SoC because you've taken on too much work. ;) It is also advantageous from a sustainability perspective for as many people as possible to help with various aspects, because this helps spread around the knowledge community-wide, rather than amongst a small handful of people.

But you have a big thing going in your favour where you've already taken part in a previous SoC, so can help lend experience to new people who might not have already, but still want to help. So it'd be good for you to put your name down on anything you think you could kind of take the "lead" in, and find other people to help support you on all but the "primary" role(s) you plan on taking.

Does that make sense?

Makes Sense

Alex UA's picture

I understand your concerns, though I think I'm pretty good at delegating before I get burned out. As I mentioned, it wouldn't just be me doing the work- I'll be asking everyone in our firm to lend a hand. I also love getting new people involved and I think it would be great if as many people as possible commit to lending a hand as possible.

This likely means that we'll also try to mentor a project (I wouldn't be the mentor) or two.

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

On delegating

emmajane's picture

Just my little heads up on this point: the tricky thing with delegating is that it contributes to the Mythical Man Month (projects take longer when you throw new people into the mix late in the project). I think we're best to have people who can contribute from the beginning, to the end, in a single role without needing to delegate.

Mythical Man Month?

Alex UA's picture

I've never heard that term till now (for those who are like me, check the wikipedia entry), though I think that it's specific to hard core development, engineering, or other projects that take a long lead time to get acclimated. It certainly can not be referring to delegation of administrative tasks, since that would basically mean the entire business world would be in a near constant state of slowing down.

To recap: delegation of highly technical tasks midway through a project = bad, delegation of annoying/time consuming administrative tasks at any point of a project = Getting Things Done. In this case I'm talking about the second form of delegation, as we're talking about the mundane tasks involved with administering this project, not the technically skilled tasks involved in each GSoC project, so I'm pretty sure that your point is not really all that applicable. I can promise that I wouldn't delegate any tasks where it would take a person longer to get up to speed than to help me get something done, and either way I take full responsibility for not just my own work, but for the work I've delegated as well. (Also- don't assume that the people I will delegate to won't already be fully up to speed on everything in the project- for the most part they work in the same office as me, so I'm sure they'll be hearing plenty about it every step of the way)

To give one small example: I will likely have all of my staff helping me to recruit mentors at DrupalCon (manning a table, handing out brochures, signing people up/collecting business cards, etc) Does this seem like an area where the "Mythical Man Month" applies?

Anyway, I'm not sure this is the best place to get in a long discussion about managerial techniques, I just want to put any worries about what I'm stating to rest. I have 9 people working for me (as well as a business partner who supports this), and I have every intention of having them all help out with the GSoC, either helping me on the admin side or by mentoring a project.

--
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

I think both of you are correct...

webchick's picture

"Emergency" delegation is absolutely not a good way to solve problems, and in fact tends to make things dramatically worse (believe this is what Emma refers to with the Mythical Man Month reference). But pre-emptively putting a strong team of individuals in place who understand ahead of time that they will have tasks delegated to them so that you are not holding the burden is a very, very good idea indeed.

I would still love it though if the employees from your company who you plan on getting to help out with various things could put their names on the sign-up wiki, both for transparency/re-assurance purposes, and also to help fill it out a bit since it's looking a little lonely still. :D

Oh, and feel free to tweak the sign-up roles...

webchick's picture

I was just brain-dumping all the ones I could think of that we had used before. So if this year, you guys want "Drupalcon SoC Table Stander Atters" and "Job Fair Team" as roles, and you DON'T want "Whip Crackers" (since you want the organization administrators to do this themselves or whatever), feel free to change it up!

I hadn't yet filled out descriptions for application rankers on up, but in thinking about it, it's probably best for this year's organization administrators to do this. You folks know a lot better than I do what level of cat herding you are comfortable with, and what sort of team you want in place to handle each of these tasks.

Absolutely!

emmajane's picture

A team of lots of people from the beginning is definitely fine! Even when I'm working with a client's secretary or someone that a task has been "delegated to" we still know what the team is and how it works. Where things start to fall down is when you aren't sure who the team is because of reassign responsibilities (which means other people have to spend more time to find the person that the task now belongs to). Of course some people might wear a range of hats, but it makes life a lot easier if the go-to person / decision maker for task XYZ is the same for the entire length of the project. I'm absolutely in favour of getting a sense of the whole team on the Wiki as webchick mentions. Let's figure out who we all are and what we're going to be able to contribute!

I fully agree with point 6,

SeanBannister's picture

I fully agree with point 6, we get a lot of SoC students who create a module and then it's left abandoned the day after SoC. We need a way to keep SoC students involved and personally I believe we should favor students that have a good past record of involvement.

bonobo's picture

One of the ways we could think about improving retention post-SoC is to have that be part of our criteria for evaluating projects.

Another advantage of publishing a rubric that lays out expectations is that it would clarify the goals/expectations for mentors as well.

Cheers,

Bill


FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education

My (controversial ;)) view on this...

webchick's picture

My view is that SoC isn't so much about getting usable code at the end (though it's always great if that happens), but about attracting and retaining new talent to the project.

I will use me as an example. ;)

My 2005 SoC project was the Quiz module. That module turned into an utter train wreck, because it was assigned to two students (myself and another guy), one of whom (guess which one? ;)) overbooked himself during the summer and wasn't able to get basically anything done.

So while half of the project was finished (the backend, storage stuff), the other half was not (the front end, "actually take a quiz" stuff). It then fell on my shoulders to try and finish the other half in between other things after SoC was over. I had it almost working, and then.... Form API happened. (anyone who remembers the Drupal 4.6 => 4.7 lifecycle is making a blood-curdling scream right now.) Of course this also happened just as I got a full-time consulting job, so the module was stuck in a limbo state for months.

So by the measure of "usable code", that project was a miserable failure. However, in the meantime, I had become an active member of the documentation team, I was reviewing dozens of core patches a week, I was responding to user support questions in the forum, I was evangelizing the Drupal project to everyone I came across, and so on.

By the time SoC ended, I had made tons of friends here, had learned the ropes of working with the community, and had completely caught the "Drupal fever." And I guess the rest is history.

(Happy side note: Quiz module has since been picked up by other people and seems to be doing pretty well now. And it's used on some pretty high-profile sites like Lifetime TV. Hooray!)

So hopefully, in the grand scheme of things, I have helped the Drupal project more than I have hurt it by the lack of usable code at the end of my SoC project. :P

IMO, our challenge is not "how do we get these students to continue slaving away on their projects after they're not getting paid anymore" (I realize this isn't what you said, but I've heard other people say this if you 'read between the lines'), our challenge is instead, "how do we get our students to become Drupal-obsessed and immersed in the community as a contributor?" If we figure out the answer to that question, awesome code will follow.

Very good point, I was

SeanBannister's picture

Very good point,
I was getting a little caught up in my excitement when I see all the SoC projects I want to use.

In saying this I do think it takes a certain type of person to want to be part of the Drupal community and not just make a bit of cash over summer. Obviously a student with an interest in web development not just programming has more chance of sticking around (bit of a generalization).

The most important thing we can do is be there for the students when they need a helping hand. One way I imagine we could do this is helping them with issues in their issue queues and encouraging them to post issues so fellow Drupalers can help them out. Possibly we could aggregate all SoC issue queues so everyone can view the latest issues and help out as quickly as possible.

Agreed

bonobo's picture

Retention of students, and new ideas in the community is more important than working code. But, if we can have both (and this is where a well-scoped, effectively mentored project can help), that's good too. In some ways, I see the FeedAPI as the poster child for what a successful SoC project looks like.

Cheers,

Bill


FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education

What motivates open source contributors, a biased view

jpetso's picture

I think the key point to getting people immersed in the community is to have the students work with the community - students will only get immersed if they have the opportunity to see the live action first hand. So maybe there's some way to structure the tasks as some sort of teamwork, hooking up people who work on stuff in any case with students who are able to help out with non-critical stuff. Appreciation of the student's work is also an important point imho - if you feel that your work is awesome, promising and important then those incentives lessen the chance of letting the project go.

Version Control API was of course a case of pure luck where all nice factors I can think of came together: awesome feedback from dww, webchick and others, needs to work together with existing code (project*) while being a sufficiently independent, and filled a need for at least some people (including d.o) but still has cvs.module as fallback if SoC had failed. I have no idea how to replicate all these factors for even a dozen of projects. Plus came out as self-constructed and self-motivated idea. Perhaps we should place a higher emphasis on letting students work on what they love to work on, instead of preferring stuff that we think we need.

Being the most unsuccessful mentor of last year's SoC though, my writings might not contain lots of helpful advice :P

braindump

jpetso's picture

Here's the usual unpractical jpetso idea: We could require a set of "artifacts" to include in the application. Say, a set of quotes found on drupal.org (from at least three different d.o nodes) and IRC quotes (from at least two well-known Drupal people). Related to their application, of course. Prior research requirements like that (better "artifact" ideas welcome) would force the students to look around and investigate the current state of things, it's not hard to do and encourages the students to look outside the box, and new contributors get to see what they're at with the Drupal community.

[edit: a few quotes are probably too easy still, and also less to the point than webchick's mini-GHOP suggested below. as always, webchick hit the nail on the head so i'm in favor of her proposal rather than mine :-o ]

Anyways, I'm all for posing a little hurdle that only motivated students are able to overcome. Not sure if this is just me, but I feel that the majority of Drupal's SoC projects to date has been significantly weaker both in ambition and student skills than for, say, Git or KDE, due to the low entry barrier on our side (or perhaps it's PHP as language, or perhaps it's really just perception without facts backing it up).

On preparing students for open source development...

webchick's picture

I think the key point to getting people immersed in the community is to have the students work with the community - students will only get immersed if they have the opportunity to see the live action first hand.

We were kicking around ideas in #drupal about this very topic, and here's a synopsis of the talk:

GHOP was an excellent program in this regard. Everyone who worked through GHOP understood how the community development process worked, because we mirrored our very same "getting things done" processes (issue queues, "code needs review", "code needs work", etc.) for "getting credit for GHOP tasks." And even if the students didn't stick around (which, if you look at raw numbers, most didn't), in almost all cases, we still got useful work done as a result. And the ones who did stick around became prolific contributors, and all of them core developers. (Note: Most contributed module developers I know with way more experience still think core development is "scary" and don't touch it.)

GHOP though is a very different animal from SoC. With GHOP, you're talking about small, bite-sized, well-scoped tasks that take a few days (or a few hours, in the case of boombatower, cwgordon7, etc. ;)) to finish. Although we had "scope creep" issues here and there, generally it wasn't a problem because we spent a lot of time up front authoring the tasks to ensure that they were well-defined. "Write tests that cover all of the following use cases in foo.module." rather than "Write some tests that catch some bugs somewhere in core."

With SoC, you're talking about both fuzzily defined projects (write a "Make everything more betterer module!") and also a dramatically longer timeline (3 months), so self-enforced time-management (during summer vacation) becomes a huge factor. Couple that with the fact that we're generally dealing with people who are used to finishing assignments and NOT working on open source projects (which means you're battling perfectionism and 'work alone in a dark cave for 3 weeks and come out with something'-ism), and it's not shocking that most SoC projects fail.

Now. I'm not suggesting at all that we should nail down SoC project specs to the finest detail -- that eliminates a lot of room for creativity on the part of the student as well as some of the "fun" of making it "your" project -- but if students don't a solid grounding in the fundamentals of open source development before they begin, they are going to flail around and do silly things like bash their head on a bug for 4 days when they could've simply asked their mentor and received an answer in 30 seconds, but they didn't want to appear "stupid." Or at least this was my experience as a student. ;)

Google builds "Community Bonding Time" into the SoC schedule, and traditionally the only structure we've added to that is "make sure you get a CVS account and contact your mentors." That's it. That doesn't set them up at all for "real world" success in open source, so they end up trying to learn that on the fly during actual SoC when they are also supposed to be getting this project done. They are also usually learning Drupal APIs at this point in addition to how our community works, so end up getting frustrated and not making progress as fast as they hope, and so naturally some get demoralized by this and quit.

Whew! That was long. If you're impatient, just read this bit:

So what if we added some structure to the community bonding time and did sort of a "GHOP-lite," to help integrate students better into the community? Come up with a group of 50 or so of these well-defined, discrete tasks, and have accepted students complete one by Week 2, another one by Week 4, etc. By the time they started SoC, they would know who some of the people in the community were, they'd understand how to use the tools we use (CVS, issue queues, etc.), and they'd know their way around the Drupal API. So they'd be going into SoC in a much better position for success. AND, if you want to look at it through a sheerly practical lens, we would get some work done for our community, regardless of what happened with their SoC projects, and we could spot "problem" students while there was still time to swap their project for someone else's.

Organizing something like this is no small feat -- GHOP ate up 20 hrs/week of my time for 3 months, and I assume aclight's, too. But if we get some folks to spear-head this and pass along the responsibility for creating these tasks to a huge section of our community (each of which has motivation to watch it and give near-instantaneous feedback), I think this would be incredibly awesome and useful.

Also...

Being the most unsuccessful mentor of last year's SoC though, my writings might not contain lots of helpful advice :P

Your student may have been unsuccessful, but I am hard-pressed to think of anything you DIDN'T try to help and get that project back on track. If all of our mentors put half of the effort you did into making that project a success, we would be blessed. So stop talking like that, or I will come over there and beat you. :P

in tha face

jpetso's picture

I'll be at Drupalcon DC, so you don't have to come over. Can you beat me there? Please? :D

OT

bonobo's picture

If webchick is handing out beatings, can we get video coverage?

Sorry for skewing the signal to noise.


FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education

Thats an awesome idea

SeanBannister's picture

Thats an awesome idea webchick; "GHOP-lite".

There's 3 great benefits to this approach:
1. Students learn about issue queue, CVS, patching. And the general processes in place.
2. It gets them involved with the community and the joys of open source.
3. We get some tasks completed.

I agree that a student with

gdd's picture

I agree that a student with a great deal of passion for their project and working with Drupal should be given preference over a student who has a good proposal with wide-ranging impact, but who seems to be going through the motions or looking for a paycheck for summer work. I remember having discussions about this last year as well and its a good thing to continue to focus on.

That said, a student working on a project that only they are passionate about is going to isolate them more from the kind of community involvement that made jpetso's project so successful (both from a code and contributor growth standpoint). An ideal project will have both passionate student and community support, but I mean those stars aligning is going to be rare.

No answers, just thoughts.

Retention is spelled J-O-B

Alex UA's picture

I think the best way to keep people working within the Drupal community is to get them employment within real Drupal shops (i.e. shops that make it part of their mission to give back). We hired our student from last year, and finding more young talent is definitely one of our key motivations for being even more involved.

However, I can see how this might cause some conflicts, so maybe it would be good to do some sort of "job fair" after all is said and done?

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

YES

mikey_p's picture

Ultimately this is the deciding factor for most folks when it comes to contributing to Drupal. As much as webchick rocks (and it's alot by the way) it's hard to say what her Drupal contribution would have looked like had she not been hired by a Drupal shop, or if there was no Drupal related jobs to be had at all.

Can't argue with that...

webchick's picture

While I think I would've piddled away at stuff in my free time, it was definitely landing a full-time gig that ratcheted up my ability to be omnipresent. ;) Likewise, it seems like Drupal companies are always in search of talent. So SoC represents a good chance for mutual benefits.

I think there is a very healthy relationship that can be formed between companies who need X done (where X is something that would be generally useful to a wide swath of the community but they themselves don't have the bandwdith to execute on), and are willing to set aside some of their developers' time to mentor a student who can implement the idea. For them, the benefits are obvious: they get to "beta test" an employee before bringing them on, and if it goes well they have both the thing they wanted done completed, and a new employee who knows the ropes of Drupal and has worked within the community for 3 months. If it doesn't go well, that project goes back on the shelf as "that old project we really ought to get around to implementing someday..."

I don't really see a conflict, per se, with the caveat that it would be critically important to make sure that all SoC work was being done transparently and in the open (Drupal.org CVS/issue queues, etc.), and not in #company-chatroom or private SVN repositories and the like. Remember that each SoC project represents a $5,000 investment in the Drupal community, so it's important to "share the wealth."

I'm not sure what a "job fair" would entail, but it sounds kind of interesting. Could you elaborate about this out a bit more?

job fair

Alex UA's picture

I don't have anything too well thought out for a job fair at the moment, but I guess I was thinking that it might be a good way to deal with any students that don't end up working for their mentor after the SoC is over. My worry is that if we don't do something "official" to help match students who completed the program with shops willing to let them work part time while they are in school, then you open up the possibility of for "poaching" and other activities that might cause strife within the community. Even if we (zivtech) only mentored one project I'd love to hire more than one successful student, since the payback is so great. However, I don't want to step on any toes and I also think that it would be better for the students if they could have some choices provided for potential employment.

Then again, I also don't want those students to end up with non-community shops (i.e. those that don't give back), so I'm thinking that it should be limited to those listed on the provider list on d.o. That way there's at least some vetting already done on the company.

As to what form it would take- I think a single wiki page where each company would get a "listing" might suffice, or maybe even better (since it would allow us to limit things to "approved" companies and successful students), a private group (similar to the GSoC mentor group) where students and potential employers could chat in a more open, but somewhat protected, environment.

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Well...

webchick's picture

Well, be careful about loaded words like "poaching." If the student does work for Company A over the summer but then ultimately decides Company B is a better fit for them, we certainly can't force them to go with Company A, and Company A should be happy that the successful student they mentored is still doing awesome things in the community. And even if the student ultimately ends up writing .NET accounting applications for EvilCorp, that's okay too -- the Drupal community (including Company A) still receives benefit from the code that they wrote over the summer.

It's important to have a holistic view about SoC and not just see it as a recruiting tool. One really big way to help with that is to set yourselves up to mentor projects that your company is specifically interested in seeing come to fruition, so that even if students ultimately don't choose to work with you, you still get direct value out of the arrangement.

In terms of an online job fair of sorts though, maybe one of our SoC project ideas this year can be implementing http://drupal.markboultondesign.com/iteration11/marketplace.html as part of the Drupal.org redesign, and one of the features of marketplace could be to promote those companies who are contributing back (and marking them in a special way if they're hiring).

I hear you...

Alex UA's picture

Poaching was definitely a poor choice of words, I'm just thinking of a way to both lower the potential for conflicts within the community of mentors (both individuals and the companies they work for) and show students the the wide array of employment choices they have once they've dived deep into Drupal. Essentially, I don't want to be restricted from recruiting from within the program, and don't want to rub anyone the wrong way (or at least as few people as possible) if I try and hire students they've mentored. I just think putting it out in the open would help everyone involved, and maybe that marketplace is a great place to start...

I'm also not questioning the value of getting people to contribute over the summer even if they choose never to use Drupal again, nor the need to appeal to the self interest of potential mentors, just trying to head off (imagined) conflicts before they arise. I'm pretty superstitious about taking any opportunity for advancement you can no matter how small. For example, I never pass a penny I see on the ground even though I always give away the change in my pocket to anyone who asks. You just never know when that penny you passed over might be the one you (or the person you give it to) need to get by.

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

I love getting new people

prav777's picture

I love getting new people involved and I think it would be great if as many people as possible commit to lending a hand as possible.I remember having discussions about this last year as well and its a good thing to continue to focus on.

Prav

Australian Dating-Australian Dating

SOC 2010 is up!

rpfilomeno's picture

Any gdo thread already up for SOC 2010? (Excited) :D

LH announced it at: http://groups.google.com/group/google-summer-of-code-discuss/browse_thre...

2011

drupalsmutant's picture

what about this year any updates?

It's on!