Wikipedia:Village pump (proposals)/Archive 32

I support a policy using {{As of}} instead of [[As of ...]] links which cause confusion and are often deleted or altered in good faith by editors who haven't heard of the As of policy.

To reduce duplication in maintenance work, I suggest adding an optional url parameter for a url which seems likely to be updated if the status of the as-of statement changes, for example a relevant page on the official site of an entity the statement is about, or a page which currently maintains updated results and may continue to do so. Maybe there could be an option in preferences (off by default) to display a link to the url at the as-of statement. Even if such a link were never shown, editors seeing the source could copy the url.

And a minor suggestion: Let {{As of}} print lower case "as of" whenever the parameter lc is present, instead of having to type lc=on. PrimeHunter (talk) 16:52, 31 July 2008 (UTC)

Thanks for the support. The lc parameter will actually give lower case if the parameter is defined and not whitespace (you cannot simply use {{As of|...|lc}} as that would behave as {{As of|...|#=lc}} where the # is the parameter name and depends on other defined parameters). You could use, for example, {{As of|...|lc=1}} or even, with slight modification to the code, {{As of|...|lc=}}, but I proposed using lc=on as it makes the wikitext more readable. The same is actually true of the df parameter, although df=US allows addition of new date formats later if required. I will modify the template documentation to make this clearer. As for a url parameter; am I correct in thinking this should be a non-functional parameter? If so simply using url=[URL] in the template would suffice. It is possible to create an inline flag such as: ^[URL] to appear at the end of the template, but it would have to be hidden by default, and only visible to users who modify their Monobook.css file correctly. I am also wary of doing this as users who do not have CSS enabled will see the flag by default. Please note that these statements should usually be referenced anyway, and if such a URL is available it should be used as the reference. For now I will modify the documentation to suggest using the url parameter in a non-functional capacity only (it will probably be forwards-compatible). All the best – Ikara ^{talk →} 00:42, 1 August 2008 (UTC)

Anyone viewing wikipedia without CSS support will be viewing one of the blandest and most confusing sites on the internet. Without CSS, the interface (sidebar etc) won't display properly, never mind the actual content. Amboxes and talkspace messages will all display as plaintext, as will many navboxes, references, co-ordinate templates, etc etc etc. Wikipedia assumes CSS support for a sensible browsing experience, so the idea you propose above is a good and usable one. Incidentally, I think this proposal is an excellent idea. Happy‑melon 14:04, 2 August 2008 (UTC)

In that case, I will look at adding the flag assuming this proposal is accepted (given current reactions I expect it will be). The documentation now encourages the use of the url parameter to assist future editors. Thanks – Ikara ^{talk →} 21:54, 2 August 2008 (UTC)

I also strongly support this change. "As of" is very useful indeed, but has needed reform for a long time. I like everything about this unobtrusive new system. One small thing: the current template renders linked dates when Y/M/D are all provided, correct? Is the final product going to do that as well? I would remove datelinking from the results entirely. It's not a big deal, as I doubt that many users are going to provide tripartite dates in their as-of tags, but since datelinking is gradually on its way out, it might be nice to leave it out of this entirely. But anyway, great job. Mr. IP 《Defender of Open Editing》 13:47, 2 August 2008 (UTC)

'Scuse me, this is off-topic but: datelinking is on its way out? I thought that datelinks were part of accessibility? Am I confused with my definitions? Franamax (talk) 14:07, 2 August 2008 (UTC)

There is a group of editors who absolutely hate date linking and/or the date auto-formatting preference. They managed to get

Template talk:cite web regarding the dates in citation templates. I have no idea how large this group is versus the (unorganized?) opposition group or the uninterested group. IMO, the only way datelinking is "on its way out" is through attrition as others get sick of fighting over it. Anomie⚔

17:22, 2 August 2008 (UTC)

It's true. "On its way out" was sort of my way of saying "I intend to kill it dead" :D Seriously, as the practice is no longer recommended, I would prefer to see it left out when we're remaking templates and such. I admit that the earlier phrasing was tendentious. Mr. IP 《Defender of Open Editing》 17:49, 2 August 2008 (UTC)

The current template uses the {{Start date}} template to display the date, which automatically formats the date, adding the wikilinks. It does not add the links or have any control over whether the dates are linked currently, aside from manually adding the date without links using the alt parameter. – Ikara ^{talk →} 21:54, 2 August 2008 (UTC)

I would oppose making this into anything much more than a strong suggestions. This is

WP:MoS-type guideline but this is far too trivial to be a policy. Mr.Z-man

14:10, 2 August 2008 (UTC)

The use of "policy" here just appears to be sloppy wording. I don't think anybody is suggesting this becomes an official policy - I'm not although I copied the word from the original post in my responce. PrimeHunter (talk) 14:20, 2 August 2008 (UTC)

Agreed. This isn't policy so much as the improvement of a useful tool for keeping our encyclopedia up to date. Mr. IP 《Defender of Open Editing》 17:50, 2 August 2008 (UTC)

Apologies, that was my sloppy wording. "As of" is not and never has been an official policy. What I meant was to change the policy (guideline) of the project page and not of Wikipedia itself. Getting it included as a MoS-type guideline would be beneficial, but is still some way off. Hope that helps – Ikara ^{talk →} 21:54, 2 August 2008 (UTC)

Update: I have now added inline reference support and updated the template documentation and WP:As of to reflect this. You can see a static example in the documentation, for use in articles you need to add a line of code to your monobook.css page. Feel free to look over the changes and tell me if anything needs fixing. Thanks – Ikara ^{talk →} 02:40, 5 August 2008 (UTC)

This may be a bit ambitious, but I would like to request that one be able to watchlist a particluar section of an article. I must admit that the only reason I am requesting this is to watch portions of high-volume talk pages, such as here in the various Village Pumps.

I checked

WP:GTL; that's easy for a person to understand (when looking at the diff), but potentially nightmarish for computer software if, somehow, it were to try to keep track of sections for the purpose of watchlisting. And what about subsections, which are even more transitory? (Not that I'm not sympathetic; this is why pages like lists of AfD discussions are primarily transclusions of individual discussions - so that editors can follow individual discussions.) -- John Broughton (♫♫)

01:54, 1 August 2008 (UTC)

Yes, everyone wants this, nobody is objecting. Now, all we need is someone with the programing skills to improve the open software we run off of to do that. Despite what John says, I don't think it would be that complicated to program.

Chillum

01:56, 1 August 2008 (UTC)

Thanks for the replies. I didn't think it was a likely possibility, anyway.

talk

) 02:08, 1 August 2008 (UTC)

Given the difficulties John mentions, a more practical (though also quite revolutionary) way to go would be to eliminate the multi-topic discussion pages, like the village pumps and certain others (is it Requested Moves that causes similar problems? can't remember now), into dedicated discussion pages which can be merely linked to from a central location, as is done with AfD.--Kotniski (talk) 06:33, 1 August 2008 (UTC)

That's an idea. It would also mean that links would never die if you linked to a discussion and wanted to keep it as a reference.

talk

) 07:05, 1 August 2008 (UTC)

I'd strongly support this. The subpages could be transcluded to give the page an identical appearance to that at present. Watching the main page would give notification as to when subpages are added or removed. Pseudomonas_(talk) 11:30, 1 August 2008 (UTC)

Ditto. But, two (that I can think of) complications: "New section edit"s would get a little more complicated; and, wouldn't the various archiving bots have to monitor a number of pages for activity, then modify the "parent" (actually, that one doesn't sound so tough) Saintrain (talk) 22:31, 1 August 2008 (UTC)

There should be some consideration for moving this discussion to

