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

2008-12-11 Thread Tim Starling
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


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

2008-12-11 Thread Gerard Meijssen
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


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

2008-12-11 Thread 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 [EMAIL PROTECTED]

 On Thu, Dec 11, 2008 at 11:37 AM, Gerard Meijssen 
 [EMAIL PROTECTED]
  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@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


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

2008-12-11 Thread Tim Starling
Gerard Meijssen wrote:
 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.

I certainly wouldn't exclude Nikerabbit and Betawiki from the list of
projects which benefit the Foundation, but I think he probably would have
done it anyway. I said that new developers are poorly integrated, he
wasn't a new developer.

I do count David McCabe's project LiquidThreads among those that have not
been useful for Wikimedia.

-- Tim Starling


___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


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

2008-12-10 Thread Gerard Meijssen
Hoi,
When a Google Summer of Code project is about aspects of usability, then we
have on the one hand the cost of mentoring and on the other hand the benefit
of three months of work done by typically really dedicated people. We have
seen that people who started in a SoC program continued to be part of our
community after their project.

In my understanding the Stanton grant intends to improve our usability. Some
people say that we wiki people make unusual decisions, have non
traditionals approaches. I would applaud it when the Stanton grant allows us
to do more then is traditional and consequently achieve more then is
traditional.
Thanks,
  GerardM

2008/12/10 Ting Chen [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.
 
  kr, rupert.
  -
  http://wikimedia.ch/donate - exempt your donation to wikipedia from
 swiss tax!
 
  ___
  foundation-l mailing list
  foundation-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
 

 If you are inferring the Stanton grant, as far as I know not. That grant
 is very closely defined and we cannot use it for other issues.

 Ting

 ___
 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