> From: "Menchi Zh-En WP" <ebeins(a)hotmail.com>
> Never mind me.
> It only shows in Hotmail to subscribers. Great, now I can starting stalk
> you.
Feel free. I haven't had an interesting stalker since university. :)
- Stephen
-------
Wikipedia: The Free Encyclopedia
http://www.wikipedia.org
I'm not recieving posts or digests, I haven't recieved one since I
signed up (3 days ago), and I am forced to always look at the archive...
Seriously, I'm gonna be forced to switch to NNTP (very annoying) if this
persists!
/Modern maps. Map producers directly compete with us, and it is generally
hard to see why we should be allowed to take their work for free, just
like we could not simply take the articles from the Encyclopaedia
Britannica.
/Not like we'd want the encyclopedia britanica articles :)
From [[Wikipedia:Always make articles as complete as possible]]
--------------------------------------------------------------------
One of Wikipedia's [[wikipedia:Policies and guidelines|rules to consider]]:
Whenever you write a page, always make it as complete and comprehensive as
possible.
<br>Don't create an article until it is in form ready for publication. If you feel that your article is seriously incomplete and you are urged to publish it please insert boilerplate text from [[Wikipedia:Stub]] into the article.
This rule is meant to supersede [[Wikipedia:Always leave something undone|
"Always leave something undone" rule]] that is regarded obsolete.
This rule is open for debate.
--------------------------------------------------------------------
Articles happen to be reviewed almost instantaneously (as they appear on RC)
or they can stay unreviewed with embarrassing errors for months (years?).
Cooperation and collective authorship that are behind the
"Always leave something undone" rule were great in the old days when there
were 50-100 edits daily not 3000+.
There's no guarantee that a proportion of articles slip form the RC and
plunge into the Wikipedia's great information soup.
This is an observation from perusing the ancient pages list.
Regards,
Kpjas.
I'd like to know if I'm alone in being quite tired of the current
Wikipedia logo (as used on en: and most of the non-English pedias). There
are several things I do not like about it:
1) It is a ball of hard to read, monochrome text, with two lines of text
under it. Since most of our content is text, it would be nice to have a
logo that has at least some pictographic elements. I personally do not
find it aesthetically pleasing either. IMHO, the absence of the textball
from the Cologne Blue skin is one of the key reasons why many people find
it more attractive.
2) The Hobbes citation itself is cute, but too subtle and pretentious; it
is also not particularly useful to readers unfamiliar with Wikipedia.
3) It is an English text, making it a bad choice for the international
Wikipedias.
4) It cites one specific philosopher and one specific quote, establishing
that particular point of view quite securely. While Wikipedia itself is
mostly neutral, the logo is clearly not. And just to make clear that its
text is far from uncontroversial, the Hobbes quote states that "man is
distinguished, not only by his reason, but also by this singular passion
[curiosity] from other animals". This is a highly anthropocentric view
with the classical animal/human distinction that is increasingly eroded by
our understanding of other highly intelligent and curious animals such as
chimpanzees, bonobos, whales and dolphins. Of course, that is not to say
that a more modern view should be taken; in fact, none should be taken at
all.
Wikipedia has thousands of highly creative users, many hundreds more than
when Cunctator originally created the logo. I think a logo contest on
Meta, officially promoted on all the main pages, could produce very
satisfying results: a visually pleasing logo which is international and
can therefore be used by all our editions.
Just a few ideas:
- an alphabet letter which also looks like a construction site
- a green tree with some interesting fruit (letters, pages or something
like that)
- several book volumes standing next to each other, with an inkwell
sitting on the top
- a flower or planet within a pair of double square brackets.
But maybe it's just me and everyone else loves the textball. I'd like to
hear some feedback on this. Just as a quick demo I have hacked together
the last idea from the ones above and put it at
http://www.scireview.de/wiki/Main_Page.html
in the context of the current Main Page. Note that this logo is just a
quick hack and I do not suggest that it should actually be used, but I
think that the colorful picture looks better than what we have now. Still
I admit that I have *no* artistic skills whatsoever. That's why I'd really
like to see what could come out of a large logo contest.
Regards,
Erik
> 2. Categories should be infinitely wiki-editable, especially in the
> beginning, because "a priori" categorization is impossible and likely
> to lead to a lot of problems. Ideas that only sysops can create new
> categories should be avoided until we actually determine empirically
> that it's necessary. (One thing we know from our wiki experience is
> that something as obviously insane as letting anyone in the world edit
> works amazingly well!)
Whose idea might you be refering to? ;-)
Well, it was not meant as a policy, but rather as a practical method, as I don't have a "history" function implemented.
But, now that this is no longer an option, how about this (technically):
* Operations on categories that are open to everyone:
** Creating a new category
** Renaming a category
** Merging two categories into one
* Deleting is (as with articles) "sysops only".
> 5. Especially initially, website impacts of categories should be very
> minimal... i.e. we don't try anything radical regarding filtered
> searches or automatic index pages or anything too exciting like that.
Great - some work saved for now :-)
Brion sarcastically wrote:
>Wow! Just like article titles. Maybe we should let only
>sysops name articles, then everyone else can fill in
>the information.
>
>But, they might repeat information or organize it badly.
>Better to let sysops define the structure of the article,
>then everyone else can fill in the bodies of the
>paragraphs.
I was proposing a voting scheme so why the straw man? I know and accept we are
a wiki but do we allow the wiki process to drive our software developement?
Isn't forming relations in a database that a SORT command could operate on
more of a software thing? Wiki is not a panacea and we are treding into
uncharted waters - I'm not aware of another wiki implementing a category
scheme successfully. Are you?
Either way, I am not advocating a "sysop-only" system on top of some broad
staring categories - at least until we establish a framework for how a
category system will work. Once that is set-up and working well, then we can
consider whether or not it is wise to open up the floodgates and let people
make weird little sub-categories the wiki-way.
>Having category aliases (just like redirects) and letting
>categories include other categories would make this
>"problem" moot.
Perhaps - so long as we have an RC that can be effectively managed. Of the
3000 edits made a day on en.wiki I review about 1000. Most people review far
less and only at certain times of the day. There is great potential for
categories to become nearly as numerous as articles real fast. That will
clutter the articles (or their meta namespace) and not represent an effective
way for people to sort articles.
>I am very strongly against a category scheme that
>is limited or sysops-only. I *want* my obscure sub-categories.
I've ALREADY stated that I want to just start small, at the top level, then
phase-in voting to increase the number of categories and THEN consider
opening it up further. Please do not mischaracterize what I stated - I DID
NOT say that this would be something limited to only sysops. Voting includes
everyone who is interested.
Also, how is anybody else going to know what the categories are? Person A
creates a bunch of really obscure sub-categories for a time. Then moves onto
other things. Not knowing about the work of person A, person B creates a
bunch more very similar sub-categories in a similar area. Now there two very
similar categories. Then person C does a sort based on person A's
subcategories (assuming person C could guess what those might be).
This could get out of hand if we do not first devise a way for us to find out
what different categories are. Different people will categorize things in
different ways and soon nobody will be able to remember what syntax they used
for a category. This happens all the time in badly created databases; Bay
Area Rapid Transit, Bay Area Rapid Transit District, BART, bartd are all the
same thing in the real world but to the database they are each different.
Category redirects would help here but before that we would have to establish
naming conventions to minimize duplicates in the first place and maybe a flag
on RC to indicate that somebody just categorized an article. Then there needs
to be a centralized place for all categories to reside so they can be
mangaged there.
How such a system would work needs to be made clear and we need people who are
familiar with how the system works so that they can effectively manage such a
system. A phased approach is needed - that is all.
This is adding a great deal of complexity to what we already have and exposes
many non-database-oriented people to the complexities of database design so
pardon me if I'm a bit weary about us just jumping-in head first on this.
KQ has already expressed many reservations about the ugly filtering issues
that a category scheme raises. I'm just trying to make sure that if such a
system were established that we do it right and minimize negative
side-effects.
-- Daniel Mayer (aka mav)
>Suggestion: We could easily import the existing
>lists into my implementation.
>
>Magnus
Only the major ones please. Many of the lists in WikiEn are really obscure and
special purpose.
IMO there should be very few categories (at least at first); One for each
major category that is already on, for example, the en.wiki's main page
(science, mathematics, physics, Linguistics, etc - the whole lot) along with
type categories like "biography", "city/town/village", "country/nation",
"subnational entitiy", "stub" etc.
Keep it simple please (at least at first). If /that/ works then we can slowly
expand the system in a measured and thoughtful way - voting for new
categories may be a good solution here in order to prevent a rapid expansion
of categories that would render the whole system useless.
I'm very weary of allowing just anybody to create any category since from a
database management perspective it would be easy for people to create many
different variants for the same intended category ([[category:biology]],
[[category:life sciences]], [[category:life science]], [[category:living
things]], [[category:the study of living things]] etc). And having too many
categories will be very difficult for people to remember and very unwieldy
for people to choose from in a category search. Let the lists stay for the
obscure stuff.
We also need to devise guidelines for when to assign labels. Again from a
database design perspective: If this is not done consistently then the output
or any sort will be suspect and perhaps complete garbage. As KQ pointed out
we could assign the category 'crime' to [[Jesus Christ]] along with the
category of 'biography' so that JC shows up in a list of criminals. But is JC
most famous for being a crime figure? No! He is famous for being a religious
figure so the category 'religion' would be there but not 'crime.' Same for
[[Bill Clinton]] ([[category:biography]] and [[category:politics]] apply
there).
With categories in place then one day we could have our special pages use
these tags for things like Recent Changes. RC in the English Wikipedia often
has 10 or more edits a minute now! It would be nice to have the option to
only see articles that may interest the user (well for me that would be
everything but one of my biology professors may want a recent changes that
only displays articles relating to mathematics, the sciences and economics).
This will become absolutely necessary if we continue our quasi-exponential
growth pattern for WikiEn; one day in not too many years (fewer than most
people probably think) there will be an average of hundreds of edits a
minute! We need to sort that out somehow or no human will bother looking at
RC anymore and will only revert vandalism to articles on their watchlists
(even with sorting, bots would probably have to help with automatic 'probable
vandalism/copyvio detection' - outputting results on a separate RC for that
type of stuff - maybe even by assigning those categories to articles...).
Alas it looks like Wikipedia is growing up. This time next year WikiEn
Wikipedians may start to specialize their edits based on which categories
they choose RC to output and several other language Wikis may follow the year
after. Our small town is beginning to show signs of emerging cityhood (or has
WikiEn at least already become a small city?).
We are going where no wiki has gone before. There is both danger and
opportunity in that.
-- Daniel Mayer (aka mav)
I just wanted to weigh in and say that I don't much care. I would
support any change to the logo that had broad support, and I would
also support the status quo.
I might get excited, though, if we could have a logo that would be a
picture of me in overalls with a shotgun saying "No fussin' an'
fightin', dammit!"
But, that's just me. ;-)
--Jimbo
I've got a pileup of work to get through on other projects, so I'm going
to take a week off from Wikipedia. (If I can -- wikipediholism runs strong
in my veins! ;)
If anyone really really needs to contact me for some technical emergency,
mail or IM me directly, as I won't be watching the wikis or the mailing
lists.
(If I finish up other things sooner than I think maybe I'll have time to
finish that conversion script for the old wikis, but don't bet on it.)
Don't go censoring everything and locking it all down to sysops while I'm
away, now. ;)
I'll return around June 23.
-- brion vibber (brion @ pobox.com)