well, supposing this is extermely complicated and will be a long time in coming, i think it would be a good idea to at least shift all XfD discussions to the AfD format, it is extremely frustrating to have to wade through archives when non-articles are suddenly deleted and the closing admin decided they didn't need to leave a relevant link in the deletion summary. as for a workaround:

• Go to preferences
• Click on Watchlist
• Check box marked 'Expand watchlist to show all applicable changes'

this isn't a perfect solution, but at least this way you see whether specific sections on a page have been modified -ΖαππερΝαππερ ^Babel_Alexandria 03:45, 2 August 2008 (UTC)

It wouldn't be hard to do a partial solution, but this would be highly fragile in the face of section name changes and archiving. We need a more robust solution complete forum solution in the long term. Dcoetzee 06:56, 2 August 2008 (UTC)

There was a proposal a while ago to convert other XfD processes to be like AfD, it got a lot of support, but I don't think it was ever implemented. As for a more robust forum solution, something like mw:Extension:LiquidThreads? Development is a little slow, but I think the goal is that it will eventually be used on Wikimedia projects. That would still only work on discussion pages though, it wouldn't work in sections that aren't being used for threaded discussion (sections in articles). Mr.Z-man 13:40, 2 August 2008 (UTC)

do you know where that discussion was? I wouldn't mind being bold about implementing it, so long as i had a relatively recent discussion to point people to. -ΖαππερΝαππερ ^Babel_Alexandria 14:26, 4 August 2008 (UTC)

Wikipedia:Village pump (proposals)/Archive 29#Transcludable XfD discussions. -- John Broughton (♫♫) 17:59, 4 August 2008 (UTC)

Recently a user falsely defended his wrongful deletions on the fictitious grounds that the article had no references so, as he claimed, to assure user confidence in Wikipedia articles as being trustworthy such deletions had to be made according too him. (The real reason for the deletion, BTW, was a grudge against the author.)

The problem with this argument, however, is that as a continuously open edit source Wikipedia articles are inherently untrustworthy since vandalism may occur moments before any article is downloaded or correction or update may occur moments after the article is downloaded.

To remedy this (in theory) and expose the problem I am proposing the creation of a static Wikipedia that is created once a day, week or month with only changes being looked at and deleted by administrators for the time interval selected. --iggy 10:14, 2 August 2008 (UTC)

I don't understand your proposal. Can you explain further? — Cheers, JackLee ^–talk– 12:28, 2 August 2008 (UTC)

It is essentially a proposal to end truly open editing forever, regardless of the specifics. I strongly oppose all such ventures, no matter what their intentions. Mr. IP 《Defender of Open Editing》 13:13, 2 August 2008 (UTC)

Not to end but rather to supplement in a manner where the static version contains the reviewed and approved changes for a previous time interval. Users would continue to edit the dynamic version but at the end of the time interval only the reviewed and approved changes would be included in the version that was no longer editable and static. Currently archived versions which could provide this function are currently open edit as well. (...of course I'm not really serious, however, this idea is just a spoof.) --iggy 13:37, 2 August 2008 (UTC)

Check out

Wikipedia:Flagged revisions. − Twas Now ( talk • contribs • e-mail

) 15:42, 2 August 2008 (UTC)

And Veropedia. -- John Broughton (♫♫) 17:53, 4 August 2008 (UTC)

Activating the WikiTimeLine extension on wikipedia would be a good idea I think. Its the, kind of, interactive and real-time version of easytimeline. Controlled by the reader of the article instead by the writer. You add tags to an article, if the reader clicks on such a link, an event will be added to the timeline. You can add the events you want (and so create an individual timeline), zoom in/out and move around. See the live example and more information here (just click on a few of the links at the top) and its MediaWiki page here. Its like a mix out of WikiTimeScale and the Simile Timeline. The interface is in JavaScript, so there's no heavy load put on the server since nearly everything runs client-side. Thus it can be used by heavy traffic wikis (like the wikimedia foundation wikis) too. The guys at bugzilla told me we would need to be interested here first and afterwards the admins of wikipedia could go to bugzilla/the developers of mediawiki and request the activation of the extension. Any interest in this extension for wikipedia? Please show your support here if so. ColdCase (talk) 12:25, 2 August 2008 (UTC)

Looks very interesting yes. Could you clarify what we would use it for exactly? Skomorokh 19:40, 2 August 2008 (UTC)

Of course. For example: Timeline of the dinosaurs, timeline of the roman empire, timeline of the evolution, timeline of the universe, timeline of our solarsystem, and so on. And when I'm talking about a timeline here, I mean dozens of events that can be seen parallel. And the best: You can stick them together as you like! So you can watch: Ok, when did the humans emerge compared to the existing of the earth? When were the dinousaurs? You can go from one article to the next and add the events which are listed there. So you can stick together your individual timeline. As you can see in the picture above: It's a comparison between: When did the

T-Rex exist, and when the Trilobites, compared to the existing of the earth. Its just like: Ok, I want to see that, and that, and that, compared to each other on a timeline. Its realy interesting to see that humans are only a very narrow band at the right end of the timeline compared to the whole existing of the earth ;) Even complex life itself did emerge very late in the earthly evolution... Anything that ever was history (or can be predicted for the future) can be displayed and compered to each other, no matter what topic it is. It's just like a little timeline wonderland ;) ColdCase (talk

) 01:26, 3 August 2008 (UTC)

I think it would be great. Just about every article about a topic in history would benefit. I'm not a fan of too much javascript, but this would be worth it. My only concern is that it doesn't work with older browsers. ·:· Will Beback ·:· 01:39, 3 August 2008 (UTC)

It has been successfully tested with: Internet Explorer 6, 7, 8 (as well as with the IE 5.5 engine); Firefox 2, 3; Opera mini; Opera 8, 9.5 (partially functional with 7 and 7.5); Safari 3.1, 4; Mozilla 1; Netscape Navigator 8, 9 (partially functional with 6 and 7). Should a browser not support javascript, simply nothing will be shown. If a browser doesn't support AJAX, it still works as long as you doesn't change the article/page (so you can at least add the timelines of one article). So I would say it should work for 99% of all users ;) ColdCase (talk) 12:09, 3 August 2008 (UTC)

FWIW, timelines are already used on Wikipedia using existing markup - see

There is a lot of information about timelines

in the editor's index. -- John Broughton (♫♫)

17:51, 4 August 2008 (UTC)

Please, I would appreciate if interested users would read what this extension is about before saying "there are already timelines". This extension would put the timelines on a whole other level, interactivity, and so on... please read and try it out yourself (see live example in original post). Don't just lable it with "already existing". This is not easytimeline. If it's about history, wikitimeline is million times better. On the other hand, if its about statistics, you'll need easytimeline. EasyTimeline is server side, WikiTimeline is clientside (javascript) and can do things easytimeline could only dream about ;) Its also easier to use than easytimeline (again, nothing against easytimeline, it can do things wikitimeline cannot do). So, please take just the little bit time for a live example. Again, here's the link to the live example, just click on the links in the first line ;) If you still oppose it after you'd taken your time to know what this is about: ok, no problem! ColdCase (talk) 21:56, 4 August 2008 (UTC)

So, per mw:Extension:WikiTimeLine, the extension is at version 1.0 as of July 2008. Shouldn't take much to activate it - though I'm not sure exactly what is needed. -- John Broughton (♫♫) 22:45, 4 August 2008 (UTC)

I've made a proposal to rename WP:Editor review at Wikipedia_talk:Editor_review#Renaming. Comments and ideas are welcome. MBisanz ^talk 18:48, 4 August 2008 (UTC)

