WikiPedia:Village pump (perennial proposals)

From Wikipedia, the free encyclopedia.

Contents

1 Always fill the summary field 1.1 A better description 1.2 Javascript extension 2 Spell Checker at Edit Pages 3 Wikimedia Affiliate at Amazon, BN, etc 4 Discussion Pages - Bring Modern Interface 5 Discussion Pages - A Semi-Modern Interface 6 Abolish personalized signatures 7 Filter or Site for Young Students 8 Abolish anonymous users 9 Better visibility for ideas

Always fill the summary field

Always fill the summary field. is Wikipedia policy.

My proposal is that something be done to help decrease the number of edits with a blank summary field. The obvious idea is to not accept a change with a blank summary field. I have my doubts about that, but I suggest that one letter summaries might be a clue that the edit itself is suspect, while a blank summary is now so common it is useless for that. Second idea is a plea to please please put something in the summary. A third idea is ten one word check boxes (revert, spelling, minor, etc) to make checking a box as easy as a one character entry into the sumary field. I'm sure others have equally good ideas. 4.250.132.28 04:56, 30 Apr 2005 (UTC)

Would it be possible to automatically detect a blank summary field and add characters from the edit? Where there are multiple edits, it could prioritise the first human readable change. Just a thought. Bobblewik  (talk) 15:52, 30 Apr 2005 (UTC)

That would be a great idea. I am often too lazy to fill out summary fields. - Omegatron 23:11, Apr 30, 2005 (UTC)

Adding code to the software to do this has been suggested several times before, but it was always rejected on the (quite reasonable) grounds that people who can't be bothered to leave a decent edit summary will just put random crap in if we force them to do something. In general, there aren't technical solutions to sociological misbehaviours. I suppose Omegatron's forgetfulness is one reasonable reason to implement this (there are technical solutions to honest mistakes), but don't expect a golden arcadia of well-written edit summaries. -- John Fader (talk | contribs) 23:23, 30 Apr 2005 (UTC)

We aren't forcing... people like me... to fill in the edit summaries with random crap. We are having the software fill in a bit of what they added to the article. This isn't a "use technology to force them to type something" thing, it's a "use technology to fill it in for them" thing.

Thus, if I change the phrase "often forget to" into "am often too lazy to", the edit summary will automatically be filled in for me: "often forget to" --> "am often too lazy to", or, less technically demanding, just "I am often too lazy to" as the edit summary. If you don't change the edit summary from the auto-generated section heading or blank, it automagically fills in a bit of your diff as the edit summary. - Omegatron 04:02, May 1, 2005 (UTC)

What if it came up with an "Are you sure" message, like when you send an email with no subject? That way if people didn't want to fill in the summary they could just say yes, but if they had just forgotten then they could go back and do it. MyNameIsClare 09:27, 2 Jun 2005 (UTC)

On a related note, I think I will create a Village pump (perennial proposals) section for things like this which come up often. (I suggested it a while back, too.) jdb ❋ (talk) 00:17, 1 May 2005 (UTC)

That is a great idea. - Omegatron 04:02, May 1, 2005 (UTC)

Writing an edit summary is a great curtsey to other people having that article on the watchlist. It is at least somewhat similar to writing a subject in an email.

One should make good concious effort to write an appropriate edit summary. People should not be forced to write an edit summary, they should be aware that is good etiquette and follow it. You should not have the software write an edit summary anymore than you trust your email program to write the subject line for you. Oleg Alexandrov 04:15, 1 May 2005 (UTC)

Many applications provide default field contents that can be changed, rather than leaving it blank. Sometimes the default is simple like 'Doc1' and sometimes it is more sophisticated and reflects previous user input. However, the principle of field completion by default is certainly commonplace. The popularity of such design features is by no means a suggestion that people who buy the applications are lazy or discourteous. We even have such a feature right here on Wikipedia. For example, when you edit a section within a page, the summary field defaults to the section heading. Whether it is desirable or feasible is another matter. Bobblewik  (talk) 11:07, 1 May 2005 (UTC)

The Edit Summary Box would be better off being at the top of the edit page. The psychological reason for this is I think best explained as follows:

The desire and reason to edit is uppermost in ones mind when clicking on 'edit this page'. At this point it is easy to add an 'edit summery'. In practise one does not even see it -out of sight -and out of mind -at the bottom. Should one wait until the edit is complete and the mark-up characters are in place and the preview checked to ensure it looks pretty and professional... the original 'memory state' has expired and the original reason for the edit has passed to 'intermediate memory.' Also the desire has been by this point been satisfied and so the emotional linkage too, has been broken. This is why it can seem like too much bother to change gear mentally and start to ponder some suitable utterance. What is more, it is now more difficult, because one now has the distraction of how the new version actually looks and this may 'read' slightly different to ones original expectation. It becomes to feel almost like one is now being asked to justify ones actions.

Simply put the edit summary on the top of the page text field and all this is avoided. It is an easy oversight to make. I have often found forms with the fields still in the order that they were originally thought of -without any consideration for the ergonomics of the mind.

