Wikipedia-l

wikipedia-l@lists.wikimedia.org

8289 discussions

Bibliography:namespace
by Daniel Mayer 21 Aug '01

21 Aug '01

On Wednesday 21 August 2002 04:41 pm, Enchanter wrote: > I don't think [using history and the top of talk pages] is enough. > If others were using wikipedia articles, we > would want a prominent clickable link back to our article, not something > buried in the edit history or the talk page. Simple fairness and courtesy > would require that we do the same and link prominently to others, as we do > with FOLDOC. Most sites simply have a link to their copyrights page and/or to a bibliography, that's all we should have (see below). Do we really want to have all the source info contained at http://www.wikipedia.org/wiki/Talk:Magnesium in the main part of the article? As more and more info is added the article will begin to look more and more messy. Having this type of info in the article will also only encourage newbies to sign articles they create. This stuff needs to go somplace else that is obvious and doesn't clutter the article. On Wednesday 21 August 2002 04:41 pm, --April wrote: > Would it be possible to add a Credits: namespace that, like the Talk: > namespace would track a given article? That way we could put credits, > links-back, links to any invariant texts, et cetera ad nauseum. We could > even put in hardcopy references, which would be useful and keep 'em from > cluttering a document. Best of all, it's unobtrusive but easily > accessible. Yes, I think this would be a great idea. Having attiribs at the top of a page called talk is non-obvious while having them in a credits:, sources: or better yet bibliography: namespace would be very initiative. This should be linked from the article's page in the same way as talk is and should have special features available only to sources (or whatever) namespaces. Some features might be; some text explanation in the non-editable part of each page briefly explaining what that page is, how it augments the standard history for large external adds and how to use it with a link to a longer explanation and to wikipedia:copyrights. Another thing worth considering is somehow using Lee's jump-to feature along with clickable footnote numbers -- clicking on footnote 5 takes you to that footnote on the bibliography: page for that article (and/or mouse over text of that footnote is displayed). -- Daniel Mayer (aka mav)

1 0

Re: Re: [Wikipedia-l] Where to put acknowledgements
by Daniel Mayer 21 Aug '01

21 Aug '01

What's wrong with simply placing any attrib or URL in the edit summary that places the text in the article? The history isn't editable and will (hopefully) be a permanent part of the article. That, combinded with another notice at the top of talk will be more than enough. As for others using our material; we already require a link-back to the original article so others can access the talk and history. -- Daniel Mayer (aka mav)

1 0

Re: [Wikipedia-l] wikipedia.org
by Daniel Mayer 20 Aug '01

20 Aug '01

On Monday 19 August 2002 03:41 pm, you wrote: > also .info, .net > > That these are safe is not bad but to buy every possibel wikipedia.* > seems a waste to me. > > giskart Wouldn't be cheaper and more sensible to trademark the word "wikipedia" in order to prevent somebody from actually using wikipedia.info/.org/.ca or .whatever? At 30 bucks US a year per TLD that could get expensive. I think it would be far better to eventually asign each language their own .org URL that is their languages' version of the word "wikipedia" (Vikipedio.org for Esperanto or Wikipedia.org for English for example). -- Daniel Mayer (aka mav)

1 0

The future of Wikipedia
by Krzysztof P. Jasiutowicz 17 Aug '01

17 Aug '01