(This may be a software proposal that perhaps should go into BugZilla, though at the moment I don't claim to understand the layers of software well enough to know exactly where this should go.)

There are some major problems with the way video is currently handled on Wikipedia, and I assume this extends to other Wikimedia projects:

• Video is treated like a image in articles even though the data format is not the same at all. The keyward "Image:" is used to display video files for no apparent reason.
• Wikimedia software actively transcodes images to a smaller size when an editor wants to post a thumbnail or otherwise resized image in an article. This transcoding is done to conserve bandwidth and send no more data than is required to show the image. This is done transparently for users.
• Wikimedia software does not actively transcode video and in fact does nothing at all to video when displayed with a frame size smaller than the original. If a 640x480 video is uploaded to the Commons but then displayed in an article at 128x96, it still streams to the reader at the full 640x480 bit-rate and consumes a massive amount of bandwidth unnecessarily.

It doesn't seem like video handling has been properly considered by whoever designs this software, compared to the handling for image auto-resizing.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Changes that don't require added functionality

In general I am proposing two changes here to the way video is handled, which would better deal with how video is used now:

• 1. Use "Video:" to designate all video content in wikipedia
• 2. The image thumbnail template needs to be modified to be able to recognize when video is being displayed, and to not attempt to resize the video frame to smaller than the original since it saves nothing and wastes bandwidth, and to ignore attempts by editors to display a video with a smaller frame size than the original video.

With this change in place, it will reflect the realities of working with video as it stands now. If an editor wants a smaller frame size they are going to have to:

• Download the current large video
• Transcode it on their local machine
• Upload the smaller video as a retouched version of the original (not replacing the original)
• Link to the smaller video they have uploaded, showing it at full frame size without using "100px" resizing methods

I have created an example of how these transcoded alternate video files can be linked to the original. I will be using something like this for my future video work: Image:Rhof-histWaschmaschine.ogv

Since I know that the image template is broken and that resizing of video should not be attempted, I am experimenting with my own freeform wikitable video template style that makes no attempt to resize the video, as seen in the washing machine article:

(I am also showing this example on

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Automatic video transcoding

A much more extensive change to functionality is that the Wikimedia software should add a capability to transcode video into smaller frame sizes and lower bit-rates automagically without any further input from the user, just as it already does resizing for image users.

There is no defined method for doing this so it would have to be created. Image templates can already use "100px" to designate a width. Something similar should be possible for video, perhaps with an additional "kbit" designation:

[[Video:Example.ogg|200px|200kbit|thumb|Example video shown at 200 pixels wide and 200 kilobits maximum streaming rate.]]

DMahalko (talk) 14:09, 27 July 2008 (UTC)

How to handle the time needed to transcode?

A potential problem here has to do with the time and processing power required to transcode video. It takes me about two minutes to transcode a one minute video clip.

Wikimedia transcodes images live and on the fly since the data volume to be transcoded is small. Doing on the fly video transcoding may not work, especially since there may become a backlog of video to transcode as thousands of people add and edit video in articles.

Also it seems possible for the transcode queue to be subject to abuse since it does take a certain finite amount of time to transcode a video file. A vandal could queue up hundreds of transcodes, each with sligtly varying transcode parameters, and fully block transcoding for anyone else.

Capping transcodes to a certain number per day doesn't seem like a good option since a vandal can just keep overflowing the limit each day. I do not know of a good way to handle video transcoding issues and dealing with potential system vandalism.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

How to handle the storage needed for transcodes?

A second issue has to do with storage. Apparently wikipedia transparently stores resized images in a cache so they don't need to be recoded again when viewed by thousands of people in an article. Presumably if wikimedia did its own transcoding of videos, these too would have to be cached, and the space used by these transcodes is not trivial.

Here too I have concerns about vandalism since a vandal could generate many transcodes of a 20 meg video which end up consuming hundreds of megs of Wikimedia storage.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Maintaining status quo

If automatic transcoding is not used then we are stuck with the current system, where each user is left to their own devices to muddle through using a local transcoder on their own computer and uploading each size variant of the same video.

There are no guidelines for what bandwidth rates should be used for transcoding or for frame resizing, and so the results of transcodes created by each user are already highly nonuniform and inconsistent from one video to the next.

I am trying to make a stab at finding consistent methods here:

The annoyance factor for local transcoding seems to be a limit on vandalism abuse, though I don't see anything that prevents a vandal from uploading hundreds of recodes of the same video and wasting wikimedia storage space that way, too.

Overall I just don't see a good way to handle this, but something should be done to make it easier to use video in articles.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Interesting. I didn't realize Wiki(media) supported video formats. I guess a solution is to offer several (standardized) sizes of a video, maybe in steps of powers of two (e.g., 128x128px, 256x256px, 512x512px, etc.), except sized to fit the more common 4:3 aspect ratio. They could either be, a) uploaded by the editor or, b) created automatcally by the server. The actually displayed video would then be chosen from among these possibilities and squeezed into whatever size is specified in the article itself. I would suggest reducing the number of possibile sizes to a finite (low) number. Making this value finite and basing the scheme on powers of two (or powers of some other number) ensures that minimal amounts of local disk space are wasted on very large files.

talk

) 18:08, 27 July 2008 (UTC)

I always thought the reason we didn't have that much video was because of some conspiracy from "Big Brother" to reduce Wikipedia's already very large bandwith. Hence I always though there was some sort of unwritten rule that we try and keep this fact a secret. Maybe, instead discussing this here, there you could consider a better venue. Have you looked into wikipedia to see what type of documentation already exist regarding the uploading of media files (images)... ogg files... etc? (Try gathering up as much information on this) I remember looking into, but getting a couple road blocks primarilly from the "upload" mecanism. Instead of what now appears to attempt to denny the fact we can upload video's why not simply have a section which actually deals with it. I think this proposal brings up a valid question. First off, 1) it's difficult to format an OGG file (or at least the last time I tried it was) 2) It's hard to figure what are the specs we should use. So again, instead of ignoring the problem I think we should look into this issue a little further. Elaborate a plan that deals with videos. Which ones should be kept, which one deleted. The maximum size. Etc. Maybe it's time to start

I would even recommend adding mecanisms to prevent "new" users to upload videos. And add a security code feature; like some random letters. Or a maximum upload ratio for video of maybe 3 videos per IP range (that covers Sockpuppets that try to upload more) --CyclePat (talk) 06:05, 29 July 2008 (UTC)

We find using a codec that is so obscure that currently no one outside hard core free content enthusiasts knows about it and how to transcode into it keeps uploads under control. The reason our video handeling is fairly poor compared to our image handleing is that for images it was mostly a matter of building ImageMagick and RSVG into mediawiki. However at the moment support for Theora is somewhat lower (which is why a lot of us who upload videos still use command line based ffmpeg2theora in order to do it). Cortado (software) is better than nothing but it is still fairly basic. There is however going to be at least some work to improve this. See here.Geni 15:43, 29 July 2008 (UTC)

So transcoding to produce multiple bitrates is a long term goal for MediaWiki. However because video recoding is so CPU expensive (compared to resizing a single image) it needs a lot of special systems/mediawiki infrastructure that no one has created yet. It will come eventually, however. As far as bandwidth goes... Video really not a problem today, in fact there are a number of complicated reasons why it would be very good for Wikimedia to have a lot more video traffic.

As far as creating Ogg files, there is pretty good tutorial on commons, improvements welcome.

For now we can do what we did before mediawiki supported thumbnailing images: We can encourage people to upload high-res and we can manually make lower quality thumbnails. It wouldn't be hard for someone to setup a bot doing this. Not ideal, but not the end of the world either. It would probably be useful to make a set of recommended bitrates and resolutions for manually generated thumbnails... I don't believe anyone has done that yet.

People interested in this subject may also be interested in this list post. --Gmaxwell (talk) 00:02, 31 July 2008 (UTC)

So, you are saying that users are being encouraged to upload high-res versions of videos? For some reason I expected otherwise.

talk

) 01:33, 1 August 2008 (UTC)

There is a 20 megabyte file size limit for all file uploads to Wikipedia and the Commons, so the choice for an uploader is high resolution but only for a few seconds, or a small low-quality low-res movie running for minutes. That seems to be enough of a usage limiter alone. DMahalko (talk) 13:42, 5 August 2008 (UTC)

Let's face it, flagged revisions will not be implemented on the English Wikipedia because of lack of consensus. (At least I'll be very surprised if it is.) And maybe that's a good thing, it's impossible to tell now, there's a lot of convincing arguments on both sides.

My proposal is to make flagged revisions available for certain pages.

To keep things simple, I would recommend against making a new user group, and would give the new rights to rollbackers, admins, etc..., but I am open to a new user group if consensus goes that way.

This proposal has a much better chance of gaining consensus, I believe, and would also allow us to see flagged revisions in action in a non intrusive way. If it turns out to be really helpful and is implemented on a lot of articles, people would be more open to the full flagged revisions. If it doesn't, then we can just go back to the status-quo.

Please let me know what you think. Jkasd 07:05, 30 July 2008 (UTC)

Hmm, I just brainstormed up an idea: what about some kind of poll of anonymous readers/editors? Since flagged revisions, as currently proposed, won't affect logged-in users at all, it makes sense to seek input from the people it will affect. We could stick a link in

sample bias). A simple click-and-submit poll might be better; maybe the devs can hack up Special:Boardvote, or something could be put up on the toolserver. --Slowking Man (talk

) 10:05, 30 July 2008 (UTC)

I don't think that's a good idea; such a system is probably gameable. {{Nihiltres|talk|log}} 11:47, 30 July 2008 (UTC)

It's probably even more 'gameable' to have a discussion about a feature that affects only anon users and then basically not tell them about it. --VectorPotential Talk 11:53, 30 July 2008 (UTC)

It will affect logged in users - their changes will not be immediately visible. Hut 8.5 20:14, 1 August 2008 (UTC)

Well, personally I think flagged revisions should be enabled with the only real effect (i.e. what anons see) being for those "flagged-protected" pages, so this sounds like a great idea. Adding the basic support for flagging of a) featured articles (just as markers, give ability to set to admins +perhaps a new usergroup) and b) clean of vandalism (just as markers, give to either rollbackers or a new group, and admins) would be a bonus that wouldn't have much effect on what anons see but would be useful to the community. {{Nihiltres|talk|log}} 11:47, 30 July 2008 (UTC)

Yes, I'm prepared to support this. Maybe we could enable it for all articles, but make unregistered users see the newest version unless an admin sets the page otherwise (in a way similar to this proposal). Hut 8.5 20:14, 1 August 2008 (UTC)

I'm an extremist opponent of universal flagged revisions, but I could almost get behind this. With luck, it would permanently establish FR as an option only for Wikipedia's most troubled pages, preventing the insidious idea of FR from creeping its way all over the rest of the project. What I would like to see is an established hierarchy of "emergency page status" measures that admins could employ for troubled pages - a unified system with several classes of page protection, in which FR would be one of the options. In fact, I would like to see full protection deprecated entirely, and possibly replaced with FR. Semi-protection would remain in place, but full protection would be replaced by "flagged revision status" where the default is set to the most recent flagged edit. Mr. IP 《Defender of Open Editing》 14:19, 2 August 2008 (UTC)

I'm quite a skeptic too, but I agree it seems reasonable to make a trial. We can each continue to guess indefinitely what the effect would be, but we won't be the wiser for it. I think it may have been suggested elsewhere to start with BLPs generally. That seems broad, but I'd support it to take the pressure off making yet more drastic limits on BLPs that would really impair the principle of NPOV. We could start with certain definable classes, like politicians currently running for office. DGG (talk) 05:39, 3 August 2008 (UTC)

What should I do from here, should I post a request at bugzilla? Jkasd 04:20, 5 August 2008 (UTC)

Yes, a general request at Bugzilla would be a good idea, though I personally hope that this discussion gets more eyes to improve its chances of implementation. {{Nihiltres|talk|log}} 13:45, 5 August 2008 (UTC)

This has been discussed for a long time at

Yes, the seed for this idea came from this discussion WT:Flagged revisions#Split proposals, where it seemed hopeful, but nothing seemed to come of it. I've refined the idea, and I thought it would be better to discuss it here instead. Jkasd 21:05, 5 August 2008 (UTC)

It would be nice if these would be in Friendly, so we can place it there better.

Well, if you want to add those templates to Friendly, you can tell

[talk]

21:36, 2 August 2008 (UTC)

I have tried to contact him, but no luck...

csdnew

11:39, 5 August 2008 (UTC)

bob dylan's real birth date is not may 24, it's may 11. this is how it appears in his id, which appears in the booklet of the bootleg series vol 1-3. and i don't think he uses a fake id. you should look for yourself. —Preceding unsigned comment added by Alexadamalex (talk • contribs)

A Google search [3] finds plenty of sources saying May 24. Talk:Bob Dylan would be a better place to suggest changes to the article. PrimeHunter (talk) 22:44, 6 August 2008 (UTC)

Sometimes a registered user forgets to log in when editing. The result is that the registered user's IP address is displayed in the history instead of the user name. I propose that when people who aren't logged in submit an edit, they should receive the prompt, "Would you like to log in before submitting your edit?" The possible choices would be "yes" or "no thank you". --Bob K31416 (talk) 17:34, 17 July 2008 (UTC)

I would agree with this suggestion and add the following problem that has happened to me. I was reviewing my watch list (which implies one is logged in) but when clicking on an entry to open it in a new window, that new window was not logged in. This does not happen very often, but results in an IP edit when you think that you were actually logged in. Dbiel ^(Talk) 18:36, 17 July 2008 (UTC)

• Comment: I really like this idea. This has almost happened a couple of times, and I wish that the Wikimedia software would ask if you wanted to log in when you begin to edit a page. It currently displays an unobtrusive notice at the top of the edit page when you are not logged in that isn't really noticeable. Perhaps that notice could be changed to be displayed in an {{ambox}} with a little log-in specific picture. That would be easier to implement than a log-in prompt during the page save. — OranL (talk) 19:13, 17 July 2008 (UTC)

• The {{ambox}} suggestion sounds like a very good idea and would be consistant with the current standardization of notices. Dbiel ^(Talk) 19:25, 17 July 2008 (UTC)

I strongly support this idea, mainly because it's happened to me too, and there is no prominent visual indicator that alerts users they are not logged in. --

:.

19:27, 17 July 2008 (UTC)

This sounds like a good idea. In the meantime, users could shove something in their custom .css files so that the appearance of the edit page when they're logged in is distinctive - bright purple background or something. This would make the difference more obvious. Pseudomonas_(talk) 19:29, 17 July 2008 (UTC)

Question: Would it be possible to have the prompt stop after the first time one clicks on "No thank you" for that particular article/session? I would imagine IP editors becoming quite frustrated if they had to face that prompt every time they made an edit. Zain Ebrahim (talk) 19:33, 17 July 2008 (UTC)

I was thinking of a global notice like

:.

19:34, 17 July 2008 (UTC)

About 30% of our edits come from anonymous users. Do we really want to hit them with popup messages every time they try to edit? --Carnildo (talk) 19:40, 17 July 2008 (UTC)

Seeing as login information can be stored on a computer, so when it detects your IP or whatever it automatically appears in the box, maybe we could make it so it detects you are possibly a registered user and causes the box to appear then? --

:.

19:44, 17 July 2008 (UTC)

The problem with this is that there are a lot of users that do not have a static IP address and the IP address may change every time the connect to Wikipedia. But a session cookie might be a possibility.

