Re: Google Summer of Code 2010 Debian Report
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.
I do not think that we need a constraining agreement with mentors on
that point. They would usually happily do it.
...then why did most of them fail to do it here :-?
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.
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...
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.
When projects are selected, admins need to keep in mind that those
working on them are not professional and experienced developers, but
students (who may not even study computer science). Furthermore, these
students will have only 12 summer weeks, during which they'll work from
home, most certainly 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 process. For these projects to survive, or even have
a chance to be born, their scope needs to be very limited.
When giving a quick look at this year's projects, this problem seems to
be a lot lesser than it has been in the past. However, this problem is
in fact part of a wider one, the tendency to pick big projects. Of
course, big projects are more attractive at first sight, but we're not
that stupid. Even with a considerate selection, big projects are more
interesting, because they should get more work done than a project which
would possibly be completed before then end of summer.
But we must not forget a big advantage of smaller projects. Not only are
their results more likely to be useful, but the fact that the students
will have completed them is a good thing per se, because the SoC is also
about recruiting future Debian contributors. As you must know, big
project students always say they're going to complete the work after the
end of the summer, but they're going back to school and obviously give
up at some point, which leaves them with a feeling of guilt that will
not help their perception of being further involved in Debian.
And in fact, this big project / small project division is in good part a
false dichotomy. In reality, even if the project would be finished
half-term, there is always room for improvement, and often surrounding
things that can be done to make use of the project's results.
I'm stopping here, but mentioning that despite this, there *could* be
ways to tackle big projects, like going in phases (something similar was
tried already).
Regarding projects management, well, if you expect a level of
accountability on par with what you'd have in a business, then you
need to have the appropriate management manpower, and perhaps more
importantly, a particular professional mindset from mentors and
students. These are not the usual way Debian operates, which is what
makes it difficult.
I am not at all expecting accountability on par with business. Google
probably gets that in the mentor reports. Towards the Debian project,
the accountability cannot be the same (I suppose, unfortunately, since
the mentor reports are not public), but there should a minimum. Having a
paragraph to report on the impact of a 5000 USD grant is not asking a lot.
Besides, this is not just for accountability. If there are problems with
the projects, describing the results could allow potential admins to
notice their involvement could be useful. Other mentoring organizations
may want to see what challenges Debian has to face.
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:
1. Having successful projects.
2. Advertising the success. For that, sending mails to d-d-a will help,
but not with any content. Having a Wiki GSoC page that doesn't look like
the summer hasn't started yet will not hurt neither.
Finally, you mention a professional mindset is needed, and Debian
doesn't usually operate that way. I'm not sure what you mean by
"professional", but if you mean money, it's not like there is no money
here. As I wrote, 5000 USD for the mentors *and* admins is surely not a
lot, but if we have management problems, I'm sure optimizing the results
of a ~ 50 000 USD/year grant could have the required priority to get a
bit of extra money from SPI.
I plan to run a BoF with fellow admins and mentors from other
organizations at the Mentors Summit to deal with these management and
reporting aspects. I'll make sure to tell you how it goes.
That sounds great, thank you.
Reply to: