Hoi,
Last year Nikerabbit was enrolled in a Finnish Summer of Code project. He
did a ton of great work for Betawiki as part of this project. The Liquid
Threads project was a GSOC project. It is used by the WikiEducator project
and as such I would rate it successful.
When you look at our own bigger projects, SUL took a crazy amount of time to
materialise, we are still not able to produce predictable data dumps. When
you look at commercial projects, at least 50% of such projects fail to meet
expectations. The notion that classical "in the office" projects do better
is not one I share.
When we are to do a proper job for summer of code projects, obviously all
our existing developers are most likely to do the better job. Nikerabbit's
project is a case in point. If there are observations why such a project
does not work out as well as we hope, we should address those issues. The
most important thing achieved with a summer of code project is not only the
software but also the experience given to what we hope will be a developer
who stays with our project after his project.
Thanks,
GerardM
2008/12/11 Tim Starling <tstarling(a)wikimedia.org>
THURNER rupert wrote:
hi,
on
http://www.mediawiki.org/wiki/Summer_of_Code_2008 there was a
statement that such efforts are restricted by "mentoring-manpower".
now that there are real people and a budget dedicated to improve
usability, could it make sense to leverage that effort by bounties
given in a way comparable to google sumer of code?
imo this might also used to attract additional donations from
individuals, as it is simple paraphrasable. and usability is a real
pain to a lot of people.
GSoC has never produced anything useful for us, so I don't know why you
think it would be a good model. Our record with contract development has
also been pretty poor.
Our most active volunteers are adept at collaborating online in public
forums. That's because they're self-selected for that trait and they're
adequately motivated that they can perform useful projects without
supervision. Remote workers brought in via GSoC and contracts seem to have
difficulty integrating with this culture, and either perform their work in
isolation or collaborate only with their designated mentor.
The idea of a collection of remote workers paid by the line of code might
sound nice to an online community member, but I'm beginning to think that
it's risky at best. A software development team working in an office
together might be old-school, but at least the management practices are
established, with good results commonly produced.
-- Tim Starling
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l