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.