Hello all, The same article was put on a Wikipedia page. I think that we have grown a Wikipedia community. Wikipedia is a volunteer project that was made possible by Bomis. However, we have invested in our favourite project a lot of enthusiasm, time and (in some cases) money. It is quite natural that we want Wikipedia to prosper. In my opinion it is a time to stop and discuss. Discuss the future of Wikipedia. How does Bomis see it ? How does Nupedia see it ? How do we ? The future might be or might not as bright as our imagination whispers into our ears. Wikipedia is a great idea combined with a new, revolutionary software and it has a lot of brilliant committed authors. Her growth is explosive. But there are also weaknesses (Wikinesses ?) brought into light be some of us. Reliability The other side of the free writing style in Wikipedia is quite possible lack of reliability. This lack of reliability would in the end undermine Wikipedia's credibility and ultimately her success. This issue must be tackled, and as soon as possible. I don't agree here with [[Larry Sanger]] and his view "self-healing". It is an example of elated wishful thinking that is misleading us. I'd rather agree with [[Piotr Wozniak]]. His ideal of reliability is EB and he is anxious about the potential lack of it in Wikipedia. I am very interested in other people views. To start the creative process of discussion I'll give you my ([[Kpjas]]) idea : Why not create two parallel Wikipedias one public Wikipedia that is almost frozen (apart from Talk pages, Feature requests pages and the like). And the working Wikipedia for contributors. Forseeing your criticisms of the proposal that it would hamper netizen involvement - Edit this page could lead into the working Wikipedia. Scalability There are two ways of Wikipedia growth - global or niche. If we decide in favour of global growth - being slashdotted only first symptom of a serious problem. I'll give you my ([[Kpjas]]) idea : :Nowadays distributed software solutions are the height of fashion. Why not devise a distributed Wikipedia ? Programmers ? Multimedia A picture can say more than, say, several Wikipedia articles. It is rather trivial. I think that Wikipedia without pictures, video, and audio is not a real encyclopedia. I wonder if you think my propositions worthwhile : AudioWikipedia, PhotoWikipedia, VideoWikipedia - pages that can be linked from the real Wikipedias but having only a title and Talk pages. Internal data format This point is connected with Software issue below. Current data format is otherwise an example of excellent software solution. But understandably the creator of it did not envision the scale of Wikipedia. It poses numerous problems like searching through Wikipedia and others. My ([[Kpjas]]) thoughts wander around [[XML]] data format in connection with a free [[database]] like [[MySQL]]. And your thoughts ? Editorial process Much has been said about it but not much done. We have an excellent and hard-working editor-in-chief - [[Larry Sanger]] but I think Wikipedia in current form needs several such editors and when it reaches 100,000 pages 1000 Larrys. My idea ([[Kpjas]] is : Create editor teams online that would cross national Wikipedias borders. The teams would need tools to work effectively. One, the simplest, in terms of setting it up are separate mailing-list devoted to editorial groups like [[Architecture]], [[Philosophy]] and so on. Software Like any other open software project the software behind it should be free and open to all. The same applies to Wikipedia software. As I said above wikipedia software (usemod wiki) is a revolutionary and of very good quality but needs of Wikipedia as a global encyclopedia of unrestrained growth go beyond that kind of software. See also above Internal data format. On the Wikipedia mailing list [[BryceHarrington]] proposed making the Wikipedia software publicly available on [[CVS]] for further collaboration on its development. Commercial and organizational issues I'm no good at it. But to me it seems to be one of the most important issues, second to wide netizen involvement. Please, share your feelings and opinions here. Best wishes to everyone, kpj. -- Krzysztof P. Jasiutowicz, M.D | Nic w przyrodzie nie ginie, jedynie spełnione Czestochowa, Poland ... | nadzieje. Stanisław Jerzy Lec Więcej cytatów : http://www.cytaty.prv.pl

4 6

(No Subject)
by sanger1＠nupedia.com 17 Aug '01

17 Aug '01

Bryce, no doubt, I would be miffed if I were you. I share your confusion, too. I had no idea that it was such a small operation (remember, I'm not a programmer, so you must explain things simply and clearly to me, if you want me to understand). I assure you that there is absolutely no *resistance* to the request--unless inertia counts as resistance... Nupedia isn't making any money either. In fact, Wikipedia is much closer to the point where it might (somehow) make money for Bomis (and therefore, potentially, for anyone else who wants to use the content for profit). Anyway, remember, Wikipedia, like Nupedia, is a volunteer project--so it's not surprising (though regrettable) that essential features like this should be rooted-for and planned by volunteers. Really, we should have done this long ago. On the other hand, long ago, we didn't really know that the project would be so successful so quickly, that this would be so important and useful so soon! Larry ----- Original Message ----- From: "Bryce Harrington" <bryce(a)neptune.net> To: <wikipedia-l(a)nupedia.com> Cc: <jasonr(a)bomis.com> Sent: Wednesday, August 15, 2001 11:29 AM Subject: Re: Re: [Wikipedia-l] Wikipedia teamwork > On Wed, 15 Aug 2001 sanger1(a)nupedia.com wrote: > > ... but, well--our programmers are very busy > > with projects that actually make money. :-/ > > (And the rest of us programmers are not?) > > Wikipedia gains nupedia a good deal of attention. You also have said > that there may be articles which can go into nupedia. I further imagine > you will find other ways to profit off wikipedia more directly; I know > you have expended thought in this area. > > The reason many people got involved (at the very least, *me*) was the > willingness to hold the content under the GFDL. As I see it, what folks > are asking is simply to deliver on the promises made at the outset, and > frankly it's rather frightening to encounter any resistance to requests > like these. (Like a car manufacturer refusing to do warranty work > because their employees are busy making new sales.) > > This is NOT going to take anyone more than maybe an hour to do. It > isn't really even programming, per se; any unix sysadmin should be > comfortable crontabbing tarballs of a website. And it IS tied up with > being able to continue making money; call it a marketing or legal > requirement if nothing else. > > Anyway, I'm a little miffed - you said your programmers were too busy, > and that you'd appreciate it if someone would supply code to do it. I > responded with some code that would do the minimum needed to comply > (just change the paths). I was anticipating a thank you, but instead > "It does no good to post it here"? Well, call me confused. ;-) > > > [Wikipedia-l] > To manage your subscription to this list, please go here: > http://www.nupedia.com/mailman/listinfo/wikipedia-l