Here are a couple ideas:

• This one looks like a warning:

You are not currently logged in. Editing this way will cause your IP address to be recorded publicly in this page's edit history. If you create an account, you can conceal your IP address and be provided with many other benefits. Messages sent to your IP can be viewed on your talk page.

• This one looks like a notice:

You are not currently logged in. Editing this way will cause your IP address to be recorded publicly in this page's edit history. If you create an account, you can conceal your IP address and be provided with many other benefits. Messages sent to your IP can be viewed on your talk page.

• Both are more noticeable than:
  

You are not currently logged in. Editing this way will cause your IP address to be recorded publicly in this page's edit history. If you create an account, you can conceal your IP address and be provided with many other benefits. Messages sent to your IP can be viewed on your talk page.

Props to .:Alex:. for the text that I used from his page. — OranL (talk) 20:17, 17 July 2008 (UTC)

Though it should say something about creating an account if you don't already have one... Mr.Z-man 22:57, 17 July 2008 (UTC)

I thought the point was that this should only be seen by editors who normally have an account.

In any case, I find using ambox a very bad idea; the particular series of templates is associated with problems in articles, and the nature of these messages is mostly of temporary issues concerning pages in the mainspace. If you want a format more suitable to general use, I highly suggest {{ombox}}. Waltham, The Duke of 23:27, 17 July 2008 (UTC)

I don't think its possible to display it to only users who have an account but are not logged in without displaying it to all anon users. Mr.Z-man 23:59, 17 July 2008 (UTC)

I changed the template to use {{ombox}} and the text of the current logged-out message. View it above and comment. Feel free to edit the template or the text. — OranL (talk) 03:01, 18 July 2008 (UTC)

_________________________________________________________________
Thank you all for your responses. I appreciate the consideration you've given to my proposal. It looks like I should give a more detailed explanation to clear up some things.

The proposed prompt is for all users that aren't logged in when they submit their edit. This includes both registered and non-registered users. Both are included because I don't see a way to easily differentiate registered from non-registered users.

The prompt does not come up when they begin to edit. It only comes up when they submit their edit. This choice was proposed because someone may only wish to view the edit page without submitting an edit and the prompt would be unnecessary in this case.

Since the users that will view the prompt includes users that are not registered and new to Wikipedia editing, I tried to make the language as simple and friendly as possible so as not to discourage them from editing. The prompt was,

Would you like to log in before submitting your edit?

and the choices to click on were meant to be as simple and friendly as possible too,

<yes>          <no thank you>

--Bob K31416 (talk) 03:16, 18 July 2008 (UTC)
___________________________________________________________________

Actually, there is an easy way to differentiate between registered and unregistered users. When you log in, a cookie is created. When you log out, the cookie saves your username so that you only have to type your password the next time you log in. So I suppose the software could be programmed to detect cookies when the user is logged out and prompt them to log in. This would work as long as the user uses the same computer and the cookies are not deleted. –

9

04:00, 18 July 2008 (UTC)

As I said, I was thinking something like this in terms of style. Noticable enough as it's not seen usually on the page, but blends in for any IPs that see it.

--
:. 08:37, 18 July 2008 (UTC)

This looks good but I am still opposed to the idea of a prompt each time an edit is submitted. Zain Ebrahim (talk) 09:51, 18 July 2008 (UTC)

I see the advantages of this idea. It doesn't require any action and is thus unobtrusive. It should be positioned just below the "save page" button. It would only appear if the editor was not logged in. That way a registered user is likely to realise, "Something's different here!" It would be of no consequence to an unregistered user. So I agree with the idea and would only suggest changes in the wording of the reminder to make it simpler and softer,

If you would like to log in before submitting your edit, click here.

An additional feature may be helpful. After the user logs in, there could be a button to click to get back to where the user was on the edit page, but this time as a logged in user. However, since this isn't already a feature during routine Log in, I suspect it is difficult to implement.

--Bob K31416 (talk) 14:48, 18 July 2008 (UTC)

If you commonly have trouble with this and you don't want to wait for the devs, something like this in your monobook.css (or other skin css file) might be helpful.

/* Turn the "Save page" button green if I'm logged in */
INPUT#wpSave {
    background-color:#88ff88;
}

