Kategorie-Archiv: gsoc

It’s spring!

Join the Google Summer Of Code 2012

The Google Summer of Code 2012 is coming up.

The last two years I participate the GSoC as a mentor and last year I had the great opportunity to join the mentor summit in SF. I really got into the idea of GSoC. You might have read my article about what can be improved this year. Maybe thats why I have been asked recently to join the this years TYPO3-GSoC-Admin-Team to organize TYPO3’s Summer of Code.

One of the main issues of the last year was the lack of inner and outer communication. Ingo and I already started to discuss how to improve that. However, beside of the regular „official reports“ on news.typo3.org, I’m going to blog about my personal point of view during the summer. At least I’m trying to do so.

We need you!

On last monday the organization application phase did start. The deadline is the next friday the 9.3. Which means we have like one week from now.

Now it’s our turn to apply and to do so and to get the best out of this summer, we urgently need your help!

For the moment we need a) possible Mentors and b) ideas for projects.

Could you imagine beeing a mentor?

The mentor is like the project manager for a student and his project. You going to decide, together with the other mentors, which students proposals will be accepted and you will guide one of these projects over the summer. You should already be involved in the TYPO3-Community and really feel the spirit of TYPO3. You are not going to actualy ‚work‘ or even code on your students project. That’s really the students part. The mentors task is more about involving the student into our community, getting and keeping the student on track and beeing available for your students questions. Expect like 3-5 hours of work per week. You will need to do hand in a midterm and a final evaluation to google, which actualy is a short questionaire. You going to do regular status meetings with your student (e.g. by skype), reviewing the students work, joining our regular mentor meetings in BigBlueButton e.g. to report about the project status. Never done something like this before? No problem: You won’t be alone. We will have some experienced mentors from the last years again, which gladly will help to solve all questions. This is one of the reasons why we will do regular mentor meetings this year. What you will get? First of all a great summer with a cool project and a cool student. Also there is a small(!) compensation. Two of our mentors will join the mentor summit in San Francisco at the Google HQ. But most important: you will do something good for the student, for the OpenSource spirit and for TYPO3! And hey: There will be T-Shirts for everyone!

As I was a mentor for two years now, I can tell you it’s a really nice and fun job and worthful experience.

Any questions about beeing a mentor? Like to be one? Get in touch with me!

Ideas for possible projects

When the students apply in the next phase of GSoC, they will hand in project proposals. As most of the students are not that deep into TYPO3 and about our current projects, we need to provide some possible ideas. In the last years we had an ‚ideas‘ page (actualy Google requires us to have one), which we need to update for this years application.

We need any project idea related to the TYPO3 core, FLOW3 or ‚Phoenix‘. Any rough idea will do! No need for fully concepted/drafted projects, just ideas. I’m going to collect all of these ideas and discuss them with the mentors. These ideas, which we think are doable by a student during the summer, will be presented on the ideas page.

For example: completely rewriting the v4 list module might not be doable for someone never have seen TYPO3 before. A FLOW3 package to browse model data is.

If you are a core team member, core project team member (/leader), a experienced TYPO3 developer or just someone actualy heavily using TYPO3 or FLOW3 and have an idea? Drop me a line!

Make it our „summer of code“

I’m really looking forward to this summer.

Do not hesitate to contact me if you like to participate or if you have any questions or ideas:

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.