Archiv für den Monat: November 2011

TYPO3’s Summer of Code (Part 2)

Like I promised this is the second part of the „Summer of Code“ article. If you have no idea what this is about, read My Summer of Code here.

This blog post is almost only about what I think needs to be improved. It’s not about how to actually solve these issues (in some cases I actually don’t have any idea how). Consider this being an invitaion for discussion. I’d love to get your feedback, thoughts, ideas on this article and GSoC in general.

Do not hesitate to drop me a mail, nudge me on twitter, jabber, skype or leave a comment below.

„You’re are doing it wrong“

As I already wrote in the last article:

We, the mentors, the students nor the org-admins of TYPO3 did not do it (completely) wrong. But – hey – it’s a budget of 27.000 US$ for TYPO3. We definitly should get something out of it, right?

While chatting and listening to other people at the Mentor Summit talking about their projects, their students, and their summer, I realized that we (TYPO3) didn’t take advantage of the possibilities. And it’s not just us. Many organizations had problems finding qualified students, filtering the proposals, projects worth doing, actually merge/use the code the students produced, and maybe most importantly keeping the students contributing after the summer.

The issues (from my point of view)

Here is what i think are the major issues:

  • What’s our goal participating in GSoC?
  • Improve communication.
  • Choosing qualified students, choosing the right proposal.
  • Define the tasks and guides for the student and the mentors.

In more detail:

What’s our goal participating in GSoC?

The major question while reading this article and for all mentors participating: „What’s our goal participating in GSoC?“.

  • Is it to get (a little) buzz about TYPO3 in the Open Source world? Is it just to be part of the summer? GSoC is a great opportunity. We should get more out of it.
  • Do we want to get new contributers? Students, who do their project and stick to it (and the TYPO3 project in general) after the summer, becoming an active contributor?
  • Do we want to get things done (maybe things no one else cares about)? We have a bunch of tasks we could let a student do. But on the other hand not all tasks are suitable for a student, especially for first time contributors like most of the students are.
  • What’s going to happen with the code the student contributes? I think it’s important that the student’s code should find its way into the core or at least should be used in a real project afterwards. This definitly has an impact on what could be a GSoC project and what’s not suitable.

When we – the mentors – are reading and voting on the students‘ proposals, no one told us what the „goal“ is. To be honest I didn’t even think about it in the first step myself. Actually it just poped up in my mind while writing these lines. If you are a mentor or going to be a mentor, you should ask yourself why you are participating: what’s your personal goal? What’s your student’s goal? And what the organization’s goal is about.

TYPO3 should have a defined goal for participating. At least a general goal, why participating at all. And maybe we can have a goal for the upcomming summer, too. E.g. if the summer’s goal might be something like „improving usability“ (although it’s not a perfect example), one can look for a task, which will help to reach that goal. This does not mean a student can’t propose anything else as a project. The goal should be a guide, an idea where to go in the big picture.

However, the goal needs to be discused before the studends apply and all possible mentors should participate in the discussion or – at least – should aggree on it.

And maybe someone already thought about it and defined a goal for TYPO3 in GSoC in general. I did not ask anybody about it. But if someone did, it’s a lack of communication.

Improve Communication

This is a very general issue. We (including me!) definitly need to improve communication on all levels. Between the mentors, between the students and especially to not-GSoC-participating people.

To give an example: I – as one of the mentors – had no idea what the status of the five other projects was! To be honest and in retrospect: i didn’t ask anyone about it. I’m pretty sure most of the others had no idea how our (Pascal and mine) project is going. At least I (as one of the inner circle) knew the subjects of the single projects, but most people from the outside have no idea what the projects are about, what the project’s goals are and what the status is.

During the summer (correct me if i’m wrong) we had like two posts about GSoC on http://typo3.org (1, 2). At the end of the summer no final post/summary was posted yet. I know it’s prepared and almost finished, but it’s not published however.

