Re: Google Summer of Code 2010 Debian Report
On 2010-09-23 21:26, David Kalnischkies wrote:
Really, if writing a paragraph on what you did during 12 weeks is
significant extra work for you, I wonder why you bothered writing this
2010/9/23 Filipus Klutiero<email@example.com>:
On 2010-09-23 05:32, Obey Arthur Liu wrote:
On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero<firstname.lastname@example.org>
I would recommend requiring candidate mentors to agree to share
with GSoC admins, so admins can at least pick information on results when
report has to be made.
Mentors are usually restricted by their spare time. Remember that
contrary to students, they usually have an actual job.
Which is why I'm suggesting that admins get allowed to use their reports, so
if any individual mentor is too busy to give a report on the results and the
students also fails to do it, the admins will be able to do it easily.
Maybe, in this case you should also motivate the students to do the extra
work you expect from them. They all were required to fill in two rather
longish evaluations in the gsoc process - repeating the same again is,
lets say, boring. Given that we (as in students) prepared all a few debconf
slides relatively near the end of gsoc most of it is already said - even
by the respective student in person… (video is available).
And these slides should be better than the evaluations as these are rather
gsoc organizational orientated questions and not so much about the
I don't think you really understand our concerns. Nobody talked about
writing "a whole lot". We're disappointed that most project do not have
*a single word* published on the results. There is room for a middle
ground between a word and a whole lot.
And more personal - as I don't know about the others and non-attending
debconf doesn't help a lot - I revised very few (as in no) "gimme more info"
requests, so writing a whole lot into the blue which is maybe never read
(or given that nobody requested it - very likely never read) isn't very
motivating - or at least I can find a bunch of more motivating tasks
including university stuff, helping my uncle making (and drinking) wine
or such boring things as fixing bugs or even writing emails…
(and yes, I have writing something on my todo list, just not high-priority)
Besides, I'm not talking about getting students to write this, but
making sure there's an easy backup solution if they don't.
At its current scale, the summer of code is approximately equivalent to a
potential indirect subsidy of 50 000 USD and a direct subsidy of 5000
5000 may not be a lot, but if we don't have enough volunteers to complete
missing administrative manpower, then we should be honest about it and
for more involvement... instead of having a misleading tone of optimism
Breaking news: people are welcome to help out for managing the Summer
of Code at Debian. There's plenty of work to do, even outside of the
summer period. (This is serious.)
I'm not sure I get exactly your intended message, but if this is serious,
this is the kind of information that would be actually relevant on d-d-a
next time the SoC team sends a mail there.
Come on, can you name even one team in debian (or any open source project)
which has too many active members? Being understaffed is the norm,
not something you need to mention explicitly in every mail you write…
(okay, this paragraph is a bit too depressive, but I am out of time to
reword it - at bit ironic in this context… ;) )
Read carefully - I was not sure I got Obey's message correctly. He wrote
"Breaking news: [...] (This is serious.)"
If he means that [...] is seriously breaking news, I think my answer is
If however "Breaking news" is sarcastic, and he means, as you say, that
all teams welcome help, implying that asking for more involvement would
be vain, then my answer is different:
Debian teams could be put on a spectrum of vitality. At one end, you
have the security team, which just needs to keep a minimal manpower. At
the other end, you have the vimim team, working on the next-generation
beat-them-all text editor. The vimim team could be vacant for a decade
without anyone noticing, however if an accident reduces the security
team to a single person, that person needs to scream immediately and
start recruiting new people before the funerals are over. Close to the
critical end, you have the archive maintenance team, of which the
breakage, although it would not cause an immediate threat to Debian,
would severely affect development, making most other teams unproductive.
I consider the GSoC admins on the side of the security team, not as
critical as the archive maintenance team, but still a team whose
performance is critical to the productivity of our GSoC project teams.
Yes, students do more work than these 12 weeks, but strictly speaking,
and to avoid going into details, they get paid 5000 USD for 12 weeks of
work. My point is that in most countries relevant for the GSoC, it's a
charitable decision for a student to offer themselves for the GSoC and
renounce the much higher wages they could have obtained if they had
chosen to get a job instead. Of course, consultants could make even more
than students. There is no way one could think the SoC targets
consultants being aware of the stipend.
the report. Yes, the SoC is surely a positive thing for Debian, but
considering the resources granted, I almost feel ashamed to see how
the results have been so far. (Note that I have not extensively monitored
the SoC. The results may be greater than I imagine, but this is
I think the issue is that you're confusing Summer of Code participants
with paid consultants. They are not. They are just students, most
often newbies at free software, whose summer happen to have been
cleared out of another summer job by the GSoC stipend.
Heh, it would be hard to confuse SoC students with consultants when they're
being paid 5000 USD for 12 weeks of works...
You forget that the students have done a lot unpaid - choosing an
organization is nothing to be taken lightly. Further more you search
a proposal you find interesting - or even write your own, and that
for most students multiple times as the chance to be chosen is
higher then. Oh, and after choosing your proposal(s) you need to provide
your hopefully-soon-to-be organizations with a bunch of information
why you are the best student in the world. Searching and convincing
a mentor for your proposal especially if its your own can suck up
much time, too. But let us assume you have one and you are one of
the chosen ones (unlikely if you look at the numbers of students accepted
vs students applied in gsoc). Now begins something which Google calls
"Bonding time" - time in which you should dig (deeper) into your project,
get familiar with the source, read documentation meet your mentor and
your community and all this kind of stuff…
Reducing the gsoc to "3 months of writing code" you didn't give credit
to that pre-gsoc invest of the students as well as you dismiss the hidden
target: Encourage a student to use and work on the projects even after gsoc.
(which is for me the real and only target: but don't tell anyone)
Well, if it's the fault of the project in general, you can't really say
it's not the fault of the admins. It's true that you need students to
propose reasonable projects for admins to pick them, but I know this is
not the only problem. If it was, the admins should communicate that.
There has even been advice for students to submit proposals, and this
problem wasn't mentioned. Remember that students using other proposals
are not the favorite anyway, we're looking for students as motivated as
As such, you
should have similar survival rate expectations for a Debian GSoC
project as for any other Debian project that you or any DD would
happen to be working on. Perhaps a bit higher, but not much.
This hits an extremely interesting point. The reference to a "survival rate"
betrays what I think is a major error GSoC administration has made. It seems
the projects selected are in large part new projects, rather than
improvements to existing software.
As said, students can provide proposals, the organization can do and
even a random stranger can come along and propose something:
You only need someone taking it to see it implemented - it doesn't
even need to be a gsoc student. If it is interesting enough everyone
could take it - but most of the proposals are not interesting. Not that
they wouldn't be cool to have, but they are not presented in a "sexy" way.
And that is really not the fault of the admins, thats the fault of the
project in general or maybe the proposer(s) in specific to be unable to
present themself and their proposals in an interesting way.
Sorry, I don't understand what you're writing (in particular, what you
mean by "you aren't a consult").
away from the resources they need, with as only somewhat reliable guide
their mentor, which may not even get 500 USD for the whole mentoring
While your mentor is your first contact, you aren't a consult and you
shouldn't be handled as such - and you do that if you assume that
nobody else in the project needs to care for the student. His primary
job is more to get you in touch with others as you don't know the
organization you are working in very well (yet) and therefore you don't
know always the right contact point for your specific needs.
And you don't know all rules right on the first day - simple ones like
the code of conduct for debian mailinglists and more complicated ones
like debian/rules (sorry, small joke - its easy, too, with debhelper ;) ).
I was not saying that Google is the most important part of SoC, I was
talking about the reasons to publically publish a reasonable description
of how the SoC went.
And most importantly, there's Google. Google may do no evil, but they do
good to their bottom line. The SoC brings them publicity, which allows
securing SoC funds for next year. With the current scale of SoC, it's a
mininum that Debian gets 10 slots. An organization of Debian's importance
could get a lot more. Some organizations have over twice as many slots.
Increasing Debian's appeal to Google involves:
Google is really not the most important part of gsoc. They pay the bills, yes,
but the important part is the student as (s)he does the real work.