Also, if possible, have a reminder to add a summery if summery field is empty when 'preview' is selected and do not show the preview until something has been entered. This will help to 'condition' those with poor memories. I think this will only be an irritation to those who irritate others by not putting a summery. Aspro 17:22, 8 May 2005 (UTC)

I vote for leaving the summary field where it is: When I click 'edit' I want to start editing right away, not summarize something I haven't yet done... I might change my mind while editing or find another thing to fix as well. Better do the summary last and have the field close to the "Save" button.

I usually do reasonably good edit summaries when I can. However, I often make several unrelated changes in one edit, sometimes because I notice an additional problem with an article once I start editing for the initial change. If one wrote the edit summary at the beginning, that summary may not reflect further changes made to the article in that edit. Therefore, I would prefer to leave the edit summary at the end. Also, it seems to me that the edit summaries cannot be changed once the edit is finished. Occasionlly, I've found myself in a position where the edit summary is saved, but does not relect the edit content well and, it seems to me, there is no way to back and change the summary, so I just let it go the way it is. Maybe some guidelines or standard ways of briefly summarizing minor edits can help, like "sp" for a minor spelling edit, "p" for a punctuation edit, "f" for a format edit, "link" or "fx lnk" for edits that create or fix links, respectively. H Padleckas 02:07, 17 Jun 2005 (UTC)

A better description

This is not a proposal for forcing people to fill in summaries (everyone agrees this is a bad idea).

This is not a proposal to make filling summaries policy (it already is) and encouraging it more often (this already happens).

This is a policy to add some info about the edit when someone doesn't fill out the edit summary field, making patrolling easier on everyone. For instance, if I make a minor change to an article, changing "5KV" to "5 kV", I just press alt+s out of habit, without filling out the summary. What would be ideal is if the software just autogenerated a summary of:

16:15 Electricity (diff; hist) . . Omegatron (Talk) (→Voltage - "5KV" → "5 kV")

Likewise, vandalism would become SOO much easier to see, because it would autogenerate edit summaries like:

16:15 Politics (diff; hist) . . 192.1.2.123 (Talk) (→Political concerns - Added "poop")

16:15 Politics (diff; hist) . . 192.1.2.123 (Talk) (→Political concerns - "is a member of the" → "IS GAY!!!")

While reducing the need to look at diffs with summaries like:

16:15 Politics (diff; hist) . . 192.1.2.123 (Talk) (→Political concerns - "the the" → "the")

How could anyone not think this is a good idea??? It's just displaying the first few changes from the diff page, saving work for everyone and reducing server load by preventing the need to load a large proportion of the diff pages. - Omegatron 16:46, May 10, 2005 (UTC)

Oh, and the auto-generated summaries should be in a different color so they can't be faked, which was my first (trivial) objection to my own idea. (Even more unlikely than vandalism with fake edit summaries done with the current software, which never happens.) I made them green in the above example, though maybe the same gray as the section name would be best:

16:15 Politics (diff; hist) . . 192.1.2.123 (Talk) (→Political concerns - "the the" → "the")

This saves server resources by processing a diff only once, preventing the need for many people to load that diff again in the future.

Details:

• The basic generated summary would be of the "inital version" → "changed version" format. It should just use the first x words of each version. If only one word is actually changed, it should still use the surrounding words for context: "the first five words of" → "the original five words of"
• If words are only added or removed, it should just say Added "word", although that would be better in context, too. Perhaps Added "word" → "The person's favorite word is". Maybe the added word could be in bold or something: "The person's favorite word is"
• If merely adding a category or interwiki, it would say Added category Words and make the cat a link. Added interwiki de:Wort (Begriffsklärung). (It should not just say Added interwiki de, for example, as the summary could prevent erroneous interwikis. More info and more linkability is better.)

- Omegatron 21:28, May 10, 2005 (UTC)

A great idea. jdb ❋ (talk) 03:34, 11 May 2005 (UTC)

Javascript extension

Someone came up with a great extension you can put in your monobook.js file which does a quick & dirty check on your edit summary…if I can remember where I got it I'll post the reference here. --Phil | Talk 16:28, May 18, 2005 (UTC)

Take a look at this which I modified from here. HTH HAND --Phil | Talk 16:33, May 18, 2005 (UTC)

What does it do? Could it be altered to do what we talked about above? - Omegatron 16:36, May 18, 2005 (UTC)

Basically it checks whether you have anything in your edit summary outside any "/*…*/" which might be put there…like I said, it's quick and dirty and catches me most times if i forget (although I think it might have problems with white-space, I'm not certain). HTH HAND --Phil | Talk 07:19, May 19, 2005 (UTC)

Spell Checker at Edit Pages

I believe that adding a spell checker to the Edit Pages can reduce the number of spelling mistakes in an article.Gaurav1146 19:29, 20 Apr 2005 (UTC)

Nice idea...

