[Foundation-l] "wiki (usability) summer" - like google summer of code?

[Gerard Meijssen]

Hoi,
When you consider that the WMF and its projects have not benefited from
Betawiki and its functionality, then you prove again for how little
internationalisation and localisation count within MediaWiki development.
Consistently you will find Siebrand or Nikerabbit as top developers for
creating MediaWiki patches. When you exclude Betawiki from what "we" are
about.... really sad.

MediaWiki development is not only development within the Wikimedia
Foundation. There have been several projects that should have benefited the
WMF projects but did not. There was a presentation on usability at Wikimania
Boston and in Alexandria and none of the lessons learned materialised in
"our" code.

Let me be clear, I am happy that SUL finally materialised and with 430 users
active under my global account, I benefit from it a lot. However, the
functionality it provides is minimal. It does not allow me to share many of
my preferences. It works, it is great but it could be so much more. There
are always "good" reasons why thing are like they are. Given that we under
invested last year relative to the budget, I am amazed by what has been
done, however I am not satisfied with the results.

As to experience as a developer, I have some 20 years of experience as a
consultant. I have seen some great projects and some really bad ones. There
have been over time several publications that inform how many projects have
gone bad. With 50% I am being nice.
Thanks,
     GerardM

2008/12/11 Chad <innocentkiller at gmail.com>

> On Thu, Dec 11, 2008 at 11:37 AM, Gerard Meijssen <
> gerard.meijssen at gmail.com
> > wrote:
>
> > 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.
> >
>
> That's great, but neither Betawiki nor WikiEducator are the WMF, nor
> are those functionalities being used (beyond the localizations provided
> from BW) within the WMF. That's precisely what this is about, making
> use of the GSOC-style of development for MediaWiki itself.
>
> 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.
>
>
> SUL required a massive amount of work to coordinate, not to mention the
> task of coming up with a model that not only works, but is scalable to the
> WMF's needs and also actually make sense. Good data models are essential.
> Dumps are another thing that requires careful work and coordination. Poor
> execution leads to poor results. It's bad enough having someone e-mail the
> list(s) once every month or two saying "new dumps please," but imagine if
> we provided dumps that were just inherently bad.
>
> I fail to see where you get this 50% of commercial projects fail. Without a
> reliable source, I have to assume you've just made up this number and have
> never worked in software development.
>
> 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
> >
>
> Tim never said that GSOC is a bad model. Nor did he say that it produces
> bad
> results. He simply said that based on previous experiences, it hasn't
> worked
> _for us_. And it's true. Looking at last summer's projects, I don't see a
> lot of
> results:
>
> 1) HTMLDiff - ended up as a highly experimental, still somewhat buggy,
> disabled-
> by-default feature that was an i18n mess (and still might not be 100%
> fixed)
> 2) Category Redirects - what ever happened to this? Was this ever merged
> from
> branch to core? The branch hasn't been touched since August, at the least.
>
> A model failing in one use case doesn't indicate a failed model overall; it
> simply
> means it doesn't work in this situation. :)
>
> -Chad
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>