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!
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
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 wing.philopp@gmx.de
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
Hoi, I forgot to indicate that the relative costs of mentoring a GSoC person are not high. I would even argue that it would benefit the WMF and MediaWiki when we pay this from within the regular budget.
Growing our community should in my opinion be a key goal. Thanks, GerardM
2008/12/10 Gerard Meijssen gerard.meijssen@gmail.com
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 wing.philopp@gmx.de
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
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
On Thu, Dec 11, 2008 at 11:02 AM, Tim Starling tstarling@wikimedia.org wrote:
GSoC has never produced anything useful for us, so I don't know why you think it would be a good model.
But it has produced useful results for a number of other open source software communities, so I don't think it's prudent to kick the idea out the window just yet. What's needed to make a system like GSoC work is to have a large team of prospective mentors, effort to integrate the volunteers into the community, etc. I've seen other groups who have been very successful from this program, adding a large portion of students as active committers after the program is over. If MediaWiki hasn't been as successful, it might be worthwhile figuring out what is being done differently from those projects which are more successful.
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.
I've heard the idea of code bounties discussed before, maybe that's a model that's worth reconsidering. Take your existing development staff and ancillary contributors and offer firm cash rewards for specific features. Ideally new contributors will join the effort in pursuit of these rewards. Again, something to consider.
--Andrew Whitwoth
Dear all,
If there is a summer of code, could you contact us , because we have just making this offline reader :
http://download.kiwix.org ==> it will be available for all the project of the WMF, when all the zenos files are creating.
http://www.wikiwix.com/ ==> it s our search engine available
...
...
Cordialement Martin Pascal tel : 02 32 40 23 69, fax : 02 32 61 45 26 gsm : 06 13 89 77 32 ----- Original Message ----- From: "Andrew Whitworth" wknight8111@gmail.com To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Sent: Thursday, December 11, 2008 5:24 PM Subject: Re: [Foundation-l] "wiki (usability) summer" - like google summerof code?
On Thu, Dec 11, 2008 at 11:02 AM, Tim Starling tstarling@wikimedia.org wrote:
GSoC has never produced anything useful for us, so I don't know why you think it would be a good model.
But it has produced useful results for a number of other open source software communities, so I don't think it's prudent to kick the idea out the window just yet. What's needed to make a system like GSoC work is to have a large team of prospective mentors, effort to integrate the volunteers into the community, etc. I've seen other groups who have been very successful from this program, adding a large portion of students as active committers after the program is over. If MediaWiki hasn't been as successful, it might be worthwhile figuring out what is being done differently from those projects which are more successful.
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.
I've heard the idea of code bounties discussed before, maybe that's a model that's worth reconsidering. Take your existing development staff and ancillary contributors and offer firm cash rewards for specific features. Ideally new contributors will join the effort in pursuit of these rewards. Again, something to consider.
--Andrew Whitwoth
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Thu, Dec 11, 2008 at 11:37 AM, Gerard Meijssen <gerard.meijssen@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
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@gmail.com
On Thu, Dec 11, 2008 at 11:37 AM, Gerard Meijssen < gerard.meijssen@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:
- 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
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
I see Summer of Code is kind like gambling or a long term investment...
The metavid.org project was partially inspired by my SOC participation as a student for mediaWiki in SOC 06. While metavid efforts will likely not directly benefit Wikipedia until 2009. Metavid pioneered a lot of the technologies that are making their way into the software. For example archive.org shipping oggz_chop: http://metavid.org/blog/2008/12/08/archiveorg-ogg-support/ and or the sequencer efforts currently under way with kaltura.
I mentored two students this summer, one for metavid under wikimedia's SOC. While its true as students coming fresh to the code they do need a lot of hand holding and it would have been more productive and easier to just "do it myself". I see it as more an effort for community building and a future investment in getting people to think about participating in open source. The other project mentored for xiph was mostly a failure.. but the project concept has been picked up by a community member and is now ready for integration testing with mediawiki upload system :) http://www.firefogg.org/
I think its fine to have SOC projects "fail" in getting code onto production servers while succeed in testing the waters for high risk areas and plant seeds for improving the free software ecosystem.
I think wikimedia should continue to participate and maybe avoid high risk by not committing core developers to be mentors. This should be more possible now that technical staff is expanding beyond a few stretched extremely thin people.
peace, --michael
Chad wrote:
On Thu, Dec 11, 2008 at 11:37 AM, Gerard Meijssen <gerard.meijssen@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:
- 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
wikimedia-l@lists.wikimedia.org