Maybe it would. However, it is very difficult to implement from a coding point of view, would bring big debates like colour/color, specter/spectre, and aluminium/aluminum into play. Overall, it may well be more hassle than it is worth. On the other hand, there is nothing stopping you using a client-side word processor to spell check your end. Smoddy (Rabbit and pork) 19:45, 20 Apr 2005 (UTC)

I dont agree with the arguments put up by you. As far as issues of American and Queen's English is concerned it can be sorted out after a discussion. One possible solution is that the word processor accepts both the American and the English version as correct. That is it takes both "colour" and "color" as correct but if somebody spells it as "calour" it should report it as an error. The solution that u pointed out of running a word processor at client side also does not seem logical to me. The reason is that not everybody editing wikipedia would take the pains to do that. As far as coding is concerned, I am not very sure abt the kind of expertise required. To conclude I would just say that if it is not technically impossible to add it, then it should definitely be added.Gaurav1146 20:15, 20 Apr 2005 (UTC)

While it would certainly save many typos, I think the necessary complexity outweighs the benefit. It's bad enough having to wait for the preview to reload, never mind having typos flagged somewhere along the line. Some browsers have spell checking built into them. (At least, the two I use do; Safari and OmniWeb. Not sure how the situation is on other platforms.) Problem solved. — PMcM 20:26, 20 Apr 2005 (UTC)

This is not a panacea, but Wikipedia:Text editor support explains how to interface Mozilla with your favorite editor. Having this configured, one just needs to right click from a text area in a browser, click on the obtained menu, and have the wiki text pop up in the editor. After you edit/spellcheck and save the text, the brower reads it back. Oleg Alexandrov 20:34, 20 Apr 2005 (UTC)

Besides, it's quite satisfying spotting and fixing typos. I guess you could look at all the other editors as being a built-in spell checker/fixer. — PMcM 20:52, 20 Apr 2005 (UTC)

Just noticed there's a more comprehensive earlier discussion on this very page, just up a few days; Wikipedia:Village pump (proposals)#Spell Check — PMcM 22:09, 20 Apr 2005 (UTC)

BTW: "Queen's English" does not simply mean "UK English", it's rather narrower than that. -- Jmabel | Talk 04:38, Apr 21, 2005 (UTC)

The only reason I started this discussion was that I observed that spelling errors were quite common in Wikipedia articles. Yesterday I picked two three articles at random, copied them to MS word and looked for spelling errors. There were one or the other spelling error in each of the article. Today I tried the same thing on two featured articles. Even these articles had some spelling errors.Gaurav1146 06:03, 21 Apr 2005 (UTC)

Then fix them. Thryduulf 07:53, 21 Apr 2005 (UTC)

Obviously I did fix them. As there are not many takers for the suggestion,so no point discussing it any further. Gaurav1146 20:19, 21 Apr 2005 (UTC)

Hi Gaurav, this is a good idea, and I think we should definitely implement it someday. The question is when, and how expensive (in terms of coding-time, server processing, etc) it would be. I think the big holdup is a) writing the code for an editor-plugin, and b) figuring out how to present the potential spelling corrections, so that it would be useful. Do you have specific suggestions? +sj + 06:07, 4 May 2005 (UTC)

copied them to MS word and looked for spelling errors ... hmmn. 'nuff said. --Vamp:Willow 17:15,?(null) 21 Apr 2005 (UTC)

Cor, but that takes an extra minute or so...

A reason not to do this that hasn't been mentioned yet is that it would consume massive amounts of server CPU. (Or so I've heard.) Nickptar 20:28, 21 Apr 2005 (UTC)