It will turn the "Save page" button green when you are logged into your account. If the button isn't green, it means you're not logged in (so don't click it!). Anomie⚔ 11:25, 18 July 2008 (UTC)

Clever and simple solution! I like it. I'm using it myself now, although with different colours and whatnot. --_{tiny plastic} Grey Knight ⊖ 12:13, 18 July 2008 (UTC)

A great idea, except it doesn't work for me. At all. Any code whatsoever never ever works on my monobook.css or monobook.js or whatever. Anyone why that is? --

:.

13:04, 18 July 2008 (UTC)

Are you using the Monobook skin? If you're not, you'll have to use the .js or .css page for that skin. Occasionally when I need to stir things up I'll use the Modern skin, and so for when I do that my modern.js contains importScript('User:Nihiltres/monobook.js');. {{Nihiltres|talk|log}} 13:29, 18 July 2008 (UTC)

Oh, it's decided to start working, but when I AM logged in. Why is this? Hmm... --

:.

08:43, 20 July 2008 (UTC)

Did you forget to clear your cache after making the change yesterday? Anomie⚔ 13:51, 20 July 2008 (UTC)

I purged the cache and it had no effect. --

:.

16:30, 20 July 2008 (UTC)

Your monobook.css modifications can only affect your personal user account. It cannot, for instance, make the button red if you aren't logged in. — OranL (talk) 18:32, 20 July 2008 (UTC)

And as OranL has said above, that is the point of using the monobook.css. Using the example given above, the save button would be green when logged in, but grey if not logged it. It was my first monobook entry. The green button took me a little while to get use to, but it does make it apparent by its absence that I am not logged in; and thus a reminder to log in before clicking on the grey save button. Dbiel ^(Talk) 18:57, 20 July 2008 (UTC)

Oh I see. I misread it. I thought the green would appear when not logged in (don't know how that would even be possible in a userscript). My bad. --

:.

20:59, 20 July 2008 (UTC)

I like this proposal a lot. It would give all of us a better idea of who the noobs are around here, instead of having established users' contribs diverted to IPs. --Pwnage8 (talk) 18:46, 20 July 2008 (UTC)

I think this green button thing should be incorporated as a gadget actually. --

:.

15:23, 22 July 2008 (UTC)

I strongly oppose this proposal. While I understand the good intentions behind it, this polidy would presume that IP editing is some sort of mistake, rather than an intention, or the majority mode of editing Wikipedia. It would also introduce a further step of annoyance into IP editing, and we have done far too much to IP editors already. It is also yet another step toward the gradual elimination of IP editing, even possibly delivering "warnings" to IP editors that look suspiciously similar to the warnings delivered to vandals. I must oppose in the strongest possible terms. Mr. IP (talk) 08:58, 26 July 2008 (UTC)

• Comment I think all it would take is for the skin to be a different color for logged in editors than for IP editors. Heck, even if the lines surrounding the edit window that I'm typing in now were a different color it would alert me that I'm not logged in. Phlegm Rooster (talk) 09:19, 26 July 2008 (UTC)
  • Well said, Rooster. Well actually my skin is very different from that when I'm not logged in, and deliberately so. However, it's not different enough. The edit window for IPs could be green or pink or blue or whatever Mr IP would consider pretty. -- Hoary (talk) 09:26, 26 July 2008 (UTC)
    • I strongly support this suggestion. It solves the problem without stigmatizing IP editing or introducing new pains in the neck for anyone editing from an IP. Implementing it could be a solid quality-of-life improvement for Wikipedia.  Mr. IP, Defender of Open Editing  15:17, 27 July 2008 (UTC)

    If you want to change the edit window, just apply CSS to #wpTextbox1 as I suggested above for the save button. You could also throw in #wpSummary to do the same for the edit summary box. Something like this:

#wpTextbox1, #wpSummary {
    border-color:#0f0; /* Give it a green border */
    background-color:#cfc; /* Give it a light green background */
}

• • Sure, you could try to get the devs to somehow change colors and such for non-logged-in editors. Or you could do this right now, the only difference being the "standard" appearance means you need to go log in. And this way you can make it as obvious or non-obvious as you want; I think I'll stick with just a green Save button, but you can turn the entire page

    Magic Pink if it concerns you that much. Anomie⚔

    20:45, 26 July 2008 (UTC)

________________________________________________________________________________________

<Save page>    <Show preview>    <Show changes>

If you would like to log in before submitting your edit, click here.

________________________________________________________________________________________

It would only appear if the editor was not logged in. That way a registered user is likely to realise, "Something's different here!" It would be of no consequence to an unregistered user.

Note that a similar statement already appears when a user is not logged in. The problem is that it appears at the top of the page, away from the "Save page" button and is thus not noticed when the user goes to save the edit.
-Bob K31416 (talk) 13:07, 26 July 2008 (UTC)

Then we should replace the old notice with the new one. Who is in favour of that idea? --Pwnage8 (talk) 15:47, 4 August 2008 (UTC)

Thank you for your input. I think that the old notice is fine. It gives some useful details and may alert some editors, when they start editing, that they have the option to log in so that they can log in before they start to edit. Other editors may not even notice the present message and just go directly to the edit box and start their editing. What I feel is needed is the short notice in the blue box, previously mentioned, that is near the "Save page" button. Because of it's close proximity to the "Save page" button, it has a good chance of getting an editor's attention and the info in the box will remind the editor of the option to log in. --Bob K31416 (talk) 20:22, 7 August 2008 (UTC)

I strongly support a strong visual difference between editing logged and logged out.

Wikipedia:Notability (Septuagenarian female plumbers with red hair and freckles) has been proposed as a further but necessary extension of the notability infrastructure. As this infrastructure of subject specific notability guidelines grows, we must keep pace with the need to define every permutation of expectations at AfD and prevent the dangerous application of independent thought. Not only must we determine consensus on this critical issue immediately, but we must also hasten to define every possible situation which may tax the good judgment of our AfD closers. --Kevin Murray (talk) 14:58, 5 August 2008 (UTC)

• This doesn't appear to be a serious proposal. ·:· Will Beback ·:· 15:10, 5 August 2008 (UTC)
  • Will, you are perceptive on the surface, but the deeper message of this parody is very serious. There are roughly ten current proposals for subject specific notability guidelines and the rate of proposal far exceeds the rate of disposition. There are two problems here: (1) people have lost confidence in WP:N and (2) we run the risk of further ballooning our rule sets into a morass. --Kevin Murray (talk) 15:16, 5 August 2008 (UTC)
    • WP:N-related proposals, adding another one doesn't help move the discussion forward, in my opinion. -- John Broughton (♫♫)
      15:36, 5 August 2008 (UTC)
      • true, but it's a short, funny read. actually, the talk page is the best part. -ΖαππερΝαππερ ^Babel_Alexandria 14:21, 6 August 2008 (UTC)

This discussion of a humorous page does not belong here. --Boring old (fart) 12:25, 7 August 2008 (UTC)

Only the format is humorous -- the message could not be more serious! We are being overwhelmed by narrowly-defined, conflicting, and redundant rule-sets. With the best of intentions, people are proposing more and more rules each month and then a short time later claiming consensus for acceptance based on agreements between just a few editors. See the proposals for notability guidelines listed at the

template:IncGuide. --Kevin Murray (talk

) 15:59, 7 August 2008 (UTC)

I have to admit that this mock proposal is one of the most cogent

points I've ever seen made.--Father Goose (talk

) 20:17, 7 August 2008 (UTC)

We already have an essay that does what you are complaining about: it's called

WP:POINT. If you think there are too many policies then say so and give specific ones, but don't make a point. Deamon138 (talk

) 22:29, 7 August 2008 (UTC)

It is in the left sidebar under Toolbox > Printable version. --—— Gadget850 (Ed) ^talk - 19:52, 6 August 2008 (UTC)