3 4

Multimedia and file uploads
by Stephen Gilbert 16 Aug '01

16 Aug '01

>> Multimedia >> >> A picture can say more than, say, several Wikipedia articles. >> It is rather trivial. >> I think that Wikipedia without pictures, video, and audio is not a >> real encyclopedia. >> I wonder if you think my propositions worthwhile : >> AudioWikipedia, PhotoWikipedia, VideoWikipedia - pages that can be >> linked from the real Wikipedias but having only a title and Talk >> pages. > >Agreed, agreed, agreed. What we need, essentially, is an upload tool >that lets us post images onto the wikipedia site. This opens many >benefits but also some cans of worms, so this is not a trivial request. > >I've written file upload systems several times over the years, and I'm >about to need to do yet another one at work. I will *tentatively* offer >to volunteer to provide something that can be plugged into wikipedia to >do file uploads, if Larry and Jason give the go ahead for it. It may be >a few months, if at all, before I can have it ready, though. > Until then, is there any reason why we couldn't use FTP to upload images? An anonymous FTP account allowing us to upload to, say, www.wikipedia.com/images would do the trick, and we could simply link the pictures from there.

1 0

Re: [Wikipedia-l] The future of Wikipedia
by koyaanisqatsi＠nupedia.com 16 Aug '01

16 Aug '01

>> Hello all, >> >> The same article was put on a Wikipedia page. > >I just have a few random, not-worth keeping comments so will reply here >rather than on the wiki site. (Btw, good idea to post it there.) etc. I think these comments are worth posting on the site. Ah, modesty.....0

1 0

Further caveat
by Larry Sanger 16 Aug '01

16 Aug '01

Just by the way, I have it from an excellent source that there really is no appreciable likelihood that Wikipedia will die because Bomis goes under, barring acts of God and such. It is great to be able to say, truly, that Bomis has very nicely weathered the great Internet bubble-burst. Larry

2 1

archiving the Wikipedia
by Tim Chambers 16 Aug '01

16 Aug '01

I'd like to have access to a tarball of the Wikipedia. Larry mentioned Jason as being the one to set up the cron jobs, so I'm copying him FWIW. A couple details haven't been discussed: 1. When the tarball becomes available, I assume it'll be a link from the appropriate Wikpedia page? I'd propose at least HomePage. Maybe Wikipedia_FAQ. And how about a page devoted to the tarball. Say, [[Wikipedia Snapshot]]? See 2. It wasn't discussed whether all versions would be archived or not. That, of course, is ideal. But it will grow ''ad infiniutum.'' (''ad nauseum''? :-) I think it's essential for the historical record to archive all revisions, but I think there should also be a "snapshot" tarball of only the latest version of each article. It would be considerably smaller and wouldn't grow as fast as the full archive. If that was done, then there could be a page called [[Wikipedia Archives]] that had links to both tarballs. <>< [[Tbc]]

3 2

Simple but useful Wikipedia change, perhaps
by Larry Sanger 15 Aug '01

15 Aug '01

Hey Jason, Have a look at what Dan Keshet says, about 2/3 the way down this page: http://www.wikipedia.com/wiki/Larry_Sanger/An_impending_scalability_problem It would make lots of people happy if we would copy his code to Wikipedia's current implementation (without having to upgrade to Cliff's latest version). It would help with scaleability. Larry

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Wikipedia-l