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 <[EMAIL PROTECTED]>
> 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@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