Any half-decent modern browser will automatically use the printer-friendly version anyway. We have a print stylesheet on every page which excludes all the extraneous stuff. If you're using Internet Explorer 6 or 7, or any version of Firefox, it certainly shouldn't be printing the navigation or edit links. — Matt Eason ^{(Talk &#149; Contribs)} 20:43, 7 August 2008 (UTC)

Just a quick note to invite comment here on a proposal to create a new criterion for speedy deletion. The proposed criterion is that where an uploader has supplied a copyright tag but has specified a third party as the content owner, without any evidence that their permission was ever given, the media will be speedied seven days after the uploader is notified if no such permission is forthcoming. This is equivalent to the NPD process used at Commons, and parallel to our NSD and NLD. Please weigh in! --Rlandmann (talk) 21:01, 7 August 2008 (UTC)

I'm sure this must have been proposed before, but could we get a little marker to sit in the top right corner of articles that have been awarded GA status? Just like how we currently have for FAs. The German Wikipedia has a little blue square containing a letter L (for Lesenswerte Artikel; article worth reading), which works quite nicely. An example can be found here: de:Nordsee. Perhaps we could use the GA symbol for the English Wikipedia? - Anxietycello (talk) 00:57, 8 August 2008 (UTC)

Well, you're right. This has been proposed again and again, and it is always shot down. It's a slippery slope. If we have FA's and GA's marked, why not A-class? Is it against

NPOV to only advertise our better articles? Why not B-class, or starts, or stubs? Also, being a Good Article is determined by one reviewer, while FA's are determined by community consensus. It isn't a terrible idea, it would just be impossible to get a clear consensus to act on it. Paragon12321 (talk

) 02:15, 8 August 2008 (UTC)

Fair enough, that's kinda the answer I expected. Shame really, seems (to me at least) like it'd be a useful feature. Should this be put on

WP:PEREN if it's suggested that often? Anxietycello (talk

) 02:30, 8 August 2008 (UTC)

You can enable such a feature for your own use, however. Go into My Preferences → Gadgets. Under "User interface gadgets" there's a box to tick to "Display an assessment of an article's quality as part of the page header for each article". As for the perennial proposal, you might be interested in reading the last "Green Dot Debate". Gwinva (talk) 02:54, 8 August 2008 (UTC)

Yes, this needs to be added to

WP:PEREN; I suggested it last time, and a record of the gazillion times this proposal has been defeated should be included there. SandyGeorgia (Talk

) 02:58, 8 August 2008 (UTC)

I added it. Please adjust it as you see fit.

masterka

06:30, 8 August 2008 (UTC)

See: Wikipedia:WikiProject Council/Directory/Wikipedia

Julie Dancer (talk) 05:46, 30 July 2008 (UTC)

I'm sure your intentions were good, but I think this actually makes things more arbitrary. A "value judgement" is still needed to, for example, decide whether or not to increment the "Do not game the system" column; was the user really doing so? This is the same as the current setup. However, the difference with this would be that it removes any context; when was the value incremented? Was it a long time ago? Did the user subsequently apologise? What is the relationship of the incrementing user; were they involved in the incident? There is all sorts of context that should be taken into account in order to more fairly evaluate users' activities; and the same goes for articles. This is similar to the concept that Wikipedia:Polling is not a substitute for discussion. Sorry! --_{tiny plastic} Grey Knight ⊖ 10:27, 30 July 2008 (UTC)

There is nothing wrong with prior discussion to help a user or administrator decide whether to enter a negative or a positive value following the discussion. The only difference is that the table affords a current status summary following each discussion on the discussion page rather than the table replacing any discussion. Think veggiesaurous, Lex, veggiesaurous! Julie Dancer (talk) 14:17, 30 July 2008 (UTC)

This is definitely

creepy. Problem articles/users should be dealt with on a case by case basis, rather than introducing something like this. It seems unnecessarily complicated and overly devoted to a "by the numbers" approach. I do not like it. Shereth

15:27, 30 July 2008 (UTC)

I think of it like grades in school more than anything else. The current system means that all of the sudden out of the clear blue sky all another user with a grudge has to do is to put a borderline article up for deletion. They know that all they have to do next to send it over the edge is to drop a few claims that the reaction of the original author is a personal attack or that the original author is being uncivil, knowing all the while that if they drive that interpretation home the article will be deleted and the author blocked. Such nominations might be more difficult if compliance history could be pointed to which would show that personal attack or incivility is a wrongful interpretation of the reaction. Most importantly it would stop articles from being nominated for deletion out of the clear blue sky. The original author deserves some warning that there might be something about the article, such as notability, which a history of status would eventually tend to reveal. The instructables uses a rating system that is very helpful in that regard, the only difference being that here it would be applied to every policy regarding article and user status. Think veggiesaurous, Lex, veggiesaurous! Julie Dancer (talk) 16:15, 30 July 2008 (UTC)

(ec) We already have the ability to do that. Talk pages are very rarely deleted, so there is no point in trying to misrepresent a past discussion; a simple link to the talk page and the accuser's position is immediately undermined by the primary source of the conversation itself. You seem to be proposing replacing this with a secondary source, and one that removes any kind of context at that. We can't reduce questions of policy compliance to raw numbers, it's too subjective. And for that matter we're allowed to disobey the rules if it helps the encyclopaedia! --_{tiny plastic} Grey Knight ⊖ 16:29, 30 July 2008 (UTC)

Think summary Lex. You get done with a discussion as an administrator on your own talk page perhaps and return to the article discussion page or user discussion page and want to indicate your thoughts without further ado. You say yeah they were not being uncivil, enter a negative amount and you are out a there ta-da (tä dä′) (Informally used to suggest the sound of a fanfare: an exclamation of triumph or pride accompanying an announcement, a bow, etc.) Julie Dancer (talk) 16:35, 30 July 2008 (UTC)

My name isn't Lex (at least, not here). I understand what your proposal is, I just don't see why it is any improvement over just saying "I do not think such-and-such a comment was uncivil", which conveys all of the information incrementing your table would, as well as more conveniently displays the attribution of who said it, and allowing to talk about individual issues rather than lumping everything the subject user has ever done into one pile (which sounds like a recipe for huge arguments). --_{tiny plastic} Grey Knight ⊖ 17:02, 30 July 2008 (UTC)

I still think you are overcomplicating the matter. If an article has potential notability issues then it should be tagged as such. If it has potential verifiability issues, it should be tagged as such. If these issues are particularly egregious, it goes instead to AfD. This notion of a scorecard over time is far too much. The task of "scoring" articles and editors is far too onerous, particularly when we have a system that works by and large. Shereth 16:27, 30 July 2008 (UTC)

That would be okay if a nomination for deletion tag for any reason for which there is an existing tag like notability or references then that tag should have forced or obligatory precedence over the nomination for deletion tag. See what I am trying to say? Julie Dancer (talk) 16:38, 30 July 2008 (UTC)

A rather

labyrinthine statement, but I think you are saying that people should put cleanup tags on rather than going straight to a deletion tag. This is already considered polite to do, although it is not required. What we are trying to say is that having cleanup tags and a "scorecard" table stating how many cleanup tags there are seems like duplication of effort to no real benefit. The table is not even as helpful as it doesn't indicate what the cleanup problems are. (In fact, even a cleanup tag should be accompanied by a talk-page explanation, although at least its positioning can give some clues.) --_{tiny plastic} Grey Knight ⊖

17:02, 30 July 2008 (UTC)

The difference between an article needing cleanup tags and one warranting deletion debate is not well-set and is open to interpretation. That is the whole purpose of the discussion itself - to determine whether or not an article should be deleted or whether it is salvageable. Shereth 17:31, 30 July 2008 (UTC)

My impression now is that no one wants to edit anything and if editing requires the least bit of work someone will nominate for deletion instead of even posting a reference tag. The idea seems to be if there is no reference section forget it. That means there are no inline references (although the article could be chocked full of hyperlinks) and have you ever seen one of the reference sections, I mean all the detail? Dang! stick a nomination for deletion tag on it and lets get out a here. Julie Dancer (talk) 13:24, 31 July 2008 (UTC)

I wouldn't trust such a system unless it could be done programatically, which is not even close to being the case.

talk

) 01:29, 1 August 2008 (UTC)

I agree. I would go along with it if were it automated and the results of automation were accurate and true to purpose.

This would turn Wikipedia into a police state. --Pwnage8 (talk) 08:30, 6 August 2008 (UTC)

As others have pointed out, this is far too arbitrary to be useful. We already have things in place to deal with all of the issues in your chart. If something has potential problems with notability, then it gets tagged. If it has potential problems with verifiability, then it gets tagged. If it has especially egregious problems that someone thinks can't be fixed through the regular editing process, then the article can be taken to AfD. Talk pages are wonderful things, and can be used to solve a lot of these problems that you've put forth.

I'm even more strongly opposed to the idea of grading users. This isn't school; there isn't any goal of creating users who are good at doing everything that they get graded on; everyone here does their best, and when their best isn't good enough for our standards, someone else comes along and picks up the slack. The benefit of having any kind of thing that says "User A sucks at writing NPOV-style biographies" is minimal compared to the damage that it does to our cohesion and morale. Whenever you implement any kind of scale, people are going to see it as a contest, which Wikipedia is not. Celarnor ^{Talk to me} 12:19, 8 August 2008 (UTC)

Alternate user names have a bad reputation because they were used originally and extensively by vandals and by users wanting to have apparent extra support of their position. The question of legitimate alternate user name under one Wikipedia account has already been addressed by requiring an additional account for a user's wiki bot. In my case the need for multiple user names is not for wiki bots but to track my own projects which are on separate computers. What I am proposing is that multiple accounts be in fact permitted just as they are for user bots giving each account the same user name followed by a sequence number. In my case the would amount to three accounts, for example Charlie-1, Charlie-2 and Charlie-3. I need these accounts to track and to separate each of the projects I am working on. Without such capability I may as well have no user name at all.—Preceding unsigned comment added by 71.100.0.179 (talk • contribs)

Erm, you don't have a username at all, unless you count your IP address... Alternate accounts may have a bad reputation, but they certainly aren't disallowed in all cases except for bots as you seem to suggest. I would suggest reading over the

multiple account policy. I believe what you're proposing is already allowed. Mr.Z-man

06:51, 3 August 2008 (UTC)

See

WP:ANI#User:Julie Dancer, repeated personal attack and harrassment for the full background here. Kevin (talk

) 09:22, 3 August 2008 (UTC)

There was no personal attack but only statement of fact. Unfortunately Wikipedia policy allows Communists to be administrators as well. Check your self Kevin and the user you claim that was harassed and you will find that your block and the nomination for deletion and the reason behind it was in truth a personal attack of actions rather than of words. 12:13, 5 August 2008 —Preceding unsigned comment added by 71.100.0.126 (talk • contribs)

Yes, Wikipedia policy allows Communists - and socialists, and anarchists, and atheists, and pagans, and pretty much anyone regardless of political or religious or other personal aspects - to be administrators. So I strongly suggest you