Reminder: this is not to offend someone. I know we all are busy and writing blog/news articles has a pretty low priority. Hey – it took me more then 5 weeks for this article, right. Just saying people are curious about what’s going on and have no chance to get any information if no one communicates about it.

Oh yes, we have a mailinglist and two IRC-channels for the students and the mentors. I had started a little indroduction thread (i think Karsten suggested it) in the mailinglist back in May. Not even that was answered by all students. Even worth: not one other mentor replied! After that half introduction thread only two other threads appeared on the list: one student asking for feedback (Yay! \o/ wish to read more like that one) and one thread someone asking for the results of the summer (reasonable question, see above – no real answers in that thread).

We also have http://buzz.typo3.org, which lacks of buzz at all (in general, totally). So it’s not a problem of missing infrastructure or plattform or tools, it’s just no one using it (including me)!

What do you think? Can/should we „enforce“ more communication by e.g. requiring each student and each mentor to write at least one public status report per month/week? One paragraph should be fine and it’s more than nothing. Can/should the org-admins be more consequent and strict when asking for (short) paragraphs about the project untill a certain date?

Remember: students and mentors are getting payed for working on the project. I think it’s okay to expect some writing as a result of the project.

Choosing qualified students, choosing the right proposals

A really hard task for the mentors prior to the actual summer is choosing, and voting on the students proposals and the students itself.

Really: Some of the proposals are really crap. Copy and paste from the ideas page. Others don’t make sense at all for TYPO3. Again others are way to ambitious for someone who has never worked and/or contributed to TYPO3 before. It’s not too hard to filter these.

However the other proposals may not be final or perfect when the student hands them in either. We as the possible mentors should take care and help the students to improve their proposals. A little guide how a proposal should look like will definitely help.

Further having a goal for the summer could help to improve the quality of the proposals. If the students know what the goal is, they can focus on it and/or get inspiration how to reach that goal. I think this could increase the number of proposals as well as the quality of them.

When you have a well written and well thought-out proposal paper you still do not know, whether the student is a good student and if he can reach his goal. I heard from serveral projects who let the prospective students contribute a simple no-brainer patch to the project.

I really like the idea. Its an easy way to prove the student gets your workflow how to contribute. He learns about the infrastucture and the tools. And after all: if he took this hassle and got through it, he has proven that he is really willing to participate and contribute.

And if the student gets stuck, did not know how to start or how things work, it might be a problem with our documentation which really should be tackled. If the student can’t figure out how to contribute, how are others supposed to do!

Define the tasks and guides for the student and the mentors.

It really would help if we define what the general tasks are during the summer for the student (beside of doing and finishing his project) and the mentor.

This might be f.e.:

  • setting up a forge project.
  • regularly blog/write about the current status of the project (e.g. on http://buzz.typo3.org) and not only on mid-term and after the final evaluation.
  • having status meetings each week or maybe even twice a week (and stick to it).
  • as a mentor first reviewing the proposals and later reviewing the students code and his articles.
  • targeting on getting the code merged into the core (this could be an additional motivation).

These are only some rough ideas. The important thing is that we need to define these tasks and rules and even more importantly to write them down. For example „“The Perl Foundation““ has written down guidelines for mentors and students. We definitly should have something like that too.

Even more ideas…

What if we ask the students to come to the next T3CON or T3DeveloperDays to talk about their projects. Kind of a little TYPO3 GSoC summit with the students and the mentors. I know this might be hard to archive due to students being distributed all over the world and some not being able to afford coming to such an event. It’s just an idea. Maybe we could apply for a little budget at the Assoc (may be too late for 2012 though).

Two mentors for each project. I heard from serveral projects that they assign a second co-mentor for each student. Actually that’s a good idea. The co-mentor could help out if the first one is not available. He could write the article, reviewing the student’s code (two +1s from both mentors are enough to merge a change into the core). As the main work will still remain on the main-mentor, the co-mentor could be a co-mentor in multible projects at the same time.

Bonus: Mentor summit

One last thing: if you’re being a mentor during the summer: do anything to get the chance to go to the Mentor Summit. It’s really worth it! And we really should send two mentors to the summit, not one going alone (at least one is way better then no one going).

So what do you think about the summer of code?
You are a student or a mentor? Tell me about the issues you had.
You did not participate in Google Summer of Code? Tell me how you have heard/read about the project and it’s outcome.

My Summer of Code (Part 1 of 2)

There are some task one keeps pushing from one week to another. Writing a blog article is definitely one of these tasks. I planed to write down my thoughts about the Google Summer of Code (GSoC) and the mentor summit in San Francisco, since the day the summit was over. However it took me till today to actually do it.

This article consists of two parts (i already wrote both, really!). This (the first part) is about GSoC and the mentor summit in general. The second part will be published on Wednesday and is about my thoughts how a organisation could improve participating the GSoC.

GSoC!? What’s it and Why?

Some of you may already know about GSoC, but some of you may have no idea why Google invited me to San Francisco. This is how the „summer“ works and why I went to SF:

Every year Google invites students to participate and contribute to Open Source projects. The basic idea: Google is giving stipends to students to work (write code) for three month on a task for an Open Source project. Google calls it the „Google Summer of Code“. Many small and some really large open source projects (Mozilla, Apache, Kernel.org, MediaWiki, Git, TYPO3, Drupal, …) apply to the programm. Actually every Open Source project can apply. Once the organizations are „accepted“ by Google, students from all over the world can apply with the organizations by handing in proposals and ideas on what they want to work on during the summer. The organization (in my case the TYPO3 Association) provides a bunch of mentors which decide and vote on the proposals. Depending on the number of student proposals and available mentors of the organisation, Google decides how many students are going to work on their suggested projects. For TYPO3 this year we got six „slots“, which means six projects/students.

Each student has at least on mentor assigned. There can be a co-mentor too. The mentor should guide the student in his project, bring him into the community and also evaluates the student’s work. Only if the student passes the mentor’s evaluation (there is a mid-term and a final evaluation), Google pays the student for his work.

This year 1115 students and 175 organizations took part. Doing a little math: 1100 Students; 5000US$ each; plus 500US$ for each mentor; plus uncounted T-Shirts; plus the Mentor Summit (which is free for all participating mentors). In sum that’s a lot of money! Just the students stipends are worth 5.500.000 US$. By what I heared it’s the largest single budget spent on supporting Open Source projects by one company.

The Mentor Summit

At the end of the summer, Google invites two mentors from each organization to meet up in Mountain View near San Francisco to exchange experiences. That’s the GSoC Mentor Summit. It takes place at the Google Campus – also known as Googleplex – for two days, organized as a „unconference“ (kind of like a BarCamp). 350 mentors were invited this year.

As I was mentoring Pascal Jungblut on his FLOW3 Browser project this year, and it happens that no other of us six mentors for TYPO3 had time to go, it was just lucky me who got the chance to go to the summit.

Beside San Francisco being a great city to visit, it was summerly in mid of October and I had far too little time to visit the city (see my photos), I had a great mentor summit.

As it was an „unconference“, the event started with a planning session. People suggested sessions and topics to discuss for the next two days. On these two days more then 60 sessions took place. Up to 15 in parallel. Unfortunately there is no way to join every session you’re intrested in.

The sessions, the discussions, the talks in between outside in the sun, during the meals, in the chocolate room or at the pool party in the evening, meeting so many different people… It was a really inspiring event! It was a little bit like the TYPO3 developer days back in 2009 in Elmshorn, just not focused on one specific topic (like TYPO3 development), but more general, more widely.

When I said „inspiring“ I mean I had the chance to reflect on how we did this summer, realizing that others had the same issues and getting ideas how to improve it in the next year.

„You’re are doing it wrong“

Actually TYPO3 did not do it wrong the way we participated in the Summer of Code. But i think we can improve here and there. But that’s the second part of the story.