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(a)yahoo.com> wrote:

(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(a)yahoo.com> wrote:

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(a)gmx.de> wrote:

Sj- 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

Chad Perrin wrote: 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

Brion Vibber wrote: 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