Hm. It would be easy, if much less complete, to add some client-side javascript (or even a server-side script) to highlight the 1000 most common misspellings on Preview pages. (We could find those by running a real spell-checker on the actual WP database, and picking (with some editing for proper nouns, etc) the most common misspellings. jdb ❋ (talk) 16:34, 4 May 2005 (UTC)

Also see User:Omegatron#Spell checker for instructions on client-side checking with Firefox and the Spellbound extension. - Omegatron 16:26, May 10, 2005 (UTC)

One side effect of not having a spell checker is that poor spelling is still viewable. I've found poor spelling frequently accompanies poor content, so this is helpful to point out sections that need help. - Omegatron 16:16, Jun 17, 2005 (UTC)

Wikimedia Affiliate at Amazon, BN, etc

Would it not make sense for Wikimedia to use an affiliate link under pages that deal with ISBN numbers and links to books/cds/etc. It doesn't impact the quality of Wikipedia at all and would bring in a few thousand dollars in revenue each quarter (a substantial amount to a non-profit). Nick Catalano (Talk) 00:28, 9 May 2005 (UTC)

We had something like this set up a while ago, but it was removed... +sj + 21:07, 11 May 2005 (UTC)

Is Wikimedia really in the business of supporting one particular vendor over another? Most of the work here is done by individuals, yet you picked two large corporations for your examples. I, for example, would be a lot less likely to add ISBN information to an article if I knew it would direct people to a direct competitor of the bookstore I own! How many other booksellers are here that would be ticked off by something like this? Gary D Robson 22:11, 26 May 2005 (UTC)

Hear hear. Given an ISBN number, it is perfectly convenient to find a retailer offering the book.

Discussion Pages - Bring Modern Interface

Hi,

I'm new to this community, and I intend to stick around as a regular contributer of articles. I've noticed a peculiar problem that I'm sure others have brought up - why does wikipedia use such a cumbersome discussion feature? Why not update the discussion section to look more like more modern and organized thread discussion board systems? The simple appearance can be maintained. Take a look at the software this board uses. [1] (http://www.xoxohth.com) Very simple and maintains a tree format too. Currently I believe the peculiar all page edit system in place is unfamiliar to new users (like me), and for those who infrequently stop by will be discouraged from leaving a comment because it does not appear so simple. Also I believe a thread system will be more compact and well organized. What have been the objections to such a system?

Lotsofissues 09:28, 26 Mar 2005 (UTC) (<--- Take me some time to remember the tildas)

UPDATE: I did not intentionally make this message look so sloppy. I posted and it was published as one long line and this is what I got after attemption to correct it. Point proven. :-( :-|

Are you volunteering to write the sizable amount of code needed to integrate a web forum into MediaWiki? Development happens solely through volunteers, and none of the ones we have now see doing this as a priority. -- Cyrius|✎ 16:12, 26 Mar 2005 (UTC)

Also, I suspect the reason it hasn't been a priority is that once people master MediaWiki markup and get used to the difference between editing sections and a whole page, they don't have much of a problem with using the same editing interface for discussion and article pages. --Coolcaesar 23:13, 5 Apr 2005 (UTC)

I agree with Lot's suggestion. Wiki pages were just not designed for discussion; it's like trying to use a round peg for a square hole. A true forum interface with threading and editable posts would be vastly superior to the current setup. Also, Cyrius is mistaken; there would be no need to write vast amounts of code; open-source forum software already exists. It would be a matter of picking the most appropriate one, setting it up, and configuring the discussion tab to link to a forum thread instead of a talk page. (Current talk pages could be auto-incorporated into the new threads). - Pioneer-12 19:08, 13 Apr 2005 (UTC)

As Cyrius points out, the developers are volunteers. When I propose we raise more money, I'm told we have more than enough. Time to start paying developers to sit in the rack room and glue the infrastructure together -- not to mention, to improve it. — Xiong熊talk 06:12, 2005 Apr 22 (UTC)

Even if it were easy to integrate a forum system like Slash (gasp!) or phpbb (shudder), I think it would be an bad idea because it contravenes WP philosophy. The current talk-page format is discussions in the wiki style -- anyone can edit anything. If the discussion is over, the thread can be deleted. If the discussion is splitting into two overlapping threads, an enterprising editor can split them up. If someone disagrees with that enterprising editor, they can revert the changes. Traditional web-boards have none of these features -- in fact, they are designed to make it impossible for non-mods to edit the general thread of discussion. Trying to hack those features into a traditional web-board would be silly -- you would end up with what we have already.

Lotsofissues, I'm curious what in particular you dislike about the current format. It may not be the the same as what newbies would be used to, but it's not very hard to grasp, either. One feature that might make it easier for new people to post would be changing the "+" tab to one that says "Post new topic" -- the "+"'s meaning is terribly non-obvious. (BTW, what is a TTT? The discussion board you mentioned uses that TLA everywhere.) jdb ❋ (talk) 07:34, 22 Apr 2005 (UTC)

1. First the easiest question - TTT (Third Tier Toilet) is elitist applicant parlance for an all inclusive category of virtually all colleges in this country with the exception of schools determined elite by the elitist standard - those schools being Harvard, Yale, Princeton , Stanford, MIT, Caltech, Columbia, Cornell, Dartmouth, Brown, UPenn, Duke, Northwestern, JHU, Rice, Oxbridge, and the four premier liberal arts colleges Amherst, Williams, Swathmore, and Ponoma.

Indeed it isn't hard to be competent in this format - but even that skill level requires a bit of accumulated editing experience. I want a system for newbies (casual visitors) to comment as easily as many newspaper article feedback forums attached to the bottom of articles make it. MAKING FEEDBACK REGULAR - instead of occassional - sounds good right? A please comment on this article at the bottom leading to a familiar PHPBB style reply box would actively solicit critical/request info we need. 2. I think in many obvious ways Wikipedia has grown too large for this format. I do janitorial work which requires me to visit the VFD page - this is not fun - in fact, it's so tedious having to load the all of the page that it breaks my healthy editing rhythm. At no point does it become more like work than then. A reformed thread style format would be pleasant. 3. Despite contributer's mastery of this format by now, few would argue phpbb is not an easier format to post in. Contributers will begin to talk more amongst each other; perhaps then it won't take me a full year to become familiar with everyone. Lotsofissues 07:09, 23 Apr 2005 (UTC)

There is plenty to dislike about the current format. First, "Anyone can edit anything" is just plain wrong for discussion. My comments are my own. Letting anyone edit them only causes problems and irritation. The forum method--that is, limiting editing access to only the poster and administrators--makes sense, saves time, and reduces irritation. Also forums have built in abilities for multipaging, standard formatting of user names, quoting previous statements, searching discussions by date--all abilities that wiki software has no real tools to assist for. Notice that no forums are clamoring to change over to wikis? It's ridiculous that I have to manually indent my posts, that I have to manually add my name to my posts, that there is no standard formatting separating one talk post from another, and that I have to manually add formatting for quotes. - Pioneer-12 09:39, 22 Apr 2005 (UTC)

People ought to write short posts, and if they don't, people split them up and reply to each point seperately. I'm not convinced about quoting. People sometimes edit your posts to improve your spelling and grammar or to remove personal attacks. Any other editing would probably be spotted and considered vandalism. I do not think there is any major problem now, but you may be interested in the concept of m:LiquidThreads. r3m0t ^talk 11:09, Apr 22, 2005 (UTC)

I quite like what we've got already. Contributing to a discussion is the same as editing pages: you only need to learn one approach. I agree that the "+" is non-intuitive: in fact it's so non-intuitive I didn't know it worked.--Dave63 08:01, 22 Apr 2005 (UTC)

There are considerable advantages to conducting discussion using a Wiki. The most obvious is that we can remove attacks and trolls, easily refactor long tedious discussions. and archive discussion threads whenever we want to. We can easily go back and retract things we should not have said. Also being lightweight and not obviously discussion-oriented it discourages long posts and point-by-point debate--which isn't what the talk pages are for. --Tony Sidaway|Talk 11:23, 22 Apr 2005 (UTC)

Tony---Well put -- I think the last advantage is the most important. If anything, WP should discourage the talk pages from being used as grounds for long-running discussions. People who wish to carry on lengthy debates are likely to be unhappy with the WP philosophy of merciless editing, rearranging, and deletion with the aim of reaching consensus, rather than declaring a winner. jdb ❋ (talk) 05:13, 23 Apr 2005 (UTC)

The need for organizing (archive) discussions becomes unnecessary in any modern interface. The need to remove attacks far dimnishes when every single user no longer has full admin power over a discussion page. Cockring.jpg blanketing needs to be removed; a FUCK YOU! thread - whatever. Lotsofissues 07:09, 23 Apr 2005 (UTC)

We absolutely should facilitate lengthy discussions. This format suppresses a long diagonal discussion - part of the process in supporting and defending the accuracy and fairness of a complex entry. More than casually critical ppl should not be grouped as unhelpful to the development of entries. Lotsofissues 07:09, 23 Apr 2005 (UTC)

Sorry for being late to the party here, but my take on this is that Wiki discussions tend to be much more thoughtful and articulate than any I've witnessed in fora or bulletin boards of any kind. This quality of discourse is probably a direct result of the features of Wiki: anyone can edit anything and useless comments tend to get dumped very quickly. We rarely see "I agree" contributions and even flamewars tend to be more like debates than tennis matches. –DeweyQ 18:49, 11 May 2005 (UTC)

Discussion Pages - A Semi-Modern Interface

I quite like the wikinature of the discussion pages, but I agree that they don't scale well. How about this: as well as the [edit] link next to every section, there is an [archive] link which automatically moves the whole section to an archive subpage. When /Archive1 gets large, /Archive2 can be used, and so on. I think this would be considerably easier to add to the Mediawiki software than a full-fledged threading system, and would greatly ease the archiving of old discussions.

Of course, if someone prematurely archives a discussion, then there is a corresponding [unarchive] tag on the Archive pages, and the standard 3-reverts rule applies in the case of archiving wars. Comments? --Jmstylr 11:49, 24 May 2005 (UTC)

Abolish personalized signatures

It is about time to abolish personalized signatures. Many signatures, if accidentally altered, would do evil things. Some signatures even contain images. -- Toytoy 15:28, Apr 19, 2005 (UTC)

Signatures work like anything else that can be added to a wiki page. There aren't any "evil things" that can be done with signatures that can't be done by simply typing or pasting. What specific dangers do you see here? --iMb~Meow 15:45, 19 Apr 2005 (UTC)

Just minutes ago, a screweed-up signature made the text that follows it <small>. Some users even include pictures in their signatures, therefore, a discussion page could be flooded with dozens of such small icons. -- Toytoy 16:33, Apr 19, 2005 (UTC)

Again, how does an error in a signature differ from any other error in wiki markup? It doesn't. It's no big deal, someone will notice it and it will be fixed just like any other error. This has nothing whatever to do with the fact that it was in someone's signature settings, just as taking away the signature feature would do absolutely nothing to prevent people from adding many images to a page. --iMb~Meow 16:41, 19 Apr 2005 (UTC)

Signature files do not carry needed information. If I want to know you, I visit your user page. It is not a good idea to make your signature file a miniature user page. I propose that we shall place some limitations on the use of signatures:

• No HTML.
• No more than 32 or 64 bytes.
• No images.
• No other external components.

I think Unicode characters are not a deadly sin, but some older browsers may not display them correctly. If we use Unicode characters or HTML tags in an article, usually it's mean to be informative (ideogram characters, math symbols, other symbols ...). Signature files are not supposed to be that informative. It is nothing but a road sign that points to your user page. You don't usually sign your name this way. When you sign your name, you do not write 100 advertising words. Bloating signature files are bad. -- Toytoy 17:12, Apr 19, 2005 (UTC)

It would be nice if we could customize the rendering of ~~~~. Then the server could enforce any restrictions automatically.

I don't think it would help, though. People leave behind all kinds of non-signature things which have potentially problematic HTML, inefficient table code, and images all over WP. At least we don't have 12-line ASCII art sigs (I bet I could do that in 32 bytes). —Michael Z. 2005-04-19 20:00 Z

I still don't see why this is an issue with signatures. How would the outcome be any different if we just said, "Don't use bad markup that ruins an article," which is probably policy anyway. —Sean κ. ⇔ 20:37, 19 Apr 2005 (UTC)

When you sign your name on a piece of paper, you do it the most effortless way. When you sign on the internet, either you don't sign it or you advertise it. This is why people abuse it. Leonardo da Vinci absolutely could draw. He did not draw a small Vitruvian man besides his name.

All I know is, I'm gonna start signing my name like this. - Pioneer-12 Missing image
Samurai.jpg


Missing image
Earth_flag_large.png
Earth

John Hancock, eat my shorts.

I know people can work out a way to beat the 32-byte restrictions, if there's such one. You can just copy and paste a 64 K gigantic signature loaded with dozens of animated GIFs each time you finish writing something. But the point is, if the cost to sign fancifully is not zero, much less people would do it. -- Toytoy 01:36, Apr 20, 2005 (UTC)

Dear heavens. What now? Check your email inbox lately? Or, for the truly staunch, browse Usenet awhile. Sigs of doom, sigs spanning multiple servers, sigs towering not merely over all content, but over thought itself. Singing sigs, smiley sigs, dancing sigs. Oy.

We have it good here, too good to be true. The odd image in a sig, not good. (I did that myself, thoughtlessly, but you see it's Unicoded now, and functional.) The occasional malformed sig, turning all following text green. The very worst sig I've seen is painstakingly rainbow-colored; must weigh in at half a typewritten page worth of markup -- and I can't even read it. None of these are problems that cannot be fixed with a gentle word to the good member.

There are good and fine reasons to personalize sigs:

• Users should take pride in their handles, and be reluctant to tarnish them with thoughtless comment. This is how users become community members.

• Our community is already way too large, so that it is very hard to keep track of other members -- the sort of informal, subjective, in-the-head soft reputation management that is the true glue of any community. Distinctive sigs help more than do bizarre names.

• The default sig sucks. At a minimum, the default should provide a link to the member's Talk page. On the other hand, maybe the default should suck. A nicely-customized sig is one way to tell the Old Heads from the noobies.

• Messing with sigs infringes on personal choice. I don't refer to style, but to function. My sig -- for example -- provides links to my user page, my email, and my Talk. I do this because I choose to be thus available. Other members choose less availability, and some include links to cherished pages that define their personalities.

But the crowning argument is just that some members will pay no attention to any such restriction! You can fix the engine to abolish sig editing, but users will just create sig templates and drop them in -- and I'll bet a dollar to a doughnut, they will transclude, too -- at least the tildes substitute.

Please, be happy and content with the relative peace which now obtains. Lest we return someday to see Quotations from Chairman Foo and nudie ASCII fancruft art. — Xiong熊talk 05:16, 2005 Apr 20 (UTC)

I've been using this plain vanilla signature for over a year. I thought about using "~~~~" as my signature with "raw signatures" selected. Whenever I type "~~~" (without time stamp), the system outputs "~~~~". Four innocent bytes.

This is not the most evil part of my plan. The "~~~~" in the code would soon be replaced to the next contributor's signature and date. What a great plan. I am smart.

Anyway, you must be very happy now to see me use my plain vanilla signature. I am a pacifist. Or I'll be the worst vandal in all human history. Ha! -- Toytoy 05:55, Apr 20, 2005 (UTC)

I find over-elaborate sigs annoying, but the inclusion of a link to the person's talk page actively useful. -- Jmabel | Talk 05:48, Apr 20, 2005 (UTC)

To an old crow known and contacted by many people, it is a good idea to provide a speedy link to the personal talk page. Otherwise, you may want people visit your user page before talking to you. I don't find it very useful to provide your contributions, your Kate's Tools external URL or your golden retriver's CitiBank credit card number in a signature which is supposed to be very small. Most decorative signatures are providing too little clues to their functions. You may see a weird Unicode sign but you don't know what the sign means unless you see the link. There are supposed to be some signature etiquette or rules. -- Toytoy 06:04, Apr 20, 2005 (UTC)

If you want to see where a user's sig links, mouseover it. Depending on your browser or your prefs, you'll get a hoverbox or the link URL in your status bar.

There is de facto sig etiquette: • Keep it short • No images • No templates • No markup that fouls up rendering • Link to your Talk • No blinking sigs •

I only worry that this discussion may prompt the feared action. — Xiong熊talk 06:31, 2005 Apr 20 (UTC)

God, I am a nice and creative mother. -- Toytoy 06:45, Apr 20, 2005 (UTC)

What's that? --{{User:Carnildo/sandbox}}

The "broken" small-tag in the signature I have been using for some time is there intentionally. Nobody ever came to my talk page to tell me they're annoyed by it. If people complain, I will change it. Extremely distracting signatures are bad, but some Unicode and some html tags (font/colour) -- what's the harm in that? dab (ᛏ) 08:21, 20 Apr 2005 (UTC)

Relying on obscure bugs in the parser to render your signatures is a great way to piss off developers. Please stop it. -- Tim Starling 16:26, Apr 21, 2005 (UTC)

If that's the case, then why have some similar bug reports been closed? -- Netoholic @ 21:04, 2005 Apr 28 (UTC)

I am using a black background and amber foreground setting with my browser, I also disabled almost every fanciful things (CSS, <font >, colors ...) so I don't see any of your color tricks. My Mozilla is like a Lynx text-based browser (I was using Netscape 2.x last year). By the way, I only use one font. To make my browsing more vanilla-flavored, I installed Privoxy and customized its filter settings to remove almost every decorative elements in the <body > and elsewhere. I disabled Java, JavaScript, lots of sites' cookies and most plugs-in as well. Why? Based on my personal settings, most of your colored texts would become very difficult to read. I am the reader. I am supposed to be the one to exercise my rights to change fonts and colors. Many years ago when I was using Macintosh, I downloaded no images and filtered even more HTML tags (tables, italic, bold, ...)! I don't want to read anything unless it's like being displayed on an Apple ][ monochrome monitor. -- Toytoy 08:40, Apr 20, 2005 (UTC)

Why are you telling us this? If you are going to such lengths to have control of browsing (I don't suppose you read print books or magazines, then), does it matter to you if people use different colors or fonts in their signatures? — Knowledge Seeker দ 16:44, 20 Apr 2005 (UTC)

In many ways we, as editors of *articles* leave very few traces on WP ... a little personalisation of handles where they are actually used (talk pages and the like) does little harm but a lot of good (self-esteem, handle recognition, direct link to talk page, etc.) I'm not overly happy of the more complex (I could do without photos and most graphics, thankyou) but each to their own, so long as they spend more time editing than creating wonderful sigs. --Vamp:Willow 17:12, 21 Apr 2005 (UTC)

• Customized signatures are really for self-esteem and a bit of fun for some users. If it helps attract people, so be it, in my view. JuntungWu 15:34, 23 Apr 2005 (UTC)

• I strongly support customization of signatures. тəzєті 23:52, May 13, 2005 (UTC)

Filter or Site for Young Students

I know it's been said that wikipedia shouldn't be used by children without parental guidance, but it is quickly becoming a useful resource and I think an alternate site needs to be setup that helps me as a parent control what my children see online. My children are good to me and they surf the Internet only going to sites which I have bookmarked for them. I have also setup a way to remotely monitor their screens without them seeing me do this, and the results have shown so far that they are behaving. However, I cannot bookmark wikipedia for them until an alternative is setup.

I need something that filters out sexual or violent images, sketches, drawings, and topics; filter out sexual keywords; does not provide links to other sites; and includes current events (news items) that can be researched. Hopefully this might be considered something viable for their short student papers in the lower levels, as long as they use one other credible paper source from a regular library.

There have been several proposals for a content filtering/labelling system in the 5 months I've been here, but every one of them has failed. The reason for this is that the community has been unable to agree a system that is compatible with our Neutral Point of View policy, particularly with regard to a definition of terms like "sexual" and "violent". Wikipedia is international, and the cultural and community standards of what is acceptable for what age-group vary considerably from one place to the next (e.g. images of nudity are generally more acceptable in Europe than they are in the USA). See Wikipedia:Content labeling proposal for a recent example of a proposal.

If there were a system letting the user (parent) decide what's objectionable and what isn't, then it would be somewhat more NPOV - as opposed to a binary flag, there would be "sexual imagery", "sexual material", "strong profanity", "mild profanity", etc. flags. These would usually, but not always, be disputable. (For instance, how to flag Holocaust?) I just don't think this'll get implemented ever on WP, because the majority of people seem to hate the idea. Might I suggest that you use a content-based Internet filtering program? Nickptar 16:10, 21 May 2005 (UTC)

Of course, no one will ever have a problem with someone setting up their own site to mirror and filter Wikipedia. —Sean κ. + 02:46, 25 May 2005 (UTC)

Abolish anonymous users

This is probably one of the more frequent proposals. It has been proposed on Wikipedia and on meta

I'd like to suggest to editors that they read m:Foundation issues before commenting here. Soundguy99 16:01, 6 Jun 2005 (UTC)

Please, someone let me know the overwhelming benefits of continuing to allow IP addresses to edit pages. Restricting editing to only registered accounts would decrease the vast amount of vandalism (especially of the "drive-by" variety) ... and does not force anyone to give up their anonymity. In fact, you have more anonymity in editing with a username than an ip address, at least someone can traceroute you with an IP address. --kizzle 23:42, May 24, 2005 (UTC)

• Far too restrictive. There are some people who will register before they commit acts of vandalism... and while many IP edits do turn out to be vandalism, there are many IP edits which are not. Some articles have been started by and maintained by users who have not registered. I started out on Wikipedia editing as an IP before I registered an account. My feeling is that my barnstar for vandalism reverts was obtained 2-3 days after registering an account not just because of my actions during those 2-3 days, but also my actions as an IP editor.--Chanting Fox 23:48, 24 May 2005 (UTC)

It's the principle. This is a wiki, and it is supposed to be that way. How many of us, me included, just happend to stumble on to wikipedia from a google-search and and noticed the Edit this page-button? "No, it can't be that way.... It can't be that simple.... Well, there is a spelling error there, no harm in trying. Jesus Christ, it worked!" Yes, drive-by vandalism is common and irritating, but know that many (most probably) are newbies that don't really get how wikipedia works. Once they start to surf around they understand how it works, and starts to make useful, even great edits. As for the vandalism, most "serious" vandals get a user-name because, as you say, it get's you more anonymity, and you can create sockpuppets etc. Drive-by vandalism is much easier to fix in comparison. Personally, I think the openess of wikipedia is wonderful, truly it is what makes wikipedia the greatest site online, and we have to take the good with (the sometimes very) bad. Gkhan 23:57, May 24, 2005 (UTC)

• I think it's important to remember that being unregistered makes a person's edits stand out from the edits of others, thus making it easier for the Recent Changes Patrol to spot vandalism. If it is true that 90% of all vandalism is performed by unregistered visitors then this is a good argument for allowing such edits! Wikipedia will always suffer from vandalism no matter whether you allow unregistered users to edit or not. Under the status quo we have a useful tool. reetep 19:22, 30 May 2005 (UTC)

Hey, I never heard that argument before... that's a good point! —Sean κ. + 20:42, 30 May 2005 (UTC)

I agree with that line of thought. Registring help us to flag good faithed edits. edit Summary , helps us flag good modifications. By that we end by helping to identify the bad guys: because the good ones are proud of what they do.

Contributing without registering helps people "ease in" to the wiki world. Many users (myself included) start by making a few edits, get comfortable with wiki structure, and then make the decision to register and be seriously involved. If you had to go through a registration process first, no matter how simple, I think a lot of people would never hit that "register" button. I might not have. Let's not do anything to discourage people from getting involved. Gary D Robson 20:16, 30 May 2005 (UTC)

I HATE visiting wikis that want you to register just so you can fix the spelling and a few links on one page that you happened to visit. Totally annoying. The good solutions to vandalism are social and technological. - Omegatron 17:39, Jun 1, 2005 (UTC)

Case in point: http://www.infoanarchy.org/wiki/index.php/GAIM Look at all those spelling errors! But I'm not going to take the time to register an account just to fix that if I am never going to visit again. - Omegatron 00:58, Jun 2, 2005 (UTC)

Vandalism is a feature of mankind and should be let to take it's course here- hopefully it is found quickly and reverted back so that the whole project is a sum of it's parts, e.g most people want a useable resource. Most vandalism is recogniseable as such, like graffiti- one can accept it as long as it can be removed. If the vandalism is not recogniseable, then we come to the question; do we believe what we read anywhere in the world, virtually or in print? Anything can be vandalised -officially or not.

At least annonymous users should be make competely aware that they can be traced if need be. Perhaps smart software can recognise the form of vandalism that is taking place- I would suggest that new edits should appear in red in the main article until voted for by a determined number of subsequent users. after which further editing allowed. Slow, but it would prevent drastic vandalism.

Better visibility for ideas

It's so frustrating to write up an idea and post it on the village pump, only for it to disappear off everyone's radar when the pump is archived. We really need to provide highly-visible lists with short summaries of proposals and software changes and discussions about stuff like this, so people can check whether ideas they've had have been proposed in the past, contribute to discussions that would otherwise be forgotten, etc. - Omegatron 19:51, Jun 10, 2005 (UTC)

Nobody will ever check previous proposals before posting their own identical version. ;) Seriously, though, make Category:Proposals for Wikipedia or similar. r3m0t ^talk 16:36, Jun 17, 2005 (UTC)

But we can search for similar and merge them after the fact. I guess this intersects somewhat with mediazilla, but not with proposals for policy and stuff. A category is a good first step. I would want descriptive summaries next to each, though. - Omegatron 16:50, Jun 17, 2005 (UTC)