Re: Google Summer of Code 2010 Debian Report
2010/9/23 Filipus Klutiero <chealer@gmail.com>:
> On 2010-09-23 05:32, Obey Arthur Liu wrote:
>> On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero<chealer@gmail.com>
>> wrote:
>>>
>>> [...]
>>> I would recommend requiring candidate mentors to agree to share
>>> evaluations
>>> with GSoC admins, so admins can at least pick information on results when
>>> a
>>> 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
project itself…
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)
>>> 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
>>> USD.
>>> 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
>>> ask
>>> for more involvement... instead of having a misleading tone of optimism
>>> in
>>
>> 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… ;) )
>>> the report. Yes, the SoC is surely a positive thing for Debian, but
>>> considering the resources granted, I almost feel ashamed to see how
>>> modest
>>> 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
>>> worryingly
>>> non-obvious.)
>>
>> 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)
>> 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.
> 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 ;) ).
> 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.
Especially because (s)he does useful work - its relatively easy to find a job
in which I have to do less for more money, but has no value. And if I e.g.
want to be treated like a second or third class member I can flip a few
burgers and harvest grapes and asparagus instead¹. I don't need to chose
debian for that if we would agree that we should handle students as consults…
The student need to be convinced to choose debian as organization and at
best (s)he should be convinced to stay with debian even after gsoc.
Google could provide debian with 20 slots, this doesn't help if
only 5 students apply… (that is what I meant with the sex-appeal above…)
If debian has 500 students applying, I am pretty sure google will be happy
to hand a few more slots to debian…
Best regards
David Kalnischkies, MultiArch in APT GSoC student 2010
¹ no offense, depends obviously on the organization, but I grew & grow up in
a winemaker family, so I know that different organizations have different
treatment styles regarding their workers - and for all gsoc organizations
I hope that they didn't use some of these as their blueprint…
Reply to: