In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Amgine
Amgine wrote:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Can I ask where the discussion is being done?
Walter (Waerth)
Hoi, I think the worst we can do is fork. It will mean that we will not benefit from the economies of scale that the Wikimedia Foundation offers. These benefits are huge, with a project that is part of the larger community, you will be known and otherwise you have to struggle to get the same "facetime". You will be just another project struggling to get recognition. You will have to find programmers, you will have to find hardware, you will have to do all the hard work that is already done really well.
Take me as an example, I did not give up on Wiktionary, I worked hard to get an idea of what we should have (by putting in a lot of work) I got some community going and learned that we need one database to rule them all .. :) I discussed this and learned about Wikidata. This is the necessary building block for the "ultimate wiktionary". I found someone to program it, I found someone to pay the programmer and, the development has started. Wikispecies will benefit from this if we get enough traction (read also but not only money) to make this happen. I have uploaded some 3000 soundfiles and now the upload screen is uploaded to such an extend that I can upload a Dutch pronunciation in a fraction of the time.
My point to you is: Do not give up, get your community to grow and find out what you really need. And work at it. My point to the list in general is, there are many things that need doing We need resources to make the things happen to grow the projects and communities other than Wikipedia. When we agree to have all these projects and communities, we have to invest in their well being. It is a defeat of who we are when we get a fork because of unresponsiveness. It is certainly a pity when we CAN hire programmers to create the desperately needed functionality.
An example: It is easier to upload Dutch, English, German soundfiles than Farsi soundfiles I can do easily 10 times more words in the same time. It upsets me that a soundfile obscures text in Hebrew, Arabic or Farsi because of this stupid symbol that is seen because Commons is seen as an external resource.
I want to have dia shows when we have too many pictures for a subject. I have ideas about "language immersion training" it needs some software to allow for different target languages. Those are only my ideas.... there are so many even better idea's....
We can get money for functionality, we can get money for servers. We just have to ask. That is why the Foundation can be such a powerfull organisation. It can be an enabler. That is in my opinion what we have done brilliantly, given the outrageous success that Wikipedia is. We just have to work hard on making the other projects a success too.
Define projects, define functionality, get a community interested in change find money, find programmers. And let's make things even better..
One thing you cannot do is expect others to do the work for you. If you cannot do the programming, find someone who can and who will. If you do not have the money find someone who does. If you cannot define your needs, find someone who can because without a well defined need you are snookered and, on your own it will be only worse,
Thanks, GerardM
On Mon, 28 Mar 2005 06:35:24 -0800, Amgine amgine@saewyc.net wrote:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Amgine _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
I'd like to say that indeed, I find GerardM proactive approach very positive. Ie "Do not give up, get your community to grow and
find out what you really need. And work at it."
Ant
GerardM a écrit:
Hoi, I think the worst we can do is fork. It will mean that we will not benefit from the economies of scale that the Wikimedia Foundation offers. These benefits are huge, with a project that is part of the larger community, you will be known and otherwise you have to struggle to get the same "facetime". You will be just another project struggling to get recognition. You will have to find programmers, you will have to find hardware, you will have to do all the hard work that is already done really well.
Take me as an example, I did not give up on Wiktionary, I worked hard to get an idea of what we should have (by putting in a lot of work) I got some community going and learned that we need one database to rule them all .. :) I discussed this and learned about Wikidata. This is the necessary building block for the "ultimate wiktionary". I found someone to program it, I found someone to pay the programmer and, the development has started. Wikispecies will benefit from this if we get enough traction (read also but not only money) to make this happen. I have uploaded some 3000 soundfiles and now the upload screen is uploaded to such an extend that I can upload a Dutch pronunciation in a fraction of the time.
My point to you is: Do not give up, get your community to grow and find out what you really need. And work at it. My point to the list in general is, there are many things that need doing We need resources to make the things happen to grow the projects and communities other than Wikipedia. When we agree to have all these projects and communities, we have to invest in their well being. It is a defeat of who we are when we get a fork because of unresponsiveness. It is certainly a pity when we CAN hire programmers to create the desperately needed functionality.
An example: It is easier to upload Dutch, English, German soundfiles than Farsi soundfiles I can do easily 10 times more words in the same time. It upsets me that a soundfile obscures text in Hebrew, Arabic or Farsi because of this stupid symbol that is seen because Commons is seen as an external resource.
I want to have dia shows when we have too many pictures for a subject. I have ideas about "language immersion training" it needs some software to allow for different target languages. Those are only my ideas.... there are so many even better idea's....
We can get money for functionality, we can get money for servers. We just have to ask. That is why the Foundation can be such a powerfull organisation. It can be an enabler. That is in my opinion what we have done brilliantly, given the outrageous success that Wikipedia is. We just have to work hard on making the other projects a success too.
Define projects, define functionality, get a community interested in change find money, find programmers. And let's make things even better..
One thing you cannot do is expect others to do the work for you. If you cannot do the programming, find someone who can and who will. If you do not have the money find someone who does. If you cannot define your needs, find someone who can because without a well defined need you are snookered and, on your own it will be only worse,
Thanks, GerardM
On Mon, 28 Mar 2005 06:35:24 -0800, Amgine amgine@saewyc.net wrote:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Amgine _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
For what it's worth, (and partially as an aside) I think everyone who thinks that structured data, or complex applications and the wiki paradigm don't mix should go to www.jot.com and request a beta. Those folks managed to build a pretty awesome looking wiki platform that supports applications developed in a certain wiki-script, and structured data storage.
-ilya
On Tue, 29 Mar 2005 07:16:15 +0200, Anthere anthere9@yahoo.com wrote:
I'd like to say that indeed, I find GerardM proactive approach very positive. Ie "Do not give up, get your community to grow and
find out what you really need. And work at it."
Ant
GerardM a écrit:
Hoi, I think the worst we can do is fork. It will mean that we will not benefit from the economies of scale that the Wikimedia Foundation offers. These benefits are huge, with a project that is part of the larger community, you will be known and otherwise you have to struggle to get the same "facetime". You will be just another project struggling to get recognition. You will have to find programmers, you will have to find hardware, you will have to do all the hard work that is already done really well.
Take me as an example, I did not give up on Wiktionary, I worked hard to get an idea of what we should have (by putting in a lot of work) I got some community going and learned that we need one database to rule them all .. :) I discussed this and learned about Wikidata. This is the necessary building block for the "ultimate wiktionary". I found someone to program it, I found someone to pay the programmer and, the development has started. Wikispecies will benefit from this if we get enough traction (read also but not only money) to make this happen. I have uploaded some 3000 soundfiles and now the upload screen is uploaded to such an extend that I can upload a Dutch pronunciation in a fraction of the time.
My point to you is: Do not give up, get your community to grow and find out what you really need. And work at it. My point to the list in general is, there are many things that need doing We need resources to make the things happen to grow the projects and communities other than Wikipedia. When we agree to have all these projects and communities, we have to invest in their well being. It is a defeat of who we are when we get a fork because of unresponsiveness. It is certainly a pity when we CAN hire programmers to create the desperately needed functionality.
An example: It is easier to upload Dutch, English, German soundfiles than Farsi soundfiles I can do easily 10 times more words in the same time. It upsets me that a soundfile obscures text in Hebrew, Arabic or Farsi because of this stupid symbol that is seen because Commons is seen as an external resource.
I want to have dia shows when we have too many pictures for a subject. I have ideas about "language immersion training" it needs some software to allow for different target languages. Those are only my ideas.... there are so many even better idea's....
We can get money for functionality, we can get money for servers. We just have to ask. That is why the Foundation can be such a powerfull organisation. It can be an enabler. That is in my opinion what we have done brilliantly, given the outrageous success that Wikipedia is. We just have to work hard on making the other projects a success too.
Define projects, define functionality, get a community interested in change find money, find programmers. And let's make things even better..
One thing you cannot do is expect others to do the work for you. If you cannot do the programming, find someone who can and who will. If you do not have the money find someone who does. If you cannot define your needs, find someone who can because without a well defined need you are snookered and, on your own it will be only worse,
Thanks, GerardM
On Mon, 28 Mar 2005 06:35:24 -0800, Amgine amgine@saewyc.net wrote:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Amgine _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
Amgine a écrit:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Amgine
I do not think finding hardware to host a project this size would be very problematic in the short run, but who would take care of it ? And mostly, if you think the current team is unresponsive to current wikinews software needs, who do you think will take care of modifying the MediaWiki software outside of the current team ? Is it perceived it would be more efficient to have a software fork or even to use another software ?
Incidently, though I often heard of some software features for the wiktionary and species project, which features are necessary to wikinews and where has this been discussed ?
Ant
(English) Wikinews suffers from three main problems that are related to the software we use.
1) MediaWiki is not a good CMS, in the traditional sense -- it does not easily support workflows, and depends on humans to adhere to a well-defined process. 2) MediaWiki does not support RSS feeds. Today's news junkies depend on RSS to read their news: our ability offer them these feeds is near zero. 3) MediaWiki does not support dynamic listing. If I tag a news story as Category:Canada and Category:Elections, there is no way currently for the system to automatically publish this list to a dated list of stories about Canada, or Elections, or Elections in Canada. In other words, MediaWiki doesn't allow for server-side views on data that are unions of categories.
The combination of these three factors to varying degrees has a profound effect on our ability to scale.
-Not having a CMS, we have to teach every user how to follow our process -- losing quite a bit of time on the effort. - Not having configurable, high-quality RSS feeds means that bloggers and news pundits won't readily access our content. - Not having dynamic lists means that for every story that we write, we have to edit at _least_ five other pages -- or as many as 20. This leads us to lose a significant amount of time and effort, or delivers inconsistent results if not everyone follows the process, or delivers an incomplete news site if we follow a simpler process.
Wikinews and our current active contributors have shown that we can put together about 20 stories a day on a somewhat sustained basis. I think that we are very near our limit, however, and that further growth is unsustainable, due to the limitations of the software. Unlike Wikipedia where you can edit a story and have someone link to it tomorrow, or three weeks from now, on Wikinews all the links have to be in place at the right time -- or face irrelevance.
There are other need-to-have features, of course -- but these are the ones that will likely determine the survival and growth of the project in the long-term, and ones that are serious enough changes from the current state of MediaWiki to warrant this discussion.
We have made strides in resolving this. Bugzilla bug# 1411 has had an extension implemented that will partially solve our Dynamic List problem, but was shot down by developers as unacceptable (though I suspect it's quite acceptable to a smaller site like Wikinews, even if unacceptable to a large site like en.wikipedia). We have tried putting together external RSS feeds, but with only limited success.
I am ready to make a more detailed proposal regarding the specific work that needs to get done, but I am glad that Gerard started the discussion in the meanwhile. Wikinews (and probably other projects) needs certain software changes to grow. In the current environment, there is a catch-22 -- we have to grow big enough to be important to developers to have big changes made to the software, but we need these changes made to grow. Not all of these changes are even useful in Wikipedia. Not all of these changes _should_ or _could_ even be used in Wikipedia.
Amgine brought up hardware or software forking. The discussions (held mainly informally, on IRC) focused on perhaps donating hardware to the Foundation to run Wikinews on separate servers at the current datacenter: allowing us to experiment in ways that the current development and release process might not be happy with. The software discussion, likewise, faced the fact that we either have to have someone on our team become a core developer, or we have to find alternate software on which to run Wikinews -- or get enough support from the Foundation to make the changes we need.
Sorry to be so verbose, but I want to chime in to explain our state of things more fully.
-ilya (n:User:IlyaHaykinson)
On Mon, 28 Mar 2005 17:55:37 +0200, Anthere anthere9@yahoo.com wrote:
Amgine a écrit:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Amgine
I do not think finding hardware to host a project this size would be very problematic in the short run, but who would take care of it ? And mostly, if you think the current team is unresponsive to current wikinews software needs, who do you think will take care of modifying the MediaWiki software outside of the current team ? Is it perceived it would be more efficient to have a software fork or even to use another software ?
Incidently, though I often heard of some software features for the wiktionary and species project, which features are necessary to wikinews and where has this been discussed ?
Ant
foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
I am not aware of any serious discussions concerning a fork. DV suggested that video files might be best hosted on some external service, but I commented that Wikimedia has more than enough resources to do that, and that we mostly need to agree on which politically correct video codec to use. I strongly oppose both project and software forks for reasons that should be obvious.
It is true that Wikinews is reaching the limits of human scaling. This is because we're getting so large that we will soon have to stop listing all stories on the Main Page, and will have to use separate index pages instead.
When Wikinews started, I did set up such index pages for regions and topics. It already became clear during the demo phase that these are nearly impossible to maintain manually -- it's not a fun job, so it doesn't get done, especially because everyone with some small technical knowledge knows that a computer could do this.
So, what's the solution?
Since I'm the person Gerard spoke about who is going to implement structured data functionality over the next 3-4 months, my own resources are limited. However, I have offered in the past to act as a development task coordinator for the Wikimedia Foundation, and that offer still stands.
Such a task coordinator would prioritize tasks, maintain contacts to potentially interested sponsors, and make recommendations on spending a certain part of our internal budget on development tasks. He would write the basic specifications, try to locate interested developers (both by inviting them directly, and by having public calls for tenders), watch over the implementation, and decide whether it meets the specs (together with the Board and the MediaWiki Release Manager, Brion Vibber).
His Holiness JW III is not infinitely scalable. I believe I am well- qualified for the role in question, and it is something I would love to do. The WMF has hired Brion on a part-time basis. But that's not going to cut it. Brion has got his hands full making sure that all the crazy inventions by people like me actually work, fixing existing bugs, working on sponsor-specific tasks like OAI support for GuruNet, churning out releases, watching over scalability, and addressing high priority general project issues like single login.
I strongly believe that a combined model of full-time employment for people like Brion, and task-based contracts for project-specific needs, is the only way forward.
As for the specific needs Wikinews has, Ilya has already written a bit about that. I have a fairly good idea in my head how news feeds could work within MediaWiki in a scalable fashion. The question is, are we willing to spend the money to get this done?
And Wikinews is not the only project which needs changes. Wikipedia, Wikisource, Wiktionary, Wikibooks, Wikispecies, Wikiquote, and very importantly, Wikicommons, would all benefit greatly from certain added functionality. Whenever I go to a meetup, I hear from a dozen people about all the new features which we need to make their projects, or projects within a project, work. Often these ideas are really bad. That's why there needs to be a gatekeeper process by which good ones are selected for implementation.
Just because Wikipedia sort of works (even though we still don't have peer review functionality after more than 4 years), we shouldn't start slacking. We have half a dozen active developers at any given time. We have hundreds of thousands of users and even more readers. We've tried recruiting. Jimbo has given his speech at FOSDEM. There's more we can do, but in part due to the growing complexity of MediaWiki, this imbalance can ultimately only be addressed with one resource: money.
Regards,
Erik
In doing maintenance and development there is this 80/20% rule. There are things that make a huge difference to people doing the work in the projects that do not cost much in developer resources. The one thing that is really important that some triage is done on the bugs editted in Bugzilla to find these little gems. Development is not only about the big developments but also about the little ones.
One issue that then arises is do you want a fix or do you want the all singing all dancing gizmo. I was really happy when commons arrived, it is still not 100% as we want it to be but it makes a world of difference in the practice of our projects. The latest update on the upload page was brilliant, it just needs this increase in length for the filename field and it would make my life easier.
There are other features like this. The thing is we do not always the perfect code straight away because we have to learn what perfection should look like and, we want some features badly.
So lets make things better but spend money on the strategic stuff, particularly when developers feel an itch things things will be fixed and when things are not fixed because it is NOT wikipedia let us have it fixed and spend money to get us the 80% of what we desperately need..
Thanks, GerardM
On 28 Mar 2005 22:27:00 +0100, Erik Moeller erik_moeller@gmx.de wrote:
I am not aware of any serious discussions concerning a fork. DV suggested that video files might be best hosted on some external service, but I commented that Wikimedia has more than enough resources to do that, and that we mostly need to agree on which politically correct video codec to use. I strongly oppose both project and software forks for reasons that should be obvious.
It is true that Wikinews is reaching the limits of human scaling. This is because we're getting so large that we will soon have to stop listing all stories on the Main Page, and will have to use separate index pages instead.
When Wikinews started, I did set up such index pages for regions and topics. It already became clear during the demo phase that these are nearly impossible to maintain manually -- it's not a fun job, so it doesn't get done, especially because everyone with some small technical knowledge knows that a computer could do this.
So, what's the solution?
Since I'm the person Gerard spoke about who is going to implement structured data functionality over the next 3-4 months, my own resources are limited. However, I have offered in the past to act as a development task coordinator for the Wikimedia Foundation, and that offer still stands.
Such a task coordinator would prioritize tasks, maintain contacts to potentially interested sponsors, and make recommendations on spending a certain part of our internal budget on development tasks. He would write the basic specifications, try to locate interested developers (both by inviting them directly, and by having public calls for tenders), watch over the implementation, and decide whether it meets the specs (together with the Board and the MediaWiki Release Manager, Brion Vibber).
His Holiness JW III is not infinitely scalable. I believe I am well- qualified for the role in question, and it is something I would love to do. The WMF has hired Brion on a part-time basis. But that's not going to cut it. Brion has got his hands full making sure that all the crazy inventions by people like me actually work, fixing existing bugs, working on sponsor-specific tasks like OAI support for GuruNet, churning out releases, watching over scalability, and addressing high priority general project issues like single login.
I strongly believe that a combined model of full-time employment for people like Brion, and task-based contracts for project-specific needs, is the only way forward.
As for the specific needs Wikinews has, Ilya has already written a bit about that. I have a fairly good idea in my head how news feeds could work within MediaWiki in a scalable fashion. The question is, are we willing to spend the money to get this done?
And Wikinews is not the only project which needs changes. Wikipedia, Wikisource, Wiktionary, Wikibooks, Wikispecies, Wikiquote, and very importantly, Wikicommons, would all benefit greatly from certain added functionality. Whenever I go to a meetup, I hear from a dozen people about all the new features which we need to make their projects, or projects within a project, work. Often these ideas are really bad. That's why there needs to be a gatekeeper process by which good ones are selected for implementation.
Just because Wikipedia sort of works (even though we still don't have peer review functionality after more than 4 years), we shouldn't start slacking. We have half a dozen active developers at any given time. We have hundreds of thousands of users and even more readers. We've tried recruiting. Jimbo has given his speech at FOSDEM. There's more we can do, but in part due to the growing complexity of MediaWiki, this imbalance can ultimately only be addressed with one resource: money.
Regards,
Erik _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
This is a great discussion.
On 28 Mar 2005 22:27:00 +0100, Erik Moeller erik_moeller@gmx.de wrote:
Since I'm the person Gerard spoke about who is going to implement structured data functionality over the next 3-4 months, my own resources are limited. However, I have offered in the past to act as a development task coordinator for the Wikimedia Foundation, and that offer still stands.
I would love to see your ideal priority-list and calendar for software development over the next year. (The same goes for the other active developers)
Such a task coordinator would prioritize tasks, maintain contacts to potentially interested sponsors, and make recommendations on spending a certain part of our internal budget on development tasks. He would write the basic specifications, try to locate interested developers (both by inviting them directly, and by having public calls for tenders), watch over the implementation, and decide whether it meets the specs (together with the Board and the MediaWiki Release Manager, Brion Vibber).
I have to repeat what I always say to suggestions like this : rewarding a single person with a title and/or salary may entice that person to do great work; it also creates a new bottleneck, and a single person only scales so far. In my experience, creating such a titled person does not magically create a community of volunteers eager to help with the goal in question, though I am not discounting the possibility that this might happen.
We should address building this community spirit and focus, whether or not one or two elevated roles are created to facilitate the process. (My personal feeling is that we would do best to let our communities of volunteers choose those who will have special power or authority; and hire / appoint people to be stewards fulfilling community desires, with obligations to be reliable and available, but no special authority)
I strongly believe that a combined model of full-time employment for people like Brion, and task-based contracts for project-specific needs, is the only way forward.
We might focus on identifying and defining tasks, and setting up an infrastructure for sharing and claiming them, before we worry about contracts.
As for the specific needs Wikinews has, Ilya has already written a bit about that. I have a fairly good idea in my head how news feeds could work within MediaWiki in a scalable fashion. The question is, are we willing to spend the money to get this done?
This in particular should not require money, considering how many people are in love with the idea of wikinews feeds.
We've tried recruiting. Jimbo has given his speech at FOSDEM. There's more we can do, but in part due to the growing complexity of MediaWiki, this imbalance can ultimately only be addressed with one resource: money.
Nonsense. Money is an excellent resource when properly applied, but there is no fundamental reason why we should have fewer volunteer developers than Linux has, for instance. After all, what are we writing but the kernel for our collective intelligence?
--SJ
PS - We could all recruit a *lot* more. The lack of paid coordinators can be a great selling point. We had a meetup yesterday in Boston. It was an last-minute "extra" meetup to discuss collaboration with local libraries, Wikimania publicity, and Mediawiki hacking, and I only promoted it a week in advance. Two of the attendees wanted to help out. One of them, a long-time programmer, had only three questions: "who are the people who decide what direction the project takes?" [Answer: everyone, even you] "but who is paid to coordinate everything?" [Answer: No-one. well, there is maybe one cool exception...] "Amazing... how can I help?" [Answer: Let me send you a few links... :) ]
Sj-
Nonsense. Money is an excellent resource when properly applied, but there is no fundamental reason why we should have fewer volunteer developers than Linux has, for instance. After all, what are we writing but the kernel for our collective intelligence?
An interesting comparison. However, it is worth noting that there is a billion dollar industry behind the Linux kernel, and many of its most active developers are directly employed by corporations like IBM, Novell and Red Hat. Hence, development tends to be driven by corporate interests.
It is no coincidence that the growth of desktop Linux, both on the kernel level and in the userspace, is depressingly slow (we're talking about a product which is almost 15 years old). It is facing many of the exact same problems that Wikimedia is facing, and the long-term solutions are likely to be identical: getting money from users to developers.
Open source, and volunteer activity in general, is not some kind of magic pixie dust which you can dispense to make everything just wonderful. This is especially true as the complexity of the project increases. We've had more offers for help on MediaWiki than we can count. Volunteers who say "I'm going to write some code" are easy to find. Those who actually do something are very rare indeed. Those whose code gets past Brion ...
Fundamentally, I also believe there is a moral obligation for each one of us, as individuals, to work on turning the free content world into a real economy, instead of trying to find ways to get ever more people to exploit themselves to an ever larger degree. We are not just dealing with "resources," we are dealing with human beings who deserve to be treated as such. I personally would encourage people to stop working on MediaWiki, or Wikimedia, if I can see that it harms their life, their children, their loved ones, their career.
That being said, here are some things we can do that will attract volunteers, short term and long term:
- provide an easier to use sandbox for people to work with the MediaWiki codebase, e.g. allow anyone to create a test-wiki from CVS HEAD, and perhaps even make the code wiki-editable. (Chroot jails, regular re- initialization, developer approval and the like help to keep the whole thing secure.)
- reach out to university CS departments. These give out projects to their students, and Wikimedia is highly loved in those circles, so it should be relatively easy to convince some of them to have their students work on MediaWiki.
- systematically improve the technical documentation and pages like "How to become a MediaWiki hacker". The parser documentation is especially bad to non-existent.
- do a better job of organizing the development-related pages. Meta is a mess. wikipedia.sourceforge.net is a static HTML page. It used to be a wiki, but SF.net was not suitable as a host. MediaWiki.org, in my opinion, should be a server outside our regular co-location facility, and be used for things like the above sandboxes, internationalization work, etc.
- use Subversion instead of CVS. It has a CVS-like syntax, so should be easy to learn for existing volunteers. It makes life a lot easier: atomic commits, very easy branching, moving files while preserving history is simple, etc. While we're at it, we could try to centralize extension development in one place.
- write and enforce a clear policy that new code needs to follow certain documentation standards before it is allowed into the HEAD branch. Undocumented code can be removed.
- long term: encourage the use of collaborative real-time editing tools like SubEthaEdit, use them in combination with Voice over IP to tutor new volunteers.
Needless to say, even the work that needs to be done to increase the efficiency of our volunteer efforts can be done faster if it is paid for, or at least organized under an official title. For the tasks for which you are qualified to do so, I highly encourage you to put ideas into action. Talk like above is cheap. Real work is worth paying for.
Regards,
Erik
On Tue, Mar 29, 2005 at 12:22:00PM +0100, Erik Moeller wrote:
Sj-
Nonsense. Money is an excellent resource when properly applied, but there is no fundamental reason why we should have fewer volunteer developers than Linux has, for instance. After all, what are we writing but the kernel for our collective intelligence?
An interesting comparison. However, it is worth noting that there is a billion dollar industry behind the Linux kernel, and many of its most active developers are directly employed by corporations like IBM, Novell and Red Hat. Hence, development tends to be driven by corporate interests.
On the other hand, there's a much lower bar for entry into working on projects like Wikipedia developing content, which is in plain English (or whatever language you're using), and even for entry into working on the MediaWiki software (PHP web application design is considerably less hairy than hacking kernel code). Your points stand, basically, except that you might be underestimating the effectiveness of pure volunteerism in many (not all, but many) aspects of the entire Wikimedia family of projects.
-- Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]
Chad Perrin wrote:
On Tue, Mar 29, 2005 at 12:22:00PM +0100, Erik Moeller wrote:
Sj-
Nonsense. Money is an excellent resource when properly applied, but there is no fundamental reason why we should have fewer volunteer developers than Linux has, for instance. After all, what are we writing but the kernel for our collective intelligence?
An interesting comparison. However, it is worth noting that there is a billion dollar industry behind the Linux kernel, and many of its most active developers are directly employed by corporations like IBM, Novell and Red Hat. Hence, development tends to be driven by corporate interests.
On the other hand, there's a much lower bar for entry into working on projects like Wikipedia developing content, which is in plain English (or whatever language you're using), and even for entry into working on the MediaWiki software (PHP web application design is considerably less hairy than hacking kernel code). Your points stand, basically, except that you might be underestimating the effectiveness of pure volunteerism in many (not all, but many) aspects of the entire Wikimedia family of projects.
-- Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]
Hoi, When you edit in English, it is easy to use Mediawiki, try however to edit something like http://fa.wikibooks.org/w/index.php?title=FarsiLes15&action=edit and you apreciate one reason why our Farsi and Arabic communities are so small. When you remove the <div class="plainlinks"> and look at the page in page preview in Firefox, you appreciate why this stupid external source indicator is another reason to for needing futher improvements. All the special codes are available in the Roman script. When you edit in Farsi, you do not have the characters available to [[media:en-insert.ogg|insert]] a soundfile ..
When this threat started, it pointed out that many languages and projects do not benefit from sorely needed developer attention. When we cannot rely on your underestimated volunteerism, I hope we are not only able but also willing to pay our way out of obstructions like this. We have plenty of room to improve the usability and accessability of knowledge that is NOT encyclopedic based and is not in a Western language. This asperation is 100% in line with what the Wikimedia Foundations stands for.
Please apreciate that I do not think the work done by all of the volunteers is not great and important. My point is that it is biased and not effective in particular ways. I disagree with your assertion that the volunteerism is effective for projects other than wikipedia. I do think that we can redress this inequality by investing in software that DOES help other scripts and other projects.
Thanks, GerardM
Amgine wrote:
In wikinews there has been an ongoing discussion regarding the unresponsiveness of the mediawiki team to issues considered critical to the project. This has now become a discussion regarding a fork of both hardware and software, and contributors are actively working toward doing so. I don't think this is the best choice, but it is beginning to look like the only choice.
Sites like Wiktionary or Wikinews are not really suitable for a wiki to begin with. I think it's unfortunate that people have so casually thrown "Wiki" on the front of the name and slapped up a new project wiki without any actual plan for making it work.
Wikipedia is *very well* suited to a wiki model because an encyclopedia is largely unstructured prose text, with cross-references between articles and some light indexing. That's exactly what a wiki is, and our wiki software is strongly geared to that.
Wiktionary requires structured data which is *completely* unlike what the wiki model provides. The project's been limping along with unstructured text for years and is going to have a hard time converting all that when the appropriate software is finally written for it (a project which is soon to get underway, I'm told, with a grant for development which Erik Moeller will be working on).
Wikinews similarly has special needs which are simply outside the scope of something like MediaWiki, with a much more limited content model, organization, categorized feeds, much stronger requirements for verification and moderation etc.
If the Wikinewsies would like to write and maintain suitable software for their project, I for one think that's *great* and applaud them for being willing to step up and put in the work instead of assuming someone else will do it for them. The wiki spirit is all about being able to do things yourself, after all!
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Sites like Wiktionary or Wikinews are not really suitable for a wiki to begin with. I think it's unfortunate that people have so casually thrown "Wiki" on the front of the name and slapped up a new project wiki without any actual plan for making it work.
Wikipedia is *very well* suited to a wiki model because an encyclopedia is largely unstructured prose text, with cross-references between articles and some light indexing. That's exactly what a wiki is, and our wiki software is strongly geared to that.
Wiktionary requires structured data which is *completely* unlike what the wiki model provides. The project's been limping along with unstructured text for years and is going to have a hard time converting all that when the appropriate software is finally written for it (a project which is soon to get underway, I'm told, with a grant for development which Erik Moeller will be working on).
This really depends on the vision that one applies to a dictionary. If the focus is on the host language of a particular Wiktionary the present software can be made to do, but I can see where it will not be adequate for Gerard's vision of a super-dictionary. The super-dictionary has a much stronger focus on translation issues, and that can tolerate somewhat less semantic debate than might be the case in a particular language. Once the super-dictionary has a working model it will probably be easier to co-ordinate between that and the various language specific projects.
Ec
Brion-
Sites like Wiktionary or Wikinews are not really suitable for a wiki to begin with.
I beg to differ. If that was the case, we wouldn't have managed to write 1000 decent articles in the last few months on the English Wikinews alone. To me, wiki is not as specific a thing as you seem to suggest. It is about utilizing the creative energy of all users to the largest extent possible.
I am on the record as opposing the implementation of my own project idea, the Wikimedia Commons, before the necessary software was written. It was launched a bit prematurely; because I didn't want to see it fail, I then wrote the basic cross-wiki image transclusion code to make it at least usable. So, I have taken your position in the past.
However, I also know that once a community exists around a certain project, the pressure is a lot higher to make the necessary software changes. For each new project, it is important to answer a simple question: Will it be possible for useful content to arise using the existing technology? If the answer is yes, then it may very well be advisable to get the project started, and let the community push for the software changes they need.
For Wiktionary and Wikispecies, a plan was lacking. It was more of a "We should do this" thing. A guy named Fonzy asked one of the developers to set up Wiktionary, and it was done. This is not the case for Wikinews. We had a plan. We knew what was missing. We could make an educated guess about how far we could go with the current software.
We also now have a good idea what we need. But as I will continue to insist, the code changes are only likely to be implemented in a timely fashion if we pay for them. Now, as for whether these changes should be part of MediaWiki proper, I strongly believe they should. The convergence of wiki and weblog technology is a process which we should lead -- just like Wikidata, this will allow MediaWiki to boldly go where no wiki has gone before. I am not open to the argument that we should not do something new and different just because it is new and different. If it doesn't work, if it doesn't scale, if it makes life harder for our existing userbase, that's another story
I think it's unfortunate that people have so casually thrown "Wiki" on the front of the name and slapped up a new project wiki without any actual plan for making it work.
Hmm, who created the German Wikiversity again? ;-) I strongly believe that every new project needs a plan and a vision, and an affirmative answer to the above question: Can we create something useful with the current codebase? In the case of Wikinews, I believe these requirements were more than met. Now the ball is in the Foundation's court again.
Regards,
Erik
wikimedia-l@lists.wikimedia.org