find another website where the rules are more to your liking. -- John Broughton (♫♫)

12:41, 5 August 2008 (UTC)

Why is that unfortunate? Celarnor ^{Talk to me} 12:24, 8 August 2008 (UTC)

Proposed addition

"phake" as in computer made ph(otographic f)ake image.

It is quite common to find software generated photo montage or enhanced images. Sometimes these are obvious sometimes not however they are all phakes.

Real Samson (talk) 08:46, 7 August 2008 (UTC)

I don't think the term is notable enough to deserve its own article, nor even to deserve mention at

Photo manipulation#Photoshopping. Sorry. − Twas Now ( talk • contribs • e-mail

) 11:31, 7 August 2008 (UTC)

I suggest you submit it to the Urban Dictionary. --Slashme (talk) 12:12, 7 August 2008 (UTC)

Jokes site. Already definitions for phake, but not this particular one yet. Should make a great addition. And it's referred to as "urban dictionary", just FTR. --Pwnage8 (talk) 19:04, 8 August 2008 (UTC)

hello my names Kari I have an account with you guys. and I was curious, if you have though about improving account settings? I would really like to be able to save some certain articles so i could go back to them later... some what like youtube does with their videos, where you can put that as a favorite and find it on your home page.

If you are logged in you can "watch" an article by clicking the tab at the top that says "Watch". Then, if you click "my watchlist", located at the top of the page next to your account name, you can see all of the articles that you are watching, much like a favorites list. Shereth 15:12, 8 August 2008 (UTC)

And, of course, there isn't anything preventing you from setting up a "Wikipedia articles" folder within your web browser's bookmarks menu, so you can bookmark them. Or even setting up a user

subpage (if you've created an account - free!) where you add the articles to the subpage. (Then you can easily add notes, group them however you want, etc.) -- John Broughton (♫♫)

15:51, 8 August 2008 (UTC)

With rev:38730, it's now possible to change the pagetitle of the Main Page. It's currently "Main Page - Wikipedia, the free encyclopedia". Does anyone think it should be changed, and if so, to what? Perhaps removing "Main Page - "? --MZMcBride (talk) 00:03, 9 August 2008 (UTC)

I've set it to simply "Wikipedia, the free encyclopedia". This should make it easier to bookmark Wikipedia, since the bookmark will by default start with "Wikipedia" instead of "Main Page". It should also be a bit more intuitive to newcomers. Any other thoughts on this? —Remember the dot ^(talk) 00:54, 9 August 2008 (UTC)

This seems to be a similar discussion to what's going on at Wikipedia:Village_pump_(technical)#Proposal:_Move_main_page_to_a_different_namespace. Deamon138 (talk) 01:04, 9 August 2008 (UTC)

The new functionality was created in concert that proposal (see the feature request at bugzilla) and I support the change of the page title to just "Wikipedia, the free encyclopedia".--Father Goose (talk) 02:16, 9 August 2008 (UTC)

Having found Wikipedia excellent as an entry point into new subjects (epilepsy, dietary issues, etc.), I wonder if there's reason to encourage writers and editors to also add a short list of further reading, related to key topics covered (separate from text references, with short description of item content). This then helps put any interested readers onto up-to date, relevant/recommended publications. 09:07, 6 August 2008 —Preceding unsigned comment added by WECIU? (talk • contribs)

The "Further reading" section (per

WP:GTL) is supposed to be for sources that could be used in the article, but haven't yet been. As for getting readers to up-to-date publications about key topics, to the extent that links in the "External links" section doesn't accomplish this, the citations ought to be in separate Wikipedia articles about those other topics, as footnotes or in the "External links" section. And readers should be able to get to those topics via either wikilinks in the article, or links in the "See also" section. -- John Broughton (♫♫)

14:21, 6 August 2008 (UTC)

That's just one of the uses the guideline (

Wikipedia:GTL#Further reading

) recommends.

It explicitly states that it is to be used for "any books, articles, web pages, etc that you recommend as further reading, useful background, or sources of further information to readers." (currently anyway ;) -- Quiddity 03:06, 7 August 2008 (UTC)

Ah, perhaps I was mislead by the following, also in that section, which you didn't mention: This section ... is generally for resources on the topic that are not specifically cited in the article. -- John Broughton (♫♫) 23:31, 7 August 2008 (UTC)

Ah, whoops. I love it when it contradicts itself. Discordianism/IAR in action! consistency is... ;) -- Quiddity 05:55, 10 August 2008 (UTC)

Of interest to the English Wikipedia, since a revision to the core program could be enabled here / not enabled by consensus on a local project. flood flag. NonvocalScream (talk) 17:56, 9 August 2008 (UTC)

Nobody is going to remember to turn this setting on and off at appropriate times. If we want this effect wouldn't it be easier to add a "hide admin edits" setting, maybe enabled by default? — CharlotteWebb 18:18, 9 August 2008 (UTC)

Surely. I'm just posting here in case the community may be interested in enabling it on this wiki. The meta proposal if for meta enabling only. Interesting reading, and like I said, if we want this for en wiki, we should start a discussion here. Best, NonvocalScream (talk) 03:50, 10 August 2008 (UTC)

Hi all, I'm french from fr: and also one of the creators of fr:Modèle:utilisateur SUL (I translate this template here), the idea is about putting this template on your user's page. It's to inform readers where is your main wiki. Do you think that we could make this a "meta/general" template like babel ones ? Otourly (talk) 20:29, 8 August 2008 (UTC) Question also asked on meta:Metapub#Utilisateur SUL

I see no reason why your

Template:SUL Box, but I'm not a template expert. EdJohnston (talk

) 18:55, 10 August 2008 (UTC)

Moved to Wikipedia:Administrators'_noticeboard#Proposal_to_overturn_Privatemusings.27_arbcom_restrictions. NonvocalScream (talk) 20:48, 10 August 2008 (UTC)

There should be a way to watch a specific section, i.e. a specific question on the RD. (or a suggestion on the proposal village pump)--omnipotence407 (talk) 11:53, 10 August 2008 (UTC)

Not possible. The watch system is on a per-page basis, because the contents of each page can change dramatically. — The Hand That Feeds You:^Bite 13:54, 10 August 2008 (UTC)

See Wikipedia:Perennial proposals#Allow watchlisting individual sections of a page. Mr.Z-man 14:13, 10 August 2008 (UTC)

I'm not sure if this would work and would like to see a discussion of this proposal. Basically I'd like to:

1. streamline editing
2. eliminate imprecise duplication
3. eliminate lags in updating information
4. eliminate conflicts between what should be identical material in different places.

Many (often large) "primary" articles have sections that contain a little bit of content and a link to another article that is a legitimate "fork" article. The purpose of such article forks is usually to conserve space in the primary article. Now if we were to place a template (which is based on the content of the LEAD in the fork article) in the relevant section in the primary article, we'd save alot of work, and also possible editorial conflicts (and conflicting information) when further revisions to a fork article (as now) aren't reflected in the related section in the primary article. This proposal would automatically ensure uniform content.

Let's take an example:

The Large Hadron Collider primary article has a section entitled Safety of particle collisions. Fine and good....

That section contains a "Main article" template that looks like this:

which is followed by a paragraph of information on the subject, preferably identical to the LEAD of the fork article. If the fork article is serving its purpose, then a template of the content of its LEAD should be sufficient content for the related section in the primary article.

Such sections would then contain nothing but two templates:

1. a "Main article" template
2. a "LEAD" template

If this proposal is adopted, we could even combine the functions of those two templates into one template that would include both the link and the LEAD content.

What think ye? Will this work? Any potential problems? Can they be solved by tweaking this proposal, rather then just trashing it? --