[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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: