Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Proposal: Allow established/experienced editors to see deleted contributions: good idea. Reservations. Comment reply to user:KnightLago
Line 719: Line 719:


:There is an add-on to do this for [[Firefox]]: [https://addons.mozilla.org/en-US/firefox/addon/744] --<span style="color:blue">[[User talk:Grey Knight|<sub>tiny plastic</sub> Grey Knight]]</span> <span style="color:#777">[[User:tiny plastic Grey Knight|&#x2296;]]</span> 15:12, 1 July 2008 (UTC)
:There is an add-on to do this for [[Firefox]]: [https://addons.mozilla.org/en-US/firefox/addon/744] --<span style="color:blue">[[User talk:Grey Knight|<sub>tiny plastic</sub> Grey Knight]]</span> <span style="color:#777">[[User:tiny plastic Grey Knight|&#x2296;]]</span> 15:12, 1 July 2008 (UTC)

:: Anecdotically, you also have an add-on which is simply is the IE8 activities for FF. And, I wans't truly paying justice to FF3 in my first post. In fact when you change your favored search engine in FF3, it also changes the search engine that is available through a right-click accordingly. That means you can get the WP search with a right-click, natively in the basic FF3, although it would be at the expense of having google or your favorite web search engine. Probably, the add-on you link would let people have both at the same time.[[User:ThorinMuglindir|ThorinMuglindir]] ([[User talk:ThorinMuglindir|talk]]) 17:59, 5 July 2008 (UTC)


:This is a good idea. Once IE8 Beta 2 comes out in August (which I am planning on installing), I would like to have this utility. I'm sure there are plenty of other people who would be interested in this too. -- [[User:Imperator3733|Imperator3733]] ([[User talk:Imperator3733|talk]]) 18:49, 2 July 2008 (UTC)
:This is a good idea. Once IE8 Beta 2 comes out in August (which I am planning on installing), I would like to have this utility. I'm sure there are plenty of other people who would be interested in this too. -- [[User:Imperator3733|Imperator3733]] ([[User talk:Imperator3733|talk]]) 18:49, 2 July 2008 (UTC)

:: Thanks for the encouragement. If others have a similar opinion, the question would be where and how to make this available to people, and how to inform users that there is someplace where they can download the IE8 WP activity. Obviously the best moment to make some noise about it would be after IE8 leaves the beta stage and Live Update has updated IE7 to the new version.[[User:ThorinMuglindir|ThorinMuglindir]] ([[User talk:ThorinMuglindir|talk]]) 17:59, 5 July 2008 (UTC)


== Optional filter for tables ==
== Optional filter for tables ==

Revision as of 17:59, 5 July 2008

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

  • Read this FAQ page for a list of frequent proposals and the responses to them.
  • If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
  • If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
  • If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

Why dont we have warnings for adult pages?

I mean, just some kind of warning, its open to any users age 0 to 100 to use wikipedia, shouldent there be SOME kind of adult content warning? It may be uncylopedadic, apon thinking about it, as any minor could open an encylopedia and flip to the 'Penis' page or such. There could be some kind of warning system, could there not? If you look up the article on 'penis' you expect to see a picture of one, and thats acceptable fully, but when its the first thing you see, some minors could really be bothered... I guess I sound like an overprotective mother, but I'm not. If you use the internet like I do, you've been 'rickrolled'. Thats when you're told to click a link, that says, "Picture of a Flower" and when you click it, you get anything, from the 'rickroll' video, to some... pretty nasty stuff. Its a sad thing when you can get rickrolled to an encyclopedia. Other articles have drawings of adult images, theres an idea. What about useing drawn or sketched [ie, medical sketches] of things like the penis, before photographs? I juts wanted to throw this out there. Cindy Flynn (talk) 06:16, 25 June 2008 (UTC)[reply]

Ohkay so a quick read in here made me clearly understand why we dont do that. So the proposal still stands. Should drawn images be placed before photographs in articles with "adult content," [I understand thats hard to defeine]? Cindy Flynn (talk) 06:22, 25 June 2008 (UTC)[reply]

I am a full grown adult and also agree with Micov. Couldn't we have a "Wikipedia Kids"? It could be composed of article lead paragraphs, selected images and links to the full WP content. I see that a URL squatter has registered www.wikipediakids.com, an unexpected hurdle. Emmanuelm (talk) 17:36, 25 June 2008 (UTC)[reply]
I feel to appropriately make my point, I must state a few things: I'm 15, and I have no problem with the uncensored content. As said in this, we are an encyclopedia. Britannica doesn't censor, neither should we. But, that does not mean we should disregard an internet minority with unsuitable content; www.wikipediakids.org (because if you'll notice we are .org,so that URL squatter isn't as much of problem) is a wonderful idea. It would be suitable and understandable for kids, but I realize there might be a hitch: it would have to have an edibility system for registered users only. Any vandalism would be absolutely devastating. I'm very stuck on this idea, and I will push it. Nice job Emmanuelm! Leonard(Bloom) 03:10, 27 June 2008 (UTC)[reply]
Registered users vandalize as well. To keep it vandalism free, you'd have to approve every new user account and then have trusted users approve every edit before it goes live. Even that wouldn't completely eliminate the possibility of vandalism, but it would make it incredibly unlikely. Mr.Z-man 03:35, 27 June 2008 (UTC)[reply]
    • I'd be the first to sign up to approve and add content for wikipediakids. I believe this could be a very good project! Lots of kids, and I mean, children, not teenagers, use wikipedia. It'd be pretty simple to screen each edit for vandalism, if you had a big enough team of trusted users. I believe that this could be a graet project. I noticed you said you where 15, and had no problem with adult content. Thats acceptable, lots of people your age can accept that type of content. Wikipedia kids would be for just that. Kids. Ages 7 [when they first start reading] to ages 13 or so. It only makes sence. I dont see how we'd get wikipediakids.org though. Cindy Flynn (talk) 22:25, 27 June 2008 (UTC)[reply]
What about kids.en.wikipedia.org or en.kids.wikipedia.org? Those domains would be more consistent, although we could also use wikipediakids.org. I don't understand why you think that we couldn't get the .org domain. This plan could work - get a decent number of trusted editors, create some policies on what is "adult content", and create a system where all edits must be approved by a trusted editor. -- Imperator3733 (talk) 15:36, 30 June 2008 (UTC)[reply]
For all who responded, see the thread below titled "Wikipediakids" Leonard(Bloom) 17:13, 30 June 2008 (UTC)[reply]
There is a very simple reason why there aren't warnings about "adult" articles: Wikipedia is not censored. There are dozens of userboxes explaining this. Any kid who comes to Wikipedia is expecting to learn something, and censoring hinders the learning process. This is like Child Psych 101: when you prevent a kid from having something, it only makes them want it more. Wikipedia isn't controlled by the FCC, and neither is the internet. Not only is the idea of an "adult" article entirely subjective (some uber-conservative parents might say that the Israeli-Palestinian conflict is "adult" material), the question about when a kid becomes an adult has been raging for centuries. In the 19th century, it was when a kid learned how to use a textile mill that he became an adult. Wikipedia is not dumbed down, nor indirect. It is blunt and to the point, just like any good encyclopedia. Think about if Brittanica was censored. That wouldn't be a very complete book, now would it? Plus, a wikipediakids would just be plain redundant. Schools across the country already have firewalls to stop kids from using Wikipedia because, since it's a wiki, it's not a "reliable source". So there's no point! Kids wouldn't be able to read it, anyway! ForestAngel (talk) 20:34, 3 July 2008 (UTC)[reply]
I have to agree with ForestAngel to some extent. I think perhaps a 3rd party project outside of the Wikimedia foundation would be much better suited for such an idea. What's great about wikipedia is that it's free both in the way that it doesn't cost money and in the way that it doesnt censor. %%-SYKKO-%% (talk to me) 02:39, 5 July 2008 (UTC)[reply]

Being able to edit your edit summaries

Ok, I've done this way too often. I make an edit, write the edit summary, and click "Save page", only to notice that I completely misspelled a word. At this point, there is nothing I can do about it other than hope nobody looks at my contributions. My proposal is being able to edit your own edit summaries. I brought up this discussion on one of the Wikipedia IRC channels, and there were plenty of ideas. The first is only letting admins edit summaries, and letting people make requests for them, because there is fear that other users would abbuse it, and possibly fabricate them. The other is only being able to make minor edits to fix typos, and prohibit completely rewriting the edit summary. I know this sounds odd, but some people (myself included) think this would be something that would make editing a little easier. Juliancolton Tropical Cyclone 17:06, 23 April 2008 (UTC)[reply]

I really don't see the need for this, nor a big problem that this would solve. If anything, a user script can be created that would require some sort of confirmation of your edit summary before saving it. - Rjd0060 (talk) 17:36, 23 April 2008 (UTC)[reply]
I think such a feature would be useful, as long as only admins could change them, and a history of the changes was logged. It should only be done for typos and minor mistakes. Fabrications of edit summaries would obviously not be allowed. Majorly (talk) 18:17, 23 April 2008 (UTC)[reply]
I would say have it so you could only change it if it was the most recent edit to that article (and it was your edit, ofcourse). This would do away with the need for a history of changes, admin-only restriction, etc., while allowing for fixing of one's edit summary in the vast majority of cases where it would be useful and appropriate. Kevin Baastalk 18:21, 23 April 2008 (UTC)[reply]
This would require a fundamental change to how Wikipedia's database is structured. (1 == 2)Until 18:40, 23 April 2008 (UTC)[reply]
How so? You wouldn't need to change any table names or column structures. As far as the database is concerned, it would just be one additional "update" query. Something like "update [table] set summary=? where article=? and revision=? and editor=? and revision=(select max(revision) from [table] where article=?)". That's not what i'd call a "fundamental change [in the] database [structure]". Kevin Baastalk
I'd much rather be able to change my log summaries (blocking, protecting, etc) which can sometimes look odd with typos. MBisanz talk 18:43, 23 April 2008 (UTC)[reply]
I would support that if it's possible. I would add though, that a message (like "This edit summary was added at ") was added at the end of the summary and then let admins view all versions of the edit summary. -- Imperator3733 (talk) 20:29, 12 May 2008 (UTC)[reply]
Why waste time fixing a typo in an edit summary? Edit summaries are not part of article content, and so it doesn't matter that they have perfect grammar. If you really need to amend or retract an edit summary, then make a dummy edit or use the talk page. –Pomte 20:12, 23 April 2008 (UTC)[reply]
Because that would be an even greater waste of time to leave a message on the talk page. And it wouldn't take that long. It could be like Rollback. You have to be granted the ability to edit your edit summaries, and then you just have to press a button or something. And really, how much time is it going to waste? Also, an edit summary is supposed to give an overview of what you've changed in the article. If you misspelled something or gave the wrong information, people might mistake what you've done. Juliancolton Tropical Cyclone 20:27, 23 April 2008 (UTC)[reply]
And it can get worse. I have sometimes pressed the wrong key while writing the edit summary (I still don't know exactly what I did) and that resulted in the edit being saved with just half the summary. This is obviously unhelpful. Waltham, The Duke of 21:02, 23 April 2008 (UTC)[reply]
That happens to me all of the time. You pressed Enter. hmwithτ 18:26, 15 May 2008 (UTC)[reply]
I would go with Kevin Baas on this one. One's most recent summary should be editable to fix typo. Any more than that, I and see RfA candidates going back to give themselves a leg up. —Preceding unsigned comment added by Paragon12321 (talkcontribs) 22:29, 23 April 2008 (UTC)[reply]
There is a simpler solution. Cultivate the habit of proofreading the edit summary as well as the actual edit when you show a preview. If you make a small error, it is really not a problem. If you really screw it up, make another edit to carry a correction.
Letting people alter either edit summaries or the substance of edits is allowing the rewriting of edit histories. It undermines the integrity of edit histories. The benefits are not anywhere close to being worth the cost. IMO. Wanderer57 (talk) 02:25, 24 April 2008 (UTC)[reply]
Not if you only let them change their edit summary if it was the most recent edit to that article - as soon as another edit is made you can no longer change the edit summary, so a historical record is kept (and shown) that can't be rewritten. Kevin Baastalk 15:36, 24 April 2008 (UTC)[reply]
You may be right. I think people are underestimating the technical difficulties involved in allowing people to edit their edit summaries, and overestimating the benefits of doing so. Wanderer57 (talk) 06:01, 25 April 2008 (UTC)[reply]
This is a great idea! I suggest limiting it to the latest edit during a 1 - 12 h period. Coding-wise it is an absolute no-brainer and will be very easy to implement (contrary to the above comments). Full support - Сасусlе 00:15, 26 April 2008 (UTC)[reply]
This is also good if you accidentally forgot to add a summary or put in the wrong one (happens if you have many tabs open). This would cut down on pseudoedits just to give or correct a summary. Сасусlе 20:49, 26 April 2008 (UTC)[reply]

Straw poll

I think it is too early to start a straw poll, please let us discuss details and implications a but further. Сасусlе 20:49, 26 April 2008 (UTC)[reply]
See also: bugzilla:10105. --MZMcBride (talk) 20:55, 26 April 2008 (UTC)[reply]

Support

  1. This is an excellent idea. At present, vandals can put offensive comments in an edit summary and nothing can be done about it other than attempt to get the edit deleted from history. GO-PCHS-NJROTC (talk) 20:29, 26 April 2008 (UTC)[reply]
    I am pretty sure that there is a wide consensus that admins should NOT be able to edit summaries of other users. We are talking so far about changing your own summary during a limited time period for every user. Сасусlе 20:49, 26 April 2008 (UTC)[reply]
    That sucks; I think admins should be able to edit the edit summaries; I have seen WAY too many vandals using abusive edit summaries. But I still support, there's been plenty of times when I've screwed up with edit summaries and wished I could go back in and fix the problem. GO-PCHS-NJROTC (talk) 00:20, 28 April 2008 (UTC)[reply]
    If an edit summary in a vandalism edit is that offensive, the revision can be deleted by an admin -- no editing necessary. Equazcion /C 09:34, 4 May 2008 (UTC)[reply]
  2. I have often wished I could edit my summary - sometimes I noticed my error just as I clicked the Save button. Allowing users to edit their own summaries immediately after saving and before any other edits to the page seems very reasonable. Sbowers3 (talk) 00:02, 28 April 2008 (UTC)[reply]
  3. have it so you could only change it if it was the most recent edit to that article (and it was your edit, ofcourse). Kevin Baastalk 14:19, 3 May 2008 (UTC)[reply]
  4. This idea would be wonderful if it can ever be implemented. Users should only be able to edit their own summaries, except admins can edit other users summaries to remove stupid comments ect. .:Alex:. 19:25, 3 May 2008 (UTC)[reply]
  5. Excellent idea; more people see edit comments that the actual text, and how many times have we all see boo-boos after pressing the button? TONY (talk) 14:00, 5 May 2008 (UTC)[reply]
  6. A fine idea - a few times I've hit "Save Page" and at the last moment realised that I've omitted something from the edit summary that perhaps should have been there. I see no real drawbacks (apart from the drain on the programmer's time) to this proposal. Lankiveil (speak to me) 12:12, 12 May 2008 (UTC).[reply]
  7. Support - users should be able to edit their last edit, as long as it is the last edit to a page and it has been no more than a couple hours. -- Imperator3733 (talk) 20:35, 12 May 2008 (UTC)[reply]
  8. Support - It would stop embarassing things like this, where I had the fingers of my right hand one key over from where they were supposed to be and didn't notice until I'd hit "Save page". ~ ONUnicorn(Talk|Contribs)problem solving 00:02, 17 May 2008 (UTC)[reply]
  9. Support, On the grounds that the user can only edit their own summaries. Also, admin should be given the right to edit anyones summaries. Rgoodermote  19:46, 20 May 2008 (UTC)[reply]
  10. Support for own edit summaries only, but with admins able to edit offensive edit summaries by anyone. DuncanHill (talk) 11:05, 21 May 2008 (UTC)[reply]
  11. Support for last edit only, by same person/IP only. --207.176.159.90 (talk) 23:58, 21 May 2008 (UTC)[reply]
    Comment:No offense but I myself do not like the idea of an IP being able to edit their own edit summaries. I know you are an IP. But I would like to suggest that IPs be given a limit. Rgoodermote  18:11, 22 May 2008 (UTC)[reply]
  12. Support - offensive summaries or summaries that reveal personal data are a big problem, but right now there is no way of editing them except for deleting the edit completely... which is not a solution most of the time. Figure out a way to prevent abuses, but it should be implemented. Renata (talk) 21:51, 24 May 2008 (UTC)[reply]
  13. Support I also like this idea but I can definitely see the problems it might introduce. If this is ever implemented, I think it should be restricted to auto-confirmed users and above. Perhaps there could be a feature that allows sysops to revoke a user their right to editing their summary. Also, it should definitely be possible for the user's last edit and only for a set time. ——Ryan | tc 08:43, 16 June 2008 (UTC)[reply]

Conditional Support

  • On one hand there should be a mechanism for removing disrputive, offesnsive, promotional, or dangerous edit summaries without going through oversight. On the other hand, I'm opposed to allowing any user to change any edit summary. It has a huge potential for abuse or misuse and I'm not sure why the average contributor would need that capability anyway, except maybe to correct a typo on their last edit. My vote would be to definately give sysops the capability to modify or remove offensive or disruptive edit summaries, and to allow other users to edit their own most recent summary under some type of time limitation. Mister Senseless (Speak - Contributions) 18:39, 1 May 2008 (UTC)[reply]
  • Yes – I have made typos in edit summaries, and also sometimes wished that I had written one (instead of using the default). This is a neat idea. However, I am not sure if there are any legal issues (therefore, I'm putting my support as "conditional.") 69.140.152.55 (talk) 14:10, 12 May 2008 (UTC)[reply]
  • Weak support leaning towards "not really important", there's been a few instances where I wished I could fix my edit summary, but again it's no big deal (forgive the cliche). If it's not a huge technical hurdle, I'd support editing the last edit summary only, during a 5 minute window following the edit. xenocidic ( talk ¿ review ) 16:40, 15 May 2008 (UTC)[reply]
  • Strong support as long as we are talking about an editor being able to change the summary of an edit if, and only if, it is their own edit, it is the most recent edit on the page, and no more than, say 12 or 24 hours have passed; this should apply equally to all registered users, including sysops. There is no potential for abuse there (nobody would "re-write article history"), and all sorts of problems with erroneous or incomplete summaries would be solved without complicating the history by leaving confusing or misleading summaries or making otherwise useless edits. Waltham, The Duke of 09:39, 18 May 2008 (UTC)[reply]
  • Conditional Support Good idea, though I don't view not having this capability as a significant hinderance to the work of most editors on Wikipedia. If it is something that can be fixed in a relatively simple way, then I'm all for it. If not, then there are bigger fish to fry. - Masonpatriot (talk) 15:46, 3 June 2008 (UTC)[reply]
  • Conditional Support I thinks users should only be allowed edit their own edit summaries, this way if you make a mistake you can correct it. Who cares if someone says something offensive in an edit summary. Pseudoanonymous (talk) 02:03, 9 June 2008 (UTC)[reply]
  • Conditional Support. This seems like a good idea, but it could cause problems. To see if there are any problems, should there be an edit summary edit history? An edit summary edit summary? An edit summary edit count? An edit summary contributions? An edit summary watchlist? An edit summary recent changes? I've often wanted to edit my own edit summary, but this could cause problems as the limit is 200 characters. Perhaps only if you are only allowed to edit your own summaries, and then admins can see your edit summary edits or something like that. Thanks. ~AH1(TCU) 16:40, 15 June 2008 (UTC)[reply]
  • Conditional Support per Waltham, although I wouldn't mind if the cut-off time was longer. I suggest 3 days. « D. Trebbien (talk) 01:15 2008 June 17 (UTC)
  • Excellent idea, if practical I'm sure the wikipedia developers are just sitting around waiting for work. It sounds like there could be significant database issues, and it's not worth jumping through too many hoops. As a compromise, I kind of like the idea of being able to change only your most recent edit, because that's when you know you messed up. How's this for an idea: Typically if you re-edit, and make no changes, you don't see a new result. How about if the only change is to the edit summary, then keep the change in place of the other change, or some such. It would have to be to your own edit only, not to someone else's. Baseball Bugs What's up, Doc? 07:28, 3 July 2008 (UTC)[reply]

Oppose

  1. Not worth fussing over. Live with your embarrassing mistakes, or make a non-edit follow-up to correctly describe your mis-typed previous edit. Too many issues about the reliability and fixed-ness of the edit history database arise in ths proposal. -- Yellowdesk (talk) 20:04, 3 May 2008 (UTC)[reply]
  2. Language in an edit summary is often quoted in disputes, often very quickly after the edit. Fixing the imo trivial problem of typos in summaries would seriously jeopardise the ability to verify these claims if an editor can go back and modify their summary based on future events. Frankly, well meaning intentions aside, this is a no-brainer, or should be to anyone who has followed a few disputes before. A far worse problem that needs addressing is allowing no summary. MickMacNee (talk) 18:16, 13 May 2008 (UTC)[reply]
    But under this proposal, the edit summary could only be changed if it was the last edit made. It seems to me that most of the time what you are saying would not happen. Plus, I think someone proposed that admins would be able to view the previous edit summaries. -- Imperator3733 (talk) 14:42, 14 May 2008 (UTC)[reply]
  3. Resounding oppose - toooooooo much potential, hardly any benefit, causes some damage (yeah, I know...), if people want to retract an edit they can always do a null edit afterwards. TreasuryTagtc 18:56, 13 May 2008 (UTC)[reply]
  4. This seems to offer little actual improvement to the editing experience to offset the major disruptions it could cause to the process of dispute resolution, vandalism fighting, etc. --Gwguffey (talk) 19:46, 13 May 2008 (UTC)[reply]
  5. Strong Oppose. We have enough problems with vandalism without creating a route for "edit summary vandalism". – ukexpat (talk) 15:22, 14 May 2008 (UTC)[reply]
    If the editing is limited to the last edit during a relatively short timespan I do not see the potential for vandalism or disruption as any subsequent edit (e.g. fixing vandalism) makes a summary permanent. Cacycle (talk) 03:57, 15 May 2008 (UTC)[reply]
  6. Highly doubt this would ever actually happen, but here's my two cents anyway. I agree it's annoying when you accidentally make a stupid grammar or spelling error in an edit summary, yeah it can be embarrassing etc, but guess what, it happens to all of us and it isn't important, so just deal with it. Also, as someone points out above, summaries are used as evidence in disputes -- so the ability to edit them would add a certain kind of recursive complication. Similar to the fact that edit summaries are required when editing a page, edit summaries would probably be needed when editing edit summaries as well -- it is, after all, the ability to change evidence, so an explanation for the edit would be needed, not to mention a history of previous versions.... seems to be getting silly then, right? You bet. This would only cause problems and, trust me on this one -- it's just not happening. No developer in their right mind would ever add this kind of superfluous functionality. Equazcion /C 04:16, 15 May 2008 (UTC)[reply]
  7. Per above. ES are have document character here. If we make then editable we need a history/permalik feature for them as well. This will not happen. Don't waste your time fussing about it. The benefits are marginal. Everyone makes typos sometime, just suck it up. --Dschwen 17:09, 15 May 2008 (UTC)[reply]
  8. Strong Oppose: They are often used in RFArb cases, so no hiding embarrassing edits. --Dragon695 (talk) 00:50, 23 May 2008 (UTC)[reply]
  9. I have made spelling mistakes in my edit summaries an embarrassing number of times but I don't really see having the option to edit them improving the encyclopaedia. Spelling mistakes - not really a big deal, being able to easily hide past negative behaviour is potentially a big deal. If edit summaries were editable would they have histories, are are these histories going to have edit summaries, will those be editable? Guest9999 (talk) 02:50, 23 May 2008 (UTC)[reply]
  10. Strong Oppose - Negligible benefit, strong likelihood for misuse/abuse. /Blaxthos ( t / c ) 12:11, 24 May 2008 (UTC)[reply]
    • I am referring here to all the opposing parties using this as an argument: How could the feature possibly be abused if the summary could only be changed within a few hours and as long as the edit is the top one? Or do people expect cases to open on the same day as the edit summaries are given? Honestly, I do not understand this. Waltham, The Duke of 23:29, 26 May 2008 (UTC)[reply]
  11. Oppose. The benefits are negligible while the potential for abuse is substantial. Nsk92 (talk) 19:08, 24 May 2008 (UTC)[reply]
  12. Oppose One of the points of edit summaries is to keep a record. Are we to also have edit summary histories? Do you make an edit summary to explain the change to you edit summary? Can you change those edit summaries too? This is a waste of the developers time too, as the current software cannot do this. 1 != 2 19:14, 24 May 2008 (UTC)[reply]
  13. Oppose I do not see the problem for which this proposal advances a solution. I can imagine new problems and new rules about who is allowed to edit what in which summaries, and how to deal with those who abuse the feature, people suspected of abusing the feature, or people not using the feature being told they should. in lieu of null edits, etc. Why create a new layer of crap when the status quo is actually just fine? Jerry talk ¤ count/logs 17:34, 26 May 2008 (UTC)[reply]
  14. Oppose if this were implemented, modifications would have to be logged for transparency. And of course, we'd have to have a field in which users could provide an explanation as to why they edited the summary. And then... oh... :D Happymelon 16:42, 27 May 2008 (UTC)[reply]
  15. Oppose. Too little benefit would cost too much in time and effort. WODUP 20:36, 27 May 2008 (UTC)[reply]
  16. So not worth it. It is supposed to be a record of what happened on the wiki - if you could change it (at all!) that defeats the purpose. Also, we would need a log for changes. But then people might make typos... – Mike.lifeguard | @en.wb 23:39, 31 May 2008 (UTC)[reply]
  17. Strong Oppose Completely unnecessary and a real potential for abuse add up to make this a very bad idea. We've all made typos and other typographic faux pas and, yes, it's embarrassing. But it's very much not a big deal. Too real a potential for abuse for this to be implemented. faithless (speak) 08:28, 1 June 2008 (UTC)[reply]
  18. Strong oppose - We should be concentrating on editing articles, not summaries. Sure, it looks stupid to have a misspelled word in your edit history, but in the bigger picture who cares? All it really does it open up potential new problems (even with the "own, last, recent" restrictions mentioned below) and not improve the encyclopedic content of Wikipedia. As such, it runs counter to the principles of Wikipedia. As someone above mentioned, check your work before you submit. Also preview your work. I will edit and preview a massive rewrite of an entire article for sometimes two days before I finally hit submit. The change log shows +10,000 or more article length increases in a single edit, with no need to go back and make further edits. If you're careful, you don't need to edit your edits. That's not to say I never make mistakes (I'm human, not a bot, after all), but so what. Sometimes it's funny to look back at your goofs and smile. --Willscrlt (Talk) 11:07, 1 June 2008 (UTC)[reply]
    Willscrlt: I completely agree that we should not care to correct typos in summaries. But that is not the reason for this proposal anyway. The only reason why we need this is to correct accidentally misleading summaries, such as empty, switched, or half-written summaries. I do not see that Wikipedians would start focusing on editing old summaries instead of articles, so I do not really understand your strong opposition against this nice to have feature - especially after your confession that even you make some summary mistakes from time to time ;-) Cacycle (talk) 19:07, 1 June 2008 (UTC)[reply]
    I suppose that the reason is that summaries a) can be accidentally misleading - what a person only slightly familiar with a subject considers an "insignificant change" can be a big deal to someone intimately familiar with it; b) can be deliberately misleading - a vandal could say "correcting typos" when really he changed every occurrence of "orange" to "purple"; c) are often omitted because many people don't care or understand; and d) are no match for a quick diff comparison (I love popups for that). I guess my thinking is that summaries are nice, but are not an essential feature of the software. Editing comments is really wasting time that could be spent on improving the project. It also makes the software more complicated and increases the chance that a bug could be introduced. I run two other wikis that use MediaWiki software, and I would prefer to keep feature creep out of the software when it doesn't significantly improve anything. --Willscrlt (Talk) 23:08, 1 June 2008 (UTC)[reply]
  19. Oppose Edit summaries serve the use of giving a reader a general idea of what the editor did. They are not extremely important. After all, the reader can always compare versions and see exactly what happened between those two versions. Constantly changing edit summaries would be confusing to the reader ("Wait--what? Didn't it just say something else a minute ago?") and would also serve for another place for vandals. Edit summaries are not that important! Like I said before, no one's going to change exactly what you did to the page, which is most important. IceUnshattered (talk) 00:12, 10 June 2008 (UTC)[reply]
    I am still waiting for an explanation how this feature could be used for vandalism under the proposed restrictions. I would also be interested how you came to the conclusion that editors would "constantly changing" their summaries under those restrictions. I disagree that summaries are not important, we have them for a good reason, i.e. to make life easier, and again, this proposal is for correcting accidentally misleading and confusing summaries. Cacycle (talk) 00:50, 16 June 2008 (UTC)[reply]
  20. Oppose otherwise what we end up with editors sanitizing their edit summaries as part of the lead up to RFA, RFB or ARBCOM. Yeah ok we all leave the odd spelling/typo error but live with it why waste server load with editors changing edit summaries. Gnangarra 04:10, 17 June 2008 (UTC)[reply]
    Please check the following "Short break" section for the actual proposal. You will see that it would not be possible to sanitize edit summaries. Cacycle (talk) 23:05, 17 June 2008 (UTC)[reply]
  21. Oppose I think any possible wasting of time over editing edit summaries or even the possibility of misuse or confusion in doing this easily outweighs the (to my mind) negligable benefits. Davewild (talk) 20:58, 19 June 2008 (UTC)[reply]
  22. Oppose there are just way to many ways in which this feature could be abused, vandals could post extremely virulent personal attacks or other obscene statements in their edit summaries and then remove them within seconds content with the knowledge that they had insulted every one watching recent changes at that time, and, that because they have changed there summaries the users have no proof. The only way to stop such abuse would be to give each edit summary its own history which would be extremely problematic. -IcĕwedgЁ (ťalķ) 06:12, 30 June 2008 (UTC)[reply]
  23. Opppose There needs to be an immutable record to follow development of article. Having to also rework the history of edit edits would not be worth the confusion of people fixing "teh" and other misspellings. Jason Quinn (talk) 15:38, 3 July 2008 (UTC)[reply]
  24. Oppose Why fix something that isn't broken? Yngvarr (c) 12:52, 5 July 2008 (UTC)[reply]
Short break:

It was really not a good idea to start a poll without talking about the same thing.

The current proposal and bugzilla discussion can be found here. It asks for a mechanism to correct edit summaries (1) if it is your own edit (2) and if it is the last edit (3) during a short time span. This exact same mechanism is implemented in most online forum systems and has proven its efficacy and safety. Under these restrictions (own, last, recent), there is absolutely no potential for abuse (e.g. any following edit would make the previous summary permanent). At the same time you keep the benefits such as fixing accidentally empty summaries, switched summaries (when you have many tabs open), and half-completed raw summaries.

I am sure that many of the opposing users (as well as some supporting users which were obviously voting for a different mechanism) would actually support such an implementation under these restrictions. Again, this is not about allowing administrators to change summaries, not about allowing admin candidates to white-wash their editing history, and not about giving vandals any type of new toy. It would just be a nice feature to make editing Wikipedia easier - nothing more and nothing less. Cacycle (talk) 03:28, 28 May 2008 (UTC)[reply]

I completely agree. With all due respect to the editors who have voted above, and to their arguments, a poll as badly organised as this one can yield little useful information on the consensus for the specific proposal made here. Waltham, The Duke of 15:22, 30 May 2008 (UTC)[reply]
I agree as well. I too was about to fall victim of the poll, thinking I opposed, until I read this section. Now I'm thinking that the proposal is a pretty good idea. -- Ned Scott 10:16, 25 June 2008 (UTC)[reply]
if it is the last edit (3) during a short time span - the sticking point is that even if an edit summary exists for only a minute, it's going to be seen by recent change patrollers as well as editors who have the page on their watchlist - particularly those using RSS feeds for monitoring. Perhaps that's not a big issue - if a vandal posts obscenities and removes them 45 seconds later, there is presumably a log that can be used to demonstrate that the obscenities did exist. Still, we're adding yet one more thing to the complexity of Wikipedia. -- John Broughton (♫♫) 14:54, 1 July 2008 (UTC)[reply]

Neutral

  • As a number of people mentioned above, this could be difficult in implementation and perhaps more importantly could have wider implications. My suggestion would be a special kind of 'change edit summary' edit. This would function much like the above (only possible with most recent edit by the person who made the edit and perhaps some sort of time limit as well) except instead of actually changing the edit summary, it simply makes an automatically completely null edit with summary and marks the previous edit summary as 'obsoleted' or something of that sort (similar to minor edits and bot edits). By default, these obsoleted edit summaries will be hidden but editors can obviously chose to view them if they so desire. My suggestion would be to extend this to edits as well. (It will always be completely optional.) This way, editors who e.g. don't preview or otherwise make several edits in quick succession can choose to hide the intervening edits if they desire to make it easier for other editors to browse the edit history (but as I mentioned other editors can still view the intervening edits if they want). A time limit will probably be important in this case to avoid editors who think they're funny and vandalise or cause other problems and then hide it a few hours later to try and obscure what they're doing, and also to avoid encouraging editors to edit when they are in a foul mood thinking they can hide anything bad they did later. Potentially this should be added as an autoconfirmed option or even a rollback option to discourage misuse further. Nil Einne (talk) 06:50, 1 May 2008 (UTC)[reply]
    Under the restrictions we are currently talking about (last plus own edit for a short time) I do not see the potential for abuse (after all, any following edit to the page makes the previous summary permanent). Therefore, I do not think that we need a history for this. A simple link on the history page that lets you change the summary entry of that edit would do it. We probably want to restrict this to registered users, but I do not think that we would need further restrictions. Сасусlе 21:46, 1 May 2008 (UTC)[reply]
  • While I'm still roughly neutral on whether an editor should be able to edit their own edit summaries (I can see both points of view, but haven't personally decided yet), I don't think admins should be able to edit "anyone's". Yes, talk page comments may be edited, but only under certain situations. (And I've seen enough successive revertings by admins of such edits, to be concerned.) And we really don't need to see the creation of reversion histories of edit summaries. So opening this door would seem to be a bad idea. And there's no real "need", since admins can always delete the revision in question. (And which can also be undeleted. And already has a set of logs.) If it's deemed truly necessary, just add this ability to the oversight "package". - jc37 20:17, 6 May 2008 (UTC)[reply]

Please participate in the discussion of the "official feature request" for this under https://bugzilla.wikimedia.org/show_bug.cgi?id=13937. Cacycle 19:16, 3 May 2008 (UTC)

Bugzilla is for technical implementation, not discussion of this sort. The developers will not be happy if you start spamming the bug with "DO WANT!" – Mike.lifeguard | @en.wb 03:59, 1 June 2008 (UTC)[reply]

Renaming "history" tab

Last year, editor Borisblue proposed changing the name of the history tab. I felt that renaming the tab to either "versions" or "revisions" would make its function clearer for casual readers and newbies. However, some respondents just didn't see the need for a change, and the proposal faded. (old discussion)

I think it's time to revisit the question. Part of the problem convincing people we ought to change, is that everyone who would be discussing it has been on Wikipedia long enough to know what the history tab is. Thus, it is hard for them to see how opaque it might appear to the uninitiated. They might, as in Borisblue's example, think that the tab on "Poland" would lead to "history of Poland." Or they might simply not get its purpose at all; after all, non-wiki pages don't have a mechanism for viewing past versions. I don't think we should assume that those readers will, out of sheer curiosity, click on the tab to see what it is, or do a mouseover. I believe that "versions" or "revisions" (or even "authors," the German Wiki uses "Versionen/Authoren") would be more likely to get people to click on the tab.

I know some people will say, "why change?," but can someone make the case why the current name is actually better or clearer? --Groggy Dice T | C 16:29, 2 June 2008 (UTC)[reply]

There may be issues with GFDL compliance, since I understand that Wikipedia asserts the history tab to be our "section entitled 'History'" as defined in section 1 of the GFDL and referenced in sections 4.I/J and the third paragraph of section 5. Of course, it doesn't seem like the non-English Wikipedias strictly comply with the titling requirements of section 1 anyway, and in any case our application of the GFDL is already rather idiosyncratic given that the license was never designed for wikis in the first place. —Ilmari Karonen (talk) 00:56, 3 June 2008 (UTC)[reply]
"Contributions" could perhaps increase community togetherness :). Ferdia O'Brien (T)/(C) 14:18, 3 June 2008 (UTC)[reply]
I like the idea of renaming it "Log." GO-PCHS-NJROTC (Messages) 23:19, 3 June 2008 (UTC)[reply]
Just to jump back in to comment on the GFDL issue, I don't think that's a big deal. I don't think anyone is likely to make an issue out of such a technicality. (If we're going to be hypertechnical, maybe the GFDL requires that "history" be capitalized!) But after reviewing the GFDL, I don't think it requires that the tab be named history, as long as the page title is named History. Even if there was a ruling that there had to be a link called "history" to the article history, we could probably create a second link called history somewhere on the page, and keep the tab named something else (as kludgy as that sounds). --Groggy Dice T | C 21:01, 21 June 2008 (UTC)[reply]
We could name it "revision history" if we needed to... Titoxd(?!? - cool stuff) 05:44, 5 June 2008 (UTC)[reply]
We all know what "revision history" means, but some readers might think it means "revisionist history". rspeer / ɹəədsɹ 18:18, 10 June 2008 (UTC)[reply]
And we're accused of that widely enough that it would resemble a freudian slip at first glance. — CharlotteWebb 14:09, 24 June 2008 (UTC)[reply]
Isn't it called History in order to comply with the requirements of GFDL? Corvus cornixtalk 20:45, 5 June 2008 (UTC)[reply]

Support 'Revision' seems most appropriate. Old discussion was not as convincing. Jeff Carr (talk) 16:27, 16 June 2008 (UTC)[reply]

Support The German Wikipedia's menu bar makes more sense to me, and I'm not even that good at German. 'Revision'/'Log' sound like pretty good names if it was changed. Leonard^Bloom (talk) 19:07, 17 June 2008 (UTC)[reply]

I don't have a current opinion on the title.. but we could conduct some kind of test or survey to see which possibility is best understood. We could, for example, change it for some subset of the visitors to the site and see which one generates the most usage. Or we could perform a survey where people are asked "which of these would you look at to determine..." ... I think we'll get better results if we test rather than guess. --Gmaxwell (talk) 19:29, 17 June 2008 (UTC)[reply]

I think the first option (the change and review) is a very good one. Visitors may feel the survey is intrusive. Leonard^Bloom (talk) 19:56, 17 June 2008 (UTC)[reply]
It's not so simple as seeing which gets the most usage. What if "history" gets more clicks because people aren't sure what it does and click just to see? It might be hard to come up with a metric that clearly gives an unbiased statistic. Jason Quinn (talk) 23:45, 1 July 2008 (UTC)[reply]

On a whim you could do a survey of a database dump (or mailing list archives, or IRC logs, etc.) and determine how our users most often refer to it. I'd bet that edit history is the most common phrase, and that's what I would use if convinced that "history" isn't descriptive enough. But would it be clear enough to absolutely anyone seeing the tab for the first time? No, nothing would, but it would at least be clearer than "revision history" (with or without vague political undertones). — CharlotteWebb 13:57, 24 June 2008 (UTC)[reply]

I oppose changing the name from 'history'. It is a common enough term in computing contexts (e.g. internet explorer has a 'browsing history') & I believe most users will understand it. A few people may misunderstand at first, & think that it refers to the history of whatever the subject is about, but no alternative would be free of this possibility - e.g. if it was called 'versions' & you were looking at an article about a song or a film or a book, you might misunderstand the 'versions' tab. Anybody who does initially misunderstand what the tab is for only has to click on it once to immediately see what it is. Weasel Fetlocks (talk) 14:00, 29 June 2008 (UTC)[reply]

Support I think "revisions" (with the 's'... not sure why you wouldn't want the 's') is the perfect wording with no room for misunderstanding like the current "history". One of my favorite quotes is "aim not to be understood but to be impossible to misunderstand"; so the argument that most people understand the current 'history' doesn't pass muster with me. Jason Quinn (talk) 23:39, 1 July 2008 (UTC)[reply]

What about "article revisions" - isn't that the most explicit answer? --Allemandtando (talk) 23:54, 1 July 2008 (UTC)[reply]
There of course comes a point of diminishing returns in clarity and "article revisions" is past that. What other kind could 'revisions' sensibly mean? So "article revisions" is not worth the extra screen clutter of two words. Jason Quinn (talk) 00:21, 2 July 2008 (UTC)[reply]

Take away "sign" button when editing non-talk pages

I've seen people sign their names on non-talk pages (Wikipedia policies, articles, etc). It's irritating and makes them look like newbs (not that they are). I think that someone should go inside Monobook and add something to remove the sign button for these pages. G2.0 USA contributions 21:12, 21 June 2008 (UTC)[reply]

Hi. This is a good idea overall, but can cause some problems. The signing option is also available in the box below the edit box, however. Also, some pages like the reference desk, help desk, and village pump pages (including this one) need to be signed, so it would be helpful if we could sign on select Wikipedia: pages by clocking the tab also. Thanks. ~AH1(TCU) 21:32, 21 June 2008 (UTC)[reply]
Such exceptions (noticeboard pages, etc. which are for discussion but not in a "_talk:" namespace) are generally identifiable by the __NEWSECTIONLINK__ keyword, and since the toolbar buttons require javascript anyway, well, you know... — CharlotteWebb 04:10, 23 June 2008 (UTC)[reply]
Actually the blanket removal of the ~~~~ button from the toolbar when editing an article, category, or template would probably be completely harmless, other namespaces (particularly "Wikipedia:") being less orthogonal in function. — CharlotteWebb 13:33, 23 June 2008 (UTC)[reply]
There are other exceptions, such as Wikipedia:Requests for arbitration, Wikipedia:Requests for comment, Wikipedia:Articles for deletion, etc. I think the Wikipedia namespace is too multipurpose as you say. The Article/Category/Template namespaces sound viable, like you point out. --tiny plastic Grey Knight 14:49, 24 June 2008 (UTC)[reply]
I'd support removing the button from the Article/Category/Template namespaces. The only problem I see is that people could still sign by typing ~~~~ manually, but it would still cut down on signing non-talk pages. -- Imperator3733 (talk) 15:54, 30 June 2008 (UTC)[reply]
I can't say that I've seen enough abuse of this feature to warrant tweaking it, but I wouldn't be opposed to its removal from Article, Category, and Template namespaces. EVula // talk // // 16:18, 30 June 2008 (UTC)[reply]
What about Portal and Image? Is there any reason not to include them? People do have a tendency to sign Images. Obviously User is fine as it is. JohnnyMrNinja 16:24, 30 June 2008 (UTC)[reply]
I wouldn't mind the button being removed from other than talk pages, when I was a newbie, I initially didn't know I SHOULD NOT sign my edits. It's not harmful, but I can see it as annoying to editors and the VERY casual readers of WP.--Hourick (talk) 16:37, 30 June 2008 (UTC)[reply]

Date parameter to "Do not move to Commons" template

I propose we add a mandatory date parameter to images tagged with this template which would put images into categories based on the copyright expiration date. Image:The Scream.jpg would be in Category:Move to Commons in 2015 for example. This way we can more easily follow images whose copyright will expire really soon (in a couple of years). Mind that there aren't that many images tagged with this. -- Cat chi? 10:44, 25 June 2008 (UTC)

Seems reasonable SGGH speak! 16:10, 25 June 2008 (UTC)[reply]
The problem with that is that approach is that it assumes no future changes or extensions to the duration of copyright protection. In the United States, it is well known that the term of copyright is likely to be extended in perpetuity so as to prevent Disney characters like Mickey Mouse and Winnie the Pooh from lapsing into the public domain. Perhaps a better set of categories would be along the lines of Category:Images copyrighted in 1920 or the like. Those wouldn't need to be updated if the law changes.
Note that extraordinary care would need to be taken in the future if someone wished to use automated (or semiautomated) tools to migrate copyright-lapsed images to Commons. Relying on user-supplied copyright dates may be risky. TenOfAllTrades(talk) 16:25, 25 June 2008 (UTC)[reply]
Basically reiterating what TenOfAllTrades pointed to: There is no strong reason to believe that a significant amount of works under copyright protection now will ever lapse. It would be better to tag the works with the relevant data which can be used in the future to apply the standing law. --Gmaxwell (talk) 23:46, 25 June 2008 (UTC)[reply]
I personally believe that they won't extend copyright again - there's a fierce and powerful lobbying group of anti-copyright people now, responsible for the legal fees of Eldred v. Ashcroft in 2003, who will push back against the pro-copyright lobbyists. But I can't say either way. Dcoetzee 02:11, 27 June 2008 (UTC)[reply]
This system is intended as a systematic reevaluation of image licenses. If some works copyright expires (for whatever the reason) at the specified date, it becomes PD and we can retag it accordingly. If not we can retag it as per the new extended date. Another thought is that this kind of tagging can be applied to current works covered under a fair use license. For example images whose authors have died (so we have an idea which year the copyright will expire). TenOfAllTrades's suggestion wouldn't work well because date of copyright is rather irrelevant in copyright. It is Generally authors death + 70 years.
I never suggested a fully automated system. I would oppose that in the matter of copyrights.
I do not see "user-supplied copyright dates" as a particular risk. All our licensing is done by "user-supplied copyright". At times people tag non-free works as free (I have seen 2008 movie screen captures marked with {{PD-old}}), that however is dealt with. This system is intended to prevent that. For example PD-Old images can be tagged by date (the date copyright expired - if available). If I see a colored screen capture of an anime in a PD-old image from the 1700s - I can catch the lie in action very easily. In other words oversight is better organised.
This could be a seperate template I suppose. The idea is the creation of a category system to process and reevaluate images based on the time of their copyright expiration - which as pointed out can be extended (somehow) and in such a case the date would be extended over here as well.
Gmaxwell's rationale above falls under WP:CHRYSTAL. If that law is changed as he suggests, we can adjust accordingly. If not, there is nothing to worry about. There is no reason to believe some ~200 countries will switch to the legal system he proposed.
-- Cat chi? 21:39, 28 June 2008 (UTC)
Why not use the author's death date instead, and then use {{#expr:}} for the number of years since then? This idea would be best as an optional one, as it could very easily be coupled with the third parameter of "country", which would use (perferably?) a {{#switch:}} to distinguish countries. Example (numbers fictional):
{{#expr [possibly #ifexpr]:{{#switch:{{{country|{{{2|}}}}}}|United States|Sweden|China=100|England|South Africa|French New Guinea=75}}-{{{date|{{{1|}}}}}}}}
From which we can combine the two, with something of an output of
This image will be in the public domain in X years (where X is that output - also use days if you want, though I wouldn't) in both the United States and its originating country. Please considering copying it to Commons when that number equals 0.
Or some such. Feel free to work with the function itself as well as the wording; the concept is what I was looking for. As for categorization, maybe-also possible. Either way, this allows for the main concern of "if they change the number of years" - all you have to do is change the numbers in the switch function. --Izno (talk) 06:14, 30 June 2008 (UTC)[reply]
Commons has several times pondered a similar idea - a sort of image "vault" for media that is not yet PD, to be automatically uploaded (or undeleted) when the day comes. This discussion fizzled, there were some legal concerns, and no one taking up writing the necessary bot, but no strong objections either. Dcoetzee 23:59, 30 June 2008 (UTC)[reply]

Would it be desirable, and if so would it be possible, for wikilinks to disambiguation pages to be in a different colour to links to non-disambiguation pages? This would, in my opinion, have certain beneficial effects. It would make the work of fixing disambiguation links mush easier. It would also help edotors adding links to spot when they have mistakenly added a link to a disambiguation page, and it would, I think, encourage more editors to fix suxh links, simply by making them more obvious. DuncanHill (talk) 11:37, 25 June 2008 (UTC)[reply]

There are a couple of tools to do something like this. Anomie 02:25, 26 June 2008 (UTC)[reply]
The best tool I am aware of is dabfinder.py. I know I can change the textcolor of e.g. redirects at my own [Userpage]/monobook.css via a.mw-redirect {color:#308050}, so I guess it is possible in some way to also change the colors of dabpages, but I guess you'd get more help at MediaWiki:Monobook.css. – sgeureka tc 15:04, 30 June 2008 (UTC)[reply]

How is this page archived?

What is the method used for archiving Wikipedia:Village pump (proposals)?

The Transhumanist    17:53, 25 June 2008 (UTC)[reply]

Looking at the source, it's MiszaBot. Look for {{User:MiszaBot/config...}} near the top. davidwr/(talk)/(contribs)/(e-mail) 18:07, 25 June 2008 (UTC)[reply]
Interesting. So far, we have only had messages for here posted in the talk page... Glad to see some symmetry at last. :-) Waltham, The Duke of 07:34, 29 June 2008 (UTC)[reply]

The Do Good Gauge

The Do Good Gauge is based on the concept where a group refines an argument which is then posted for democratic measure. The Do Good Gauge provides a mechanism to tie arguments together. The goal of the concept is to provide the most comprehensive view for understanding every angle of an argument.

The foundation of the idea is based on refining arguments similar to Benjamin Franklin's Junto group. This refinement would lead to the development of an intelligent argument. These intelligent arguments would be posted on a website where the public would measure its moral goodness. This measurement would stimulate alternative or supporting arguments for refinement.

Wikipedia's collaborative functionality would provide an instrumental tool for developing the arguments refined by the Junto group.— Preceding unsigned comment added by BenDoGood (talkcontribs) 22:01, June 25, 2008 (UTC)

Wikipedia is not a democracy. — The Hand That Feeds You:Bite 00:22, 26 June 2008 (UTC)[reply]

This Do Good Gauge proposal is not intended to turn Wikipedia into something that it is not, but to suggest that Wikipedia has a great potential for collaboratively refining arguments.

Admittedly, the purpose of posting this idea to the Village pump is to recruit individuals in refining the Do Good Gauge Concept. Any suggestions of where Wiki type tools are being used in refining arguments in the nature of Benjamin Franklin's Junto would be appreciated. —Preceding unsigned comment added by BenDoGood (talkcontribs) 02:24, 26 June 2008 (UTC)[reply]

You don't make it clear what your proposal is in relation to Wikipedia practice or policy. If you are just advertising / recruiting for your website, it doesn't belong here. Weasel Fetlocks (talk) 13:57, 26 June 2008 (UTC)[reply]

The name of this thread is "Village pump (proposals)" and from reading the guidelines of the the thread I assume this is as good a place to post the Do Good Gauge idea. If not, suggestions of where to post would be appreciated.

I would suggest that a large portion of the articles posted on Wikipedia can be considered arguments. As much as individuals would like to claim objectivity in developing their articles, most topics are subjective. The collaborative nature of Wikipedia brings a democratic balance to this subjectivity.

An argument tends to provide a point of view with a suggested solution. The problem that an argument tends to resolve is rarely binary in nature. Again, Wikipedia does provide a great tool for collaboratively providing intellectual answers to a problem, but there are no guarantees that an article will reference opposing or optional arguments.

As of today, there is no single internet source where arguments can be examined from a multi-dimensional point of view. At the discretion of Wikipedia author(s), an article can reference opposing or optional points of view, but this feature is not built into site.

In short, the goal of this proposal is to provide an internet source which provides the most comprehensive and intelligent views of argument topics. At a minimum, I could see Wikipedia as providing the collaborative method for developing the argument thesis. At a maximum, I would foresee Wikipedia providing more consistent connection to related arguments. --BenDoGood (talk) 15:11, 26 June 2008 (UTC)[reply]

You seem to be operating from a false assumption (articles == arguments). While debate may occur as to the phrasing of article contents & sourcing, the entire point of Wikipedia is that you can look up the references yourself to verify what they say. For debates, Wikipedia operates on consensus, meaning we try to find an agreement that fits within our rules. It is not a majority vote, nor is it a place to debate the subject of the article itself. It sounds like what you really want is to start a new wiki primarily for debate and using your system to resolve those debates (to the extent they can be resolved). — The Hand That Feeds You:Bite 16:41, 26 June 2008 (UTC)[reply]
I looked at your website to see how this system is supposed to work. I honestly think that you would need some specialised coding done, what with all the voting and such. It seems closer to a web forum than to a wiki. Look around, there might be some existing forum software, or extensions to such, that will do something like what you want; as long as users can assign a "value" to each others' posts, you should have the basics of it. Ironically I had an idea for a project that could achieve this (although just as an interesting theoretical exercise, whereas yours has a specific "aim") but haven't got time to build it. As I say though, it's probably been done somewhere. --tiny plastic Grey Knight 13:45, 27 June 2008 (UTC)[reply]
Apparently the phpBB forum system has an option for rating the post as good/bad; if you want something less binary then it could probably be modified without too much bother. Ask around on their community forum if somebody can give you a hand. --tiny plastic Grey Knight 13:51, 27 June 2008 (UTC)[reply]

Grey Knight, thank you for taking the time to look at the abstract idea posted at Do Good Gauge. As a software engineer who specialize in developing data driven websites and open source solutions, I feel I can design and manage the development of the site.

The Do Good Gauge processes involves several ideas which are not implemented as an entire internet solution.

  • A collaborative group to refine and prepare a thesis argument. Wikipedia would provide a great tool for collaboratively developing the thesis paper.
  • A forum type site for publicly displaying, querying, arranging, and gauging the thesis papers.
  • Statistical analysis for collecting interesting information which could be used to invoke related arguments.

Several debate type of websites capture a portion of this idea, but the goal of a debate team or website is to win a position not to fairly represent all aspects of an argument.

Grey Knight's suggestion for obtaining a hand from the community forum is appreciated. It is help in refining the idea and in recruiting a junto/community to generate arguments for the site that I am looking for.


--BenDoGood (talk) 15:54, 27 June 2008 (UTC)[reply]

As above, it may be a good idea for some kind of website or forum, but doesn't sound like a good idea for Wikipedia. WP should not include original research, so is not a good place for roughing out a thesis. I really don't agree that a 'large portion' of the articles on WP constitute arguments. Subjectivity creeps into a few articles, but it should be discouraged not welcomed. Arguments make a point about something, whereas Wikipedia articles are a thorough examination of the subject, with all statements grounded in verifiable factual sources. Comments cannot be put into an article purely on the basis that more users agree with them than disagree, or that they measure highly on the Do Good Guage.
Wikipedia is 'democratic' to the extent that anybody can add or edit content, so long as they can cite evidence where necessary; but too much democracy in terms of group decisions could be a bad thing. Remember that a lot of article content comes from people who are experts on that specific subject. Their assessment of the article content will be more reliable than somebody, or a group of people, who don't necessarily know the subject too well. Weasel Fetlocks (talk) 17:06, 27 June 2008 (UTC)[reply]
Some system that interconnects a wiki (not Wikipedia) with a forum would be handy for such a project. You might even want to look at just a MediaWiki wiki with the LiquidThreads extension for enhancing the talk pages; and probably some custom extensions to manage the voting/statistical side of things. You could always advertise in your userpage here if you want to, I guess. --tiny plastic Grey Knight 12:38, 30 June 2008 (UTC)[reply]

Wikipedia's background image

Image:Headbg.jpg is a very low quality picture. I understand it shouldn't be megabytes big, but would it hurt to have it just a little better quality? I know going from 8KB to 16 will provide a longer load time, but this should only be for the first load (as it will be stored in the cache). Or perhaps re-doing the image, and compressing it in a less lossy way would fix the artefacts? The quality of Image:Wiki.png was recently greatly improved, and is still only 16KB. — Jack (talk) 00:12, 26 June 2008 (UTC)[reply]

It's a background image, hardly noticeable. It's fine the way it is. davidwr/(talk)/(contribs)/(e-mail) 00:18, 26 June 2008 (UTC)[reply]
Only about 30% of the image is actually visible anyway; don't think this is a major issue. EVula // talk // // 16:22, 30 June 2008 (UTC)[reply]

Wikipendium

As I feel substantial concern towards many fundamental problems inherent in Wikipedia as a community and "encyclopedia", I hereby propose a social fork of Wikipedia to be called Wikipendium. Please read through the proposal, think about it objectively, and comment on the proposal's discussion page. Best and friendly regards, – Thomas H. Larsen 02:15, 26 June 2008 (UTC)[reply]

Proposing a new project would need to be directed at the Wikimedia Foundation itself. We can't do anything with that on the Village Pump, as we're just editors of Wikipedia, like you. — The Hand That Feeds You:Bite 16:45, 26 June 2008 (UTC)[reply]
The Foundation is not going to host a fork of its own project. You may independently fork, with or without permission or support from the Foundation or the community, provided you credit the authors (as required by the GFDL) of any content that you copy. — CharlotteWebb 17:10, 26 June 2008 (UTC)[reply]
If I understand him correctly, he is intending to host it himself, but just wanted to gather a few comments from Wikipedias on that page (since Wikipedia is an obvious place to do prior research). Probably he should talk to Citizendium as well, since he's using a few concepts from there too. --tiny plastic Grey Knight 13:33, 27 June 2008 (UTC)[reply]
Exactly. – Thomas H. Larsen 03:09, 30 June 2008 (UTC)[reply]

Wikipediakids

From this discussion Emmanuelm came up with the idea of Wikipedia for kids (lovingly called "wikipediakids") and I strongly support this idea; Wikipedia is not censored, and it should be that way, but it leaves us with the problem of possibly leaving out an internet minority with unsuitable content. If "wikipediakids" was considered and debated, I propose this set of basic prinicples that would differ from the 'pedia we know and love:

Censorship and such
  1. Articles would be suitable for children, with attention taken to also preserve the range of content that the site would offer. I.e, Sex would not be an article, but Mother and Father would be. (if that doesn't make sense, please harrass me)
  2. Pictures would be appropriate and self explanatory.(see below)
Article clarity and readibility
  1. Articles would essentially be lengthened introductory paragraphs. This would allow the length of the article to be reasonable, and the content understandable. They would alos be linked to the full length article on en.wiki, that way they could "advance" if you will.
  2. Pictures and other media would be self-explanatory and would attract the attention; I'm almost certain that most youngins understand more effectivly with a pictorial representation.
  3. Length (going into greater detail) would be a heavy issue on WikiKids. The article would have to be a readable size, maybe the equivilant of a long stub?
Vandalism
For fairly obvious reason (I hope), the vandalism that is rampant here (specifically that with homophobic/vulgar content) can not be evident there. It would ruin the entire purpose, and for this problem I present these solutions:
  1. Only registered users on en.wiki can edit.
  2. Those who want to edit on WikiKids have to be reviewed or approved by an admin.
  3. All uploaded files would be reviewed, then posted.
  4. New pages have to be run through a couple other users.

That's all I can think of. Tell me your ideas! Or crush mine, either/or. Leonard(Bloom) 03:34, 27 June 2008 (UTC)[reply]

You can't really just say "pictures will be self-explanatory" and have it be so - we restrict ourselves to freely licensed media, so we're stuck with what we can get. If such a project were to be hosted by Wikimedia, or use the Wikipedia name, I assume it would have to use free media too. And doesn't linking back to the Wikipedia article somewhat defeat the purpose, to keep the kids separated onto a "safer" site? Finally, to truly eliminate vandalism (or make it really unlikely, at least) you'd have to either have trusted users approve every edit before it goes live or have very strict requirements for who can get approval to edit, which would dramatically reduce your potential userbase. Mr.Z-man 03:44, 27 June 2008 (UTC)[reply]
That bit about freely liscened media makes sense, and I overlooked that. Hm... I'll ponder that bit later. Moving on, the linking back issue I wouldn't say is self-destructive; linking back allows for more information at the risk of unsuitable content. Maybe a warning page when you the link or something? Like a redirect to a warning, then "continue? yes/no" bit. As for the vandalism, as you kinda said, there is always a human factor, but assuming good faith and having tighter vandalism watches (again, that is assuming people are willing to volunteer; I would) would help. I hope that helps clear some things up. Leonard(Bloom) 03:59, 27 June 2008 (UTC)[reply]
So, no images of the Prophet then, right? That could be damaging to some of the little tots. No pictures of anyone in a bra, in fact, we better not have anything about brassieres or breasts. And what's with that bit about not being homophobic, that sounds like homosexual recruitment to me. Of course, nothing about any ideas of how religious education affects children and certainly nothing that would indicate controversy about the way children are educated in any province, state or country. A whole lot of articles about disease would have to be changed to "It's going to be fine, just take the medicine".
I support none of what I've just said, but any one of them are illustrative of the absolute minefield of setting out to produce a Wikipediakids. We can barely figure out what's good for us adults. It's a noble idea, but to follow Z-man's comment on having trusted users - who defines which users are trusted to approve the content? The reality of parenthood is that everyone has their own specific idea of what is right for their kids. I can see problems arising on many levels. If you can figure out a way to extend the encyclopedia to be used by younger users though, more power to you! Franamax (talk) 06:03, 27 June 2008 (UTC)[reply]
It's doubtful that the Wikimedia Foundation themselves would want to do it — the Wikipedia is probably as far as they want to go into the content-segregative kind of thing. Of course, you can always fork it yourself. :-)
I'll ask User:NonvocalScream to chime in here, I believe he's looked at some similar underlying concepts in the past and might be able to offer some constructive suggestions on how to avoid the "telling people what to do" trap.
--tiny plastic Grey Knight 13:27, 27 June 2008 (UTC)[reply]
There's already the Simple English Wikipedia. That's kind of a precedent for content-forking, although that's on language grounds. I'd be quite strongly in favour of a wikipedia with child-accessible articles (in terms of simple and friendly explanations, writing style, and general idiom), but I'd be extremely opposed to any kind of promise that it'd be non-offensive - I don't like either a) the concept of censorship to avoid any potential offence whatsoever, or b) the prospect of the aftermath of the inevitable slipups. Pseudomonas(talk) 15:58, 27 June 2008 (UTC)[reply]
There are parental controls that most Internet browsers have, so parents could just use those to block out uncensored material on Wikipedia. RedThunder 16:49, 27 June 2008 (UTC)[reply]
Basic response to the above comments, respectivly:
  1. "Trusted users" means having someone review anyone who wants to help WikiKids. Like getting rollback; you post your name and reason and you get a response. As for the "minefield" bit, I think it would be relatively easy to set out what would be appropriate and not; sexual or morally taboo topics would be excluded, but, would be connectable through links to en.wiki. But I may be dumbing down the whole process.
  2. Yeah, I doubt this idea will ever reach Jimbo. But, who knows? It's not quite a snowball.
  3. A child accessible wikipedia is a great idea, and it might make more sense in the long run than WikiKids. I don't support censorship either ("Censorship is like banning steak because a baby can't eat it" -Mark Twain), but I feel Wikipedia might be losing out on potential viewers by refusing the censor. I'm am not saying Wikipedia should be censored, but an alternative should be offered.
  4. No response comes to mind. Sorry. The response are much appreciated, and I hope to see this idea debated and reviewed. Leonard(Bloom) 19:36, 27 June 2008 (UTC)[reply]
I like the concept... perhaps a suggestion would be to open another free content encyclopedia, another project. "English Wikipedia for youngsters" or something similar. The new project (if approved and set on incubator/meta) would require work from the ground up as far as guidelines, and content guidelines go. But perhaps an offshoot of wikipedia here is not a good idea, rather, consider if another wikimedia project aimed to be targeted to kids (that is to say, the audience for that project pedia is kids). Each project has the ability to set how it runs. This would perhaps be the way to avoid violating the integrity of this encyclopedia (The English Wikipedia). Consider proposing a new project on meta. Thoughts? NonvocalScream (talk) 03:09, 28 June 2008 (UTC)[reply]
"Kids" is a pretty broad target demographic - would we try and aim it all kids, or have different wikis or some other kind of wall between content for 5-10 year olds, 11-14 year olds and 15-18 year olds (for example)? As for your vandalism concerns, WP:FLAGGED revisions could be of some help were this to come to fruition. — Matt Eason (Talk &#149; Contribs) 21:33, 28 June 2008 (UTC)[reply]
Kids would be a self-defined demographic, with the deciding factor being parents; the children (or parents) would decide if they want (or their kids) to see the unsuitable content on en.wikipedia. Also, WP:FLAGGED is a great addition, and thanks for the comment! Leonard(Bloom) 00:47, 29 June 2008 (UTC)[reply]

It's a tricky one. The point of Wikipedia is that anybody can edit it, but should always verify information with citations, & their edits may be challenged by other users. That doesn't translate too well for children, who are unlikely to be able to follow Wikipedia's rules and guidelines on content, editing, style, references, etc. & If all those rules were relaxed, so that (for example) children could add unreferenced content & POV comments, it would quickly degenerate into a very poor quality encyclopedia. If, on the other hand, WPKids was edited by adult users, & children themselves could not edit it, it would not be significantly different from any of the children's encyclopedias you can get on CD-Rom. Weasel Fetlocks (talk) 14:18, 29 June 2008 (UTC)[reply]

A thought occurs: instead of building a whole new wiki for the kids' version, why not just make Wikipediakids as an interface for using the existing Wikipedia database. It could have more kid-friendly graphics & start from a simple search page. A search would then bring up the relevant article from Wikipedia, but displayed within a Wikipediakids window, which could maybe also have a Wiktionary search field in it too, so that kids could instantly look up any words in the article that they don't understand. I'm sure it would be very easy to put 'blocks' in, so that Wikipedia articles on certain subjects (e.g. sexual subjects) could not be viewed through a Wikipediakids search. Weasel Fetlocks (talk) 15:05, 29 June 2008 (UTC)[reply]
That idea is probably the most practical of this thread, and I think it could be easily done. Would it be too much to ask for a "support" or "oppose" at this point? I wanna see if this idea could go anywhere. Leonard(Bloom) 17:39, 29 June 2008 (UTC)[reply]
Oppose all attempts at 'windowing' Wikipedia in-situ. What you do with a forked copy is up to you. But here on Wikipedia, don't be a WP:TOBY. Splash - tk 12:57, 1 July 2008 (UTC)[reply]

The Pocket Wiki

I am not sure if I am contacting the correct people, but I have been sitting on this idea and I thought I would send it to you guys, on the off chance that you had not heard it yet. I had the idea of the invention of the "Pocket Wiki", a portable cell phone sized apparatus that contains the text available on Wikipedia.com, for all subjects. Without the pictures, I would imagine that the information could be stored on such a device. It would provide the user with a screen, a small keyboard of sorts in order to sift through the information, and access to all information that is posted on Wikipedia. The caviot would be that it would also have an extendable USB Drive of sorts or a place to plug in a USB Cable, so that when plugged into a computer, it would sync with any new additions that have been made to Wikipedia since the last time it was synced, much like an iPod.

My friends and I are constantly calling each other, asking the other if they are near a computer so they can check something on Wiki and I have a book I write down things I want to look up when I get home or when I get close to a computer with internet access so I can check Wikipedia. It is also my homepage; Wikipedia.org.

I am sure something like this is already in the works, but I just wanted to write this so that I knew and could maybe get some closure that it is. Some may say that the internet on the phones would make this obsolete, but the technology that is available now is slow and such a small portion of the populous have it that it would still be a viable investment for the next 5-8 years in my estimation, until they make the internet on the cell phone cheaper and much quicker. A Pocket wiki would simply be something someone carries or keeps close to them to look up pertinent information when the situation called for it and they could get it immediately.

Just a thought

Thanks for the time

Patrick J. Masters > —Preceding unsigned comment added by Sdpatmasters (talkcontribs) 17:09, 27 June 2008 (UTC)[reply]

I don't know of any devices with a hard coded version, but you can access Wikipedia from devices such as the Amazon Kindle, cell phones and PDAs. See Wikipedia:WAP access. --—— Gadget850 (Ed) talk - 17:26, 27 June 2008 (UTC)[reply]
There is something similar to this in the making, see here, i imagine when released it will be possible to get versions for pda's--Jac16888 (talk) 20:20, 27 June 2008 (UTC)[reply]
If you have internet access on your cell phone, you can use that. bibliomaniac15 00:04, 29 June 2008 (UTC)[reply]
There are already downloadable versions - see WP:EIW#Mobile. -- John Broughton (♫♫) 14:36, 1 July 2008 (UTC)[reply]

Proposal: Allow established/experienced editors to see deleted contributions

A number of editors have been around for years and have made thousands of edits, but are not necessarily interested in becoming admins. Nevertheless, such editors do participate in deletion reviews and requests for adminship discussions where seeing deleted contributions would indeed be relevant and helpful to assess the articles and candidates under discussion. Therefore, I propose that we come with a criteria by which established and experienced editors who have been editing for years and who have thousands of edits be able to see (not undelete, just see) deleted contribs for the purposes of such discussions. I am sure that it is somehow technologically possible to allow such editors to see the contribs without tacking on the undelete function. Sincerely, --Le Grand Roi des CitrouillesTally-ho! 20:07, 27 June 2008 (UTC)[reply]

I think this would be a good idea, it is somewhat difficult to decide whether or not an article should have been deleted if you can't actually see that content--Jac16888 (talk) 20:16, 27 June 2008 (UTC)[reply]
  • It is important that COPYVIO, BLP, and other things be kept under tight control. Before I would go along with any such proposal, it would have to be limited to certain articles, for a certain length of time. A "deletion reviewer" userright that would allow access to articles actively undergoing deletion review makes sense. A separate userright that would allow access to deleted edits made by a person in an RfA or other rights-elevation process also makes sense. For deleted articles, this would show just the edits made by RfA candidates and the immediate preceding edit for comparison, not any other edits. If there is no RfA-style vote, then limiting both rights to people who have both an old account with many edits and a recently-active edit history also makes sense. I would recommend such rights automatically expire after 6 months, with nearly-automatic renewal if the person is still an active editor and asks that the right be renewed. Defining "active editor," "old account," and "many edits" is something that can be hashed out later, but I would recommend at least 6 months, several thousand edits, and at least 100 edits in the immediate past 6 months. I know this sounds complicated, and it is, but creating a class "read only admins" that have access to all non-oversighted deleted edits is neither necessary nor desirable. davidwr/(talk)/(contribs)/(e-mail) 21:08, 27 June 2008 (UTC)[reply]
  • I think for myself as the iniator of the thread, I have over 20,000 total edits, have been editing since 2006, have rollback rights, but although several editors have offered to nominate me for adminship I have so far declined as I really focus on non-admin areas. With that said I do think that my comments in RfAs and DRVs would be more intelligent if additionally based on deleted contribs. Plus, even personally, I have never and would never made any copyvio or BLP edits and so think I should be able to see the totality of my contributions. Best, --Le Grand Roi des CitrouillesTally-ho! 23:24, 27 June 2008 (UTC)[reply]
  • Just so you know, I wasn't saying that the process should be exactly the same as for AWB, but just that the process' be similar. i.e. Come up with a set of "requirements", then if someone wants those abilities, they apply at a page (like for AWB), and in most cases they are granted. This would make sure that there is some approval process, but it's not as involved as RfAs. -- Imperator3733 (talk) 19:21, 30 June 2008 (UTC)[reply]
(ec) Let's not get over-restrictive on this. Established editors have enough sense to avoid spreading blp and copyvio--and if they try to reinsert it they will soon no longer be established editors. If we're concerned about they're using it elsewhere, there are enough other ways to get deleted comment if one wishes to be in bad faith. I see no reason not to let anyone with a good reputation here have it, with an appropriate warning about what not to do with it. The material that is really sensitive is oversighted--since we dont fully trust all 1500 of the admins to be sensible 100% of the time either.
A six-month restriction is absurd, because we've made people full admins with less experience than that if they do things right. AWB requires 500 edits in mainspace, and anyone who does that much work successfully is probably trustworthy enough for this very limited purpose. But if this is to be an automatic right, not a screened right like AWB, yes, it should be a little higher than that. And some of the uses suggested by arb com do not require large amounts of experience in mainspace, unlike most of what AWB can do.
Additionally, any editor should be able to see the edits they hav themselves contributed. It simply doesnt make sense not to. 23:31, 27 June 2008 (UTC) — Preceding unsigned comment added by DGG (talkcontribs) 23:31, 27 June 2008 (UTC)[reply]
I mentioned COPYVIO and BLP not because they are likely to be reposted, but because if copyrighted material is made available to more than a select few, it can invite a copyright lawsuit. Likewise, if BLP material isn't deleted from view, it can invite a libel lawsuit. Now, the reality is, many BLP and COPYVIO items are in non-deleted edits that are open to every Internet user on the planet, so the risk of a lawsuit may not be all that high. However, we should at least recognize the possibility before proceeding. davidwr/(talk)/(contribs)/(e-mail) 23:45, 27 June 2008 (UTC)[reply]
I think though if it is okay for admins to see the stuff, then those with as many contributions as admins who do participate in DRVs and RfAs should be able to also see these contribs (it would of course still be an overall limited number of editors) and as DGG or someone else said we really should be able to at least see the totality of our own contributions. Best, --Le Grand Roi des CitrouillesTally-ho! 00:08, 28 June 2008 (UTC)[reply]
Surely it would be better to use the rollback tools system of approval, it seems to be working fine, and since this is an admin tool too, it makes more sense to have a similar set-up--Jac16888 (talk) 23:37, 27 June 2008 (UTC)[reply]
The key difference is rollback and AWB don't grant any new powers, just a new convenience and the ability to really mess things up in a hurry rather than slowly. Granting the right to see deleted material is significant, done in the extreme it's equivalent to "backup operator" permissions on a computer. This is why it should be reserved for either people approved by the community a la RfA or to people who are not just trusted not to make mistakes, but trusted not to misuse information that is hidden to the masses. I know we aren't talking visibility to WP:OVERSIGHTed edits, but we are talking seeing what most can't. davidwr/(talk)/(contribs)/(e-mail) 23:51, 27 June 2008 (UTC)[reply]
I don't see why the present system of having an admin–many of whom say on their userpage that they are happy to do it–allow users to view deleted material on request is insufficient. Phlegm Rooster (talk) 00:00, 28 June 2008 (UTC)[reply]
Skipping the middle man saves time and is more efficient. There's no reason why established editors should not be able to see all of their contribs. Sincerely, --Le Grand Roi des CitrouillesTally-ho! 00:03, 28 June 2008 (UTC)[reply]

Please, someone, centralize this discussion. I've posted quite heavily on this subject at the Wikipedia_talk: page, but it would seem that that is one of multiple places this discussion is taking place. Only one page is needed. Pick one please, and merge the two pages. --MZMcBride (talk) 03:31, 28 June 2008 (UTC)[reply]

I'd say that the fragmentation is not intentional: the ArbCom discussion is (or should be, anyway) about the commons-admins-seeing-our-deleted-images issue, which is only tangentially connected to this discussion. Discussion on a new en.wiki right to see deleted contributions, which is what this is, should be kept in this thread. Happymelon 21:23, 28 June 2008 (UTC)[reply]
I don't think the commons issue is even mentioned in the arbcom page, and was only mentioned in the first section on the talk page. That proposal is for a global right and is being discussed mainly on meta. Mr.Z-man 22:30, 28 June 2008 (UTC)[reply]
I'd be very interested in a slightly enlarged set of userrights, without having all the admin rights. I have no wish to block users ever, or deal with page protection; but I'd often find it helpful if I could view deleted pages/images. The other two items from the WP:UAL#Table list which I would be interested in include "editprotected" and "unwatchedpages". -- Quiddity (talk) 20:13, 29 June 2008 (UTC)[reply]
What, you don't want the "all-you-can-eat" option? And we're doing a one-day-only 2-for-1 offer on oversight: buy hiderevision, get checkuser half price!! :D In seriousness, there are a number of admin permissions that I would like to see broken out, but not into separate groups a la rollback, ipblockexempt, etc. Why are we so ideologically opposed to a 'trusted' usergroup (with a nicer name, of course). Bundle rollback, accountcreator, deletedhistory, noratelimit, edit-semi-protected, unwatchedpages, and a handful of others together and dish it out like rollback: you get someone who is equipped with all the admin tools that don't have sharp edges, and you leave the admins free to handle the 'big three' of protect, delete and block. Happymelon 20:26, 29 June 2008 (UTC)[reply]
Looking at the API usergroups list, the less dangerous admin rights are: deletedhistory, import (unused), move-subpages, autopatrol, proxyunbannable (unused), rollback, trackback (unused), reupload-shared (not sure what this does, may be unused), unwatchedpages, upload_by_url (seems to be disabled?), ipblock-exempt, markbotedits (for rollback), suppressredirect (currently unused), apihighlimits, browsearchive, noratelimit, tboverride, override-antispoof, and uboverride. Mr.Z-man 03:48, 30 June 2008 (UTC)[reply]
I agree with Happy-melon's idea for a "trusted" user group. This group could be given to experienced editors who don't feel ready (or don't want at all) to be an admin. The current rollback group could be merged into this group as well. -- Imperator3733 (talk) 19:30, 30 June 2008 (UTC)[reply]
For various reasons, I like the idea of a "trusted" group too - given anyone can get an account, a standard not needing RFA, simply to say "this person broadly has the idea and even if not perfect edits mostly decently". Roughly, it ties in with high risk vs. low risk, and also may mean a user who wants that, knows there will be some review of their reputation and work, and hence that it may mean a bit more to build a good rep and do good work :) FT2 (Talk | email) 23:08, 3 July 2008 (UTC)[reply]
The only problem is that besides the ability to view deleted content and rollback and perhaps autopatrol, most of the "safe" admin rights are either unused (import), rarely used (markbotedits), not very helpful (unwatchedpages), or bypasses for disruption-prevention measures (tboverride) that the vast majority of users may never need. Especially if we choose not to bundle the deleted history rights with this, it would basically be nothing but a status symbol. Mr.Z-man 23:37, 3 July 2008 (UTC)[reply]

In reply to above, the present system of admins saying they will give copys of deleted articles is with caveats. No copyvios, no BLP, nothing that would be inappropriate for the general public. I know I have deleted, and I have seen deleted information in articles that is not suitable for the masses or the average editor to have access to. As for the average editor seeing their deleted contributions, I don't think that is what this proposal is for. This is for people with a genuine need. Curiosity is not a genuine need. The idea of skipping the middle man is moot for the reasons I have just mentioned. If this going to be implemented the requirements would be on par with a successful RfA. Community trust, no real history of blocks or abuse, etc. I think if someone wants this ability they need to demonstrate they could pass an RfA if they attempted one. KnightLago (talk) 19:07, 3 July 2008 (UTC)[reply]

A general comment: First off. I think this is a brilliant idea. I think there should be a barn star for this proposal! In reply to KnightLago: Hi KnightLago. I respectfully disagree. Here is the reason. I would like to use this feature myself but in the past I've been block. I've been blocked personally for several reasons which, now that I think about it, may have been justified. However, anyone, that has enough experience to have been blocked, such as myself, must surely know what the concensequence are if they violate the trust of the community. For example, using this new feature for disruption would most likely be considered an automatic block. I can think of many other examples but one that comes to mind is an editorial dispute over content. Such disputes would be dealt with by our current channels (Admins) who could easily permanently or temporarily take away the privilege of going back into deleted page history. Also, I think an RfA is pretty much a load of crap of politics which really doesn't apply for this privilege. (I am a little biased though since my RfA failled many a years ago. Nevertheless, I too don't really have an interest in being an admin right now and think it's a great idea for experienced users to be able to check deleted pages. In particular, I think experienced users (8000 edits or more during a period of 2 years. The 2 years in mandatory.) should be permitted access to all deleted pages. Less experienced user (let's say 2000 to 7999 edits or 1 year of experience (we could also add closes like: despite the fact that they may have been editing for more then 2 years they must meet the edit number)) should only have access to content which they specifically help contribute. (The reason I say less experienced users is because, sometimes, in my case, I remember making a new article (just in May 2008) and honestly believing that it could make it. (See User:CyclePat/Rhumart). I had to request that the page be moved to my user page and then make another request so I could merge the information to Free World Trust v. Électro Santé Inc.. And on top of that there was some more melodrama that I added because I was the only editor because I tried having the content speedy deleted, and tried moving the page myself to my own user page. Anyways... I just wanted to share this story with you because I think it's a relevant example of how we can cut back on melodramatic administrator who want to follow procedures by the book. In my case, the admin could have deleted the page, and I could have then userfied it myself. Finally, I think new editors shouldn't have access because they may not completely understand wikipedia's policy, may be trolls, etc, and may likely simply recreate the same page again. --CyclePat (talk) 17:54, 5 July 2008 (UTC)[reply]

FWIW, The software support for tiered deletion is pretty much done, though it's still in code review and not turned on yet. Once its activated deciding how to use it is up to the community. Cheers. --Gmaxwell (talk) 20:35, 3 July 2008 (UTC)[reply]

I think the tiered deletion system should be used to divide up deleted content. The "Trusted" user group could have access to anything that was deleted because of notability issues, etc. Copyvios and BLP stuff could still be only visible for admins. I can't think of anything that's wrong with estabished/experienced users seeing information with notability issues, and they might be able to find something notable about it. I've made a few articles that were speedy-deleted because they weren't "notable", but I still believe that they should be included in Wikipedia. Giving established users access to this content would help Wikipedia and not have many (if any) negative effects. -- Imperator3733 (talk) 01:10, 4 July 2008 (UTC)[reply]

Transcludable XfD discussions

I propose making all XfD discussions subpages that are transcluded, not just AfD and MfD (meaning CfD, TfD, and SfD). I understand that these discussions get much less traffic, but they would get far more if people were able to add them to the appropriate deletion pages (like Wikipedia:WikiProject Video games/Deletion), which are designed only for transcludable subpages. I can see no downside to this, and they would work better with our current structure. JohnnyMrNinja 00:26, 28 June 2008 (UTC)[reply]

  • Strong Support. This would also help WP:DS, which is a major WikiProject. MrKIA11 (talk) 00:48, 28 June 2008 (UTC)[reply]
  • Support I would find it extremely valuable to have these pages as subpages if only so I could watch discussion I was active in. Adam McCormick (talk) 00:59, 28 June 2008 (UTC)[reply]
  • Support it would also make it easier for newbies if they do not have to navigate a very complicated page and can instead use a preloaded debate page like the one provided by {{AFD}}. -IcewedgЁ (ťalķ) 01:00, 28 June 2008 (UTC)[reply]
  • Comment While I'm not unalterably opposed, I'm not at all convinced that this is a good idea for SfD. SfD is already transcludable at the day level and it's rare for more than a few unrelated stub types to be brought to nomination. Even for a basic SfD nomination there are such a large number of possibilities (template to be deleted, template to be renamed, category to be deleted, category to be renamed, template to be upmerged with category deleted, template and category to both be deleted, and template and category to be renamed) relative to the number of nominations that I cannot see preloaded debates as being useful to SfD. Given the vast range of possibilities, if SfD were to adopt such a scheme, it would likely have to be something along the lines of Wikipedia:Stub types for deletion/Log/2008/June/26/1 with the discussions individually numbered for that day. Given the usual nature of the fourth level headings on SfD, trying to use those for the subpage discussions would be extremely problematic. Caerwine Caer’s whines 02:31, 28 June 2008 (UTC)[reply]
  • Support The XfD system is horribly unstandardized, this would be a good start. I would suggest doing DRVs as well. Mr.Z-man 03:36, 28 June 2008 (UTC)[reply]
  • Partial support. I agree with Caerwine. Though it does make sense in general terms, and certainly may simplify matters at TfD and CfD, it is likely to increase rather than decrease complexity at SfD due to the varied nature of possible options. A halfway measure (with pre-templated discussion headings but without preloaded debates) might work, though the items nominated 9which may be templates, categories, or a combination of the two) may lead to other difficulties with that. Grutness...wha? 06:58, 28 June 2008 (UTC)[reply]
    • I agree that I cannot see pre-loaded debates working for SfD, but what about the basic idea of transcluded subpages? I also agree that many times it may not make things much better, but for the occasion that it does, I think it'd be worth it. This way we can be sure that every SfD is brought to the attention of the appropriate WikiProjects. Also, watching just one (when there are several) is nice. JohnnyMrNinja 20:07, 28 June 2008 (UTC)[reply]
  • Support I can't see a downside either.--Fabrictramp | talk to me 14:48, 28 June 2008 (UTC)[reply]
  • Oppose for Deletion Review I can't support this for deletion review. I (and I believe other regulars there) keep each days log on my watchlist, there are rarely more than 5 reviews per day and this enables the keeping an eye on all DRVs. Having templates for each one would make this more complex not less and often DRVs are resolved quickly (e.g. contested prods) and would mean a lot more adding to watchlist then taking it off quite quickly. Also categorising them by subject would be much less useful at DRV as often the discussion is more about the process taken. Davewild (talk) 21:00, 28 June 2008 (UTC)[reply]
  • Support for TfD and CfD. No one has objected to expanding the approach to these two discussion types, but there seem to be good arguments against SfD and DRV. -- John Broughton (♫♫) 21:31, 28 June 2008 (UTC)[reply]
  • Oppose for DRV. We get a reasonable fraction of our nominations by editors that lack the right to create new pages. The AFD system prevents IP editors and new editors from making AFD nominations because they can't create the page for the discussion, but at least dumbbot can complete a nomination started by putting a template on the article - it can't do that for DRV where the page to be reviewed is normally deleted already. Mu for the rest. I've seen CfDs and TfDs, though rarely, linked on a Wikiproject deletion sorting page. I've never seen a RfD, SfD, or DRV linked there. First show evidence that the deletion sorting wikiproject and its users actually link to these discussions widely. If only a few projects want to follow up on these discussions; they can do the work it takes to have meaningful links on their pages. GRBerry 00:57, 29 June 2008 (UTC)[reply]
  • Comment - Okay, so it is pretty clear that the proposal for CfD and TfD meets with no strong opposition (correct?), so I think that is pretty much settled. The subpages for SfD would cause problems due to inconsitancy of naming and content, so making subpages would be awkward. DrV would be problematic due to article creation, and most are resolved quickly and do not need project involvement (correct?). So I am going to consider CfD and TfD resolved, and create a new proposal for everything else (directly below). JohnnyMrNinja 04:39, 30 June 2008 (UTC)[reply]
  • I don't particularly have an opinion about the other ones, but I agree that DRV should remain the way it is. seresin ( ¡? ) 18:40, 1 July 2008 (UTC)[reply]
  • Strong support for CfD; as mentioned above, this pretty much is in line with the opinions expressed so far. Good Ol’factory (talk) 08:01, 4 July 2008 (UTC)[reply]

I have never done anything like this before, so forgive me if I progress awkwardly. I think it might be best to start with WP:CfD, and once that is completed move on to WP:TfD (though I am not opposed to progressing in a different manner). I have created Wikipedia talk:Categories for discussion/Transclusion for the purposes of making these edits to essential project pages. I ask for any and all help, as I have little idea as how to properly go about this. As most of the changes will need to be in the Template namespace, and I know scarily little about templates, I will very much relying on help and the knowledge of others to see this through. Thanks to everyone who everyone who participated in this discussion! JohnnyMrNinja 09:59, 4 July 2008 (UTC)[reply]

Deletion/Discussion template

What about a standard template for all other XfD discussions (excluding AfD, MfD, CfD and TfD) that simply links to the section of the discussion on the appropriate project page? It would simple, and would only need to be used if the need were felt to create a broader consensus from the appropriate project. Something that looked like -

SfD - {{Lauenburg-geo-stub}} / Category:Lauenburg district geography stubs (edit|talk|history|links|watch|logs)

This could be used for WP:SfD, WP:DRV, WP:RfD, WP:IfD, and WP:UCfD if and when more attention is needed. It would require no change to the Deletion pages, and would give (close-to) the desired result. The main thing is, as it would only be used as needed, it shouldn't get in anyone's way. Thoughts? JohnnyMrNinja 04:39, 30 June 2008 (UTC)[reply]

No comment on the rest, but for DRV we already use {{newdelrev}}, which includes the "(edit|talk|history|links|watch|logs)" already, and has some extras due to the nature of the process: "(restore|cache|AfD)" (the last of which is common changed or added to when necessary). If a standardized template is created for this, I'd suggest a "|drv=1" parameter be used to add those features on (or to redirect to {{newdelrev}}). Cheers. --lifebaka (Talk - Contribs) 11:29, 1 July 2008 (UTC)[reply]

Hello. This template's table style must be changed. Because, all page in main namespaces must use article message boxes, and tihs page uses diffrent style. We must use Ambox mini style.

  • Here is the code;

{| class="ambox ambox-mini ambox-notice" |class="ambox-image"| |style="font-size:83%;line-height:1.6em"|This article contains Chinese text.
Without proper rendering support, you may see question marks, boxes, or other symbols instead of Chinese characters. |}

  • And preview;
This article contains Chinese text.
Without proper rendering support, you may see question marks, boxes, or other symbols instead of Chinese characters.

Thank you.Srhat (talk) 13:38, 28 June 2008 (UTC)[reply]

No, it should not be changed. The ambox style is for article message boxes, for temporary tags on an article. Permanent templates should not use the ambox style. {{Nihiltres|talk|log}} 14:07, 28 June 2008 (UTC)[reply]
OK.Thank youSrhat (talk) 17:07, 28 June 2008 (UTC)[reply]

Merge all Wikimedia wikis

I suggest merging all the Wikimedia wikis into a single wiki, because:

  1. There is significant duplication of content between the sister wikis
  2. It is currently not possible to search all the individual wikis in one go
  3. Merging the individual brands into a single brand name will make the brand more popular than any of the individual brands.

-- Masatran (talk) 14:24, 28 June 2008 (UTC)[reply]

Both theoretically, and practically impossible, and even if it was possible, it contains no logic at all, as different wikis have different languages, which language over-rules other languages?. AzaToth 14:41, 28 June 2008 (UTC)[reply]
Also, different sister projects have different agendas, that should not be mixed. AzaToth 14:42, 28 June 2008 (UTC)[reply]
It is possible searching (and even machine-translating) all individual wikis in one go by using Qwika. JoJan (talk) 14:48, 28 June 2008 (UTC)[reply]
  1. Regarding the languages: the user interface language can be chosen from content negotiation.
  2. The use of keeping the languages together is that, for example, Wikipedia itself would then be able to provide multiple-language-wiki search. Results can be restricted to a list of languages specified by the user.
  3. Basically, we need an equivalent for Qwika within Wikipedia.
  4. The agendas of the sister wikis have more similarities than they have differences. Currently the user is confused as to which of the sister wikis is relevant for her subject, as there is too much overlap.

-- Masatran (talk) 19:28, 28 June 2008 (UTC)[reply]

Theres no way at all this is going to happen. ever. Even if you managed to get some form of consensus on here, the foundation would never agree to it. Merging them all would result in a massive disaster. The whole idea of the different projects is that it splits the workload, just like the wikiproject system. Merge them all and suddenly we have a mass of pictures, quotes, free source, free books, dicdefs, news articles and free content all in 246 different languages, with each wiki bringing their own policies and rules, who decides which policies are made top, consensus wouldn't work because each projects users would support their own policies. Then we have the sysops, in smaller projects, its a lot easier to be a sysop simply because they need them, a imagine they would never pass an rfa here. do we desysop them? if we do then who will look after the bits that were part of their project? As for the brand, i really don't think wikipedia has a problem with not being popular enough. And yes there is signicficant duplication of content. In different languages, which is the whole point.--Jac16888 (talk) 19:44, 28 June 2008 (UTC)[reply]

This should have been split into two proposals: one to merge all the sister wikis, and another to merge the different language wikis. -- Masatran (talk) 19:48, 28 June 2008 (UTC)[reply]

I hate to be rude but it really shouldn't be because either way, its a preposturous proposal and will never ever happen, if its even at all possible. No offence, but you're wasting your time--Jac16888 (talk) 19:58, 28 June 2008 (UTC)[reply]

Wikipedia is popular enough. It is its sister wikis that do not have enough popularity. Merging them into Wikipedia would give them a much larger audience. --Masatran (talk) 20:00, 28 June 2008 (UTC)[reply]

(several edit conflicts later...) Can you give an example of the "significant duplication of content" you're talking about? I don't use any of the sister wikis much so I'd be interested to know. We do use InterWiki links when there's relevant content on a sister wiki, but maybe we could do more. Interwiki search would be cool, but there are other ways of doing it, as JoJan pointed out. I would be extremely sceptical about merging them into a single wiki. Apart from the fact that it would likely be a technical nightmare, I can see it causing far more problems than it would solve, and I'm not sure that it would solve any. If you're actually proposing a single unified wiki rather than some kind of portal, there would be significant problems with merging several huge, mostly-disparate communities, all with varying policies, guidelines and customs. — Matt Eason (Talk &#149; Contribs) 20:01, 28 June 2008 (UTC)[reply]
As others have said, this is practically impossible, I don't want to imagine how difficult it would be on a technical level to merge hundreds of different databases into one. What happens to user accounts? We're running into problems implementing single user login because users on multiple projects share the same username and neither wants to change their name, this would require many forced renames. What about instances where projects have pages with the same title? For example, an article about a person on Wikipedia and quotes from that person on Wikiquote, would they be merged, would one have to change names? What about policies? Would pages follow a different set of policies depending on what type of content they have? There are similarities, but there are also incompatible differences. Wikinews allows original reporting and Wikiversity allows original research, but Wikipedia doesn't report the news or allow original research. The English Wikipedia allows non-free images to be used as fair use, but other Wikipedias and projects like the English Wiktionary don't allow fair use images. And of course, if we merge everything together, we really aren't an encyclopedia anymore and we would have to change the name to something completely new. Mr.Z-man 20:09, 28 June 2008 (UTC)[reply]
Procedural note: This utopic (or, as I see it, dystopic) suggestion should go to Meta, where it can be deconstructed appropriately and by the rules. I can understand why people see the English Wikipedia as the flagship of the Wikimedia Foundation, but we are only responsible for our own affairs. Waltham, The Duke of 07:28, 29 June 2008 (UTC)[reply]

Wikimedia School Team

The Wikimedia School Team has been founded to develop positive relationships between schools and the Wikimedia Foundation. Its first project is outlined here. to help out, just sign up on the page. Geoff Plourde (talk) 22:31, 28 June 2008 (UTC)[reply]

History of people, places, or things

Should the idea of adding the foundations and/or history of the different clauses for Wikipedias' vast amount of articles be pre-dominately included? I have what seems to be a problem in this respect. I believe a brieg history (one or two paragraphs) should be included even though there might be a seperate article representing the history of any particular article. If not, should the brief history-outline be included in the summary at the top of the page, or am I way off base here? Thank you for your time. InternetHero (talk) 21:56, 28 June 2008 (UTC)[reply]

Universal navigation bar to go with unified login

I've searched and searched and can't find this topic so apologize if its already been discussed. Anyway I'm one of those editors who jumps around all Wiki projects to do various things, most commonly being using commons to upload files and linking them with WP (I do voice acting for Spoken Wiki). Since the system already registers my unified login and knows which projects I'm linked to, can you guys develop an icon nav bar that shows each wiki project I'm registered with so i can jump to that wiki right away? I know this is me being lazy but if I'm at a remote computer, then this would be helpful. I think of it akin to GAP and how it owns multiple clothing store sites and its websites are unified by a navigation bar. The best name I can come up for this is Unified navigation bar or Trans-wiki Navigation .:DavuMaya:. 20:33, 29 June 2008 (UTC)[reply]

It sounds like a good idea, and I can't think of any draw backs. Leonard(Bloom) 02:47, 30 June 2008 (UTC)[reply]
File:Unicode 25BE 28x26 01.gif my userpage my talk my preferences my watchlist my contributions log out
Perhaps a gadget that adds a little drop-down arrow where you can jump to one of a (configurable) set of projects... --tiny plastic Grey Knight 12:05, 30 June 2008 (UTC)[reply]
I was thinking of the actual icons themselves lined up in a row before the user name but I realize that would present width issues with smaller browser. A dropdown is ok (for some reason I despise drop downs!) but would it work universally on other browsers or run into conflicts? .:DavuMaya:. 16:30, 30 June 2008 (UTC)[reply]
This is a good idea. It could be similar to the Windows Live services where you can link multiple accounts and there is a dropdown menu that can switch between accounts. It seems like it would be easy to do, plus there are many sites that have things similar to dropdown menus. -- Imperator3733 (talk) 16:36, 30 June 2008 (UTC)[reply]
It could cause width issues on more than just small browser windows when you consider that Wikipedia alone has about 264 language versions! Of course, what would you even use for the icons, considering the language versions? I'd say a drop-down that lets you select project (Wikipedia, Wiktionary, Wikiversity, etc) first, and then a sublist to let you select the language variant for that project. (In simple skins I guess this would just turn into a nested set of unordered-lists at the bottom of the page.) Maybe I should take this as a cue to try creating my first gadget... --tiny plastic Grey Knight 16:55, 30 June 2008 (UTC)[reply]

"Dust Box" Policy Proposal

For known edit warriors, such as myself, has anyone ever considered banishing us to a Dust Box where we might fairly debate? This would save a lot of Admin time, and some of us might trade our freedom to openly edit on articles for a link to "Debate of the Day" on the Main Page. I'll open with an example that would become a hopeless edit war:

Hopeless edit-war bait
The following discussion has been closed. Please do not modify it.

Now that we have established that the genetic code is designed and there are no technologies based on Darwin, I further state:

All new cosmology since the finding that the Balmer red-shift is inversely proportional to square-of-distance in presumed recessional velocities of stars has been used to patch up this very finding, and that includes quasars and black holes, neither of which are directly observable by anything but variations in predicted red-shifts. The Big Bang tautology also includes the creation of the Second Law of thermodynamics with the Bang, with no mechanistic explanation other than faith in Hawking, and no reading of his work by the vast majority of his faithful at any level of intelligence beyond para-quoted hearsay for the less-intelligent-than-him; that is to say, with no reading of his math and physics.

Hawking is quoted as saying in an MIT seminar that there might be a supreme intelligence within Black Holes. His followers now claim this is the source of predicted Hawking Particles.

Hence, faith in NO GOD is still faith. The apostles of NO GOD are Hawking and Darwin.

Please vote on discuss this proposed policy. Doug youvan (talk) 05:07, 30 June 2008 (UTC)[reply]

Disagree: various parts of WP:NOT would appear to apply here, especially WP:NOTSOAPBOX. If people want to have debate, there are various fora (especially bulletin-boards) for this. I don't see it as being productive for wikipedia to create such a forum (and thereby potentially attract more contentious attention, with the very real possibility of it spilling over into article-talk/mainspace). HrafnTalkStalk 06:01, 30 June 2008 (UTC)[reply]
Oh, and WP:NOT#FORUM.--Izno (talk) 06:39, 30 June 2008 (UTC)[reply]
Why such eagerness for a poll? Such matters should be discussed, not voted upon. Waltham, The Duke of 06:04, 30 June 2008 (UTC)[reply]
Hrafn - I was thinking of you as the other half of the debate, with both of us taken off the table as article editors. Waltham - Sorry, I do not know the procedure here; let's make it a discussion. Doug youvan (talk) 06:17, 30 June 2008 (UTC)[reply]
Doug: I am not on wikipedia to debate you on a "made-up term", but to edit the encyclopaedia to ensure that information is verifiable (as well as adding new verifiable content, etc). HrafnTalkStalk 06:48, 30 June 2008 (UTC)[reply]
Hrafn: Your contribution is noted: http://www.wikipediaversusthegodofabraham.org , thus we are already far into debate which has no place here because our work involves strawdogs, polemic questions, and other debate tactics. Doug youvan (talk) 07:02, 30 June 2008 (UTC)[reply]
Doug: this website which you created would be considered WP:HARASSment if it were not so absurd. Not only does it contain numerous non-sequitors (unrelated to purported opposition to 'the God of Abraham'), but difs such as this one give the appearance that I was the author of large changes when in fact I only made a 'minor edit' at the end. There is no "debate" here, other than in your own mind. HrafnTalkStalk 07:31, 30 June 2008 (UTC)[reply]
See bullet 4 concerning identity: http://meta.wikimedia.org/wiki/Talk:Board_elections/2008/Archive2#Questions_before_candidacy.3F. That is for a Board Member; we are just editors. In my experience, I know of no method other than a court to determine ID, and only in cases where opposing counsel vigourously attacks one's identity for purposes of impeachment as a witness. The meta.wikimedia.org procedure is inadequate, unless http://meta.wikimedia.org/wiki/User:Cary_Bass is Homeland Defense and they are really on their toes. Hence, you are arguing the case for taking this into debate: It hardly matters in debate who we are. Any of us could be a consortium of people sharing a username and password who represents a special interest group that has no interest in the quality of an encyclopedia, but a lot of interest in a political campaign, market position, highly sophisticated vandalism, etc. Doug youvan (talk) 08:00, 30 June 2008 (UTC)[reply]

If you want a truly uninterrupted, no gloves on, full out debate, maybe something should be set up off-site and linked to? -- Ned Scott 06:40, 30 June 2008 (UTC)[reply]

I have no interest in debating a sockpuppeting editor who has previously been indefinitely blocked for making legal threats against me (I apologise for not clicking that Doug youvan=Nukeh earlier). HrafnTalkStalk 08:28, 30 June 2008 (UTC)[reply]
Maybe you guys should look into dispute resolution if the disagreement on that page is spilling over onto here. --tiny plastic Grey Knight 10:20, 30 June 2008 (UTC)[reply]
So, generalizing from this particular problem which is far more than a simple editorial dispute, I believe it is still in the best interests of WP to open a debate forum as an alternative to a hopeless edit war follow by a dispute resolution process involving highly polarized issues. There is some information in debates, but it is usually not of encyclopedia quality. This also addresses another problem, our authority. Perhaps some of you have heard from students that their teachers and professors are instructing them not to use Wikipedia as a source. I think that is bad advice on articles such as John Calvin and the Bohr Atom. Those articles are well done and should be seen as authoritative. However, on a subject such as Intelligent Design, which might be perceived by some to mix religion and science, a structured debate is a better forum. If we identify the participants by real names, and those names are prominent, we will place some of mankind's current thinking into the historic record by a more efficient means. For the Intelligent Design Debate, I propose we invite Richard Dawkin. Doug youvan (talk) 13:49, 30 June 2008 (UTC)[reply]
Real names and "authenticated experts" have been proposed lots of times under different contexts, but have never caught on in a formal sense. I agree with User:Ned Scott's point about taking it off-site if you want a debate under less restrictive conditions. --tiny plastic Grey Knight 14:55, 30 June 2008 (UTC)[reply]
Ned and Grey: So many things would have to be taken off-site. For example, how could someone with journalistic information from American Family Radio (AFR) edit in Planned Parenthood without a war? What about someone from JDL editing on Godwin's Law? We could make a list of almost impossible edits here, but that list is probably the same list that is well known to WP as the most time consuming topics that enter dispute resolution. I also believe that a large number of editors just give up. They operate in good faith, hit a consortium of well wired editors, and withdraw. Just watch: I withdraw from this discussion as of now, because it is time consuming. You guys work it out. Doug youvan (talk) 16:48, 30 June 2008 (UTC)[reply]
Since this discussion abutted mine and has been nagging at me I thought I'd comment. Each response you give Doug seems to indicate there is a lot more going on than just the need to vent in a Dust box. I feel and to no disrespect, that you are saying "we" and "our" problems of Wikipedia when I really think you are addressing your own problems -- specifically those that deal with editing of religious or ideological articles. It is no surprise many archived debates in conflict resolution, arbitration, wikiquette, etc are related to ideology (and speaking of anything related to the Muslim world--uff da!). Please consider lots of topics have seemingly deadlock debates -- politics, culture, wars, lutefisk, etc. I feel you, but do not be too apt to say the World of Wikipedia is working against you, and neither should your conflict with another user become the pinnacle on which to preach. NOTFORUM NOTSOAPBOX .:DavuMaya:. 19:34, 30 June 2008 (UTC)[reply]
it's got nothing to do with our core business and would go against WP:NOT. On that basis, I'd say this is a terrible idea. --Allemandtando (talk) 23:12, 30 June 2008 (UTC)[reply]
Well, the proposer already withdrew, so I guess we can just archive the discussion unless somebody else wants to take up the cause? (Any volunteers?) --tiny plastic Grey Knight 15:16, 1 July 2008 (UTC)[reply]
I can no longer withdraw because of this recent event: http://en.wikipedia.org/wiki/Wikipedia:Suspected_sock_puppets/Nukeh#User:Nukeh. Such vigorous editing against a simple policy change proposal indicates more of the same here. Note that nothing hereinabove mentioned anything about the initial statement concerning Hawking and Darwin. What is actually at stake is a fair election of Kansas School Board members. Opening a debate threatens the position of www.kcfs.org in illegally influencing this election by inappropriate use of Kansas state funded salaried positions and facilities that are used 24 x 7 by this consortium of editors who should be spending their time teaching, as salaried, rather than attempting to rewrite history on WP. Doug youvan (talk) 07:17, 2 July 2008 (UTC)[reply]
Ummm, this is truly bizarre -- I posted notice of this sockpuppet report both here and on this user's talkpage, before this user withdrew. I would recommend following Grey Knight's advice and archiving (per WP:NOT & per lack of anybody actually interested in debating Youvan). HrafnTalkStalk 08:03, 2 July 2008 (UTC)[reply]
I think it would be better to propose this at a time when you don't have something "at stake", otherwise you're going to have interests conflicting. What is the below block of (what looks like) quotations for? I don't understand their relevance to the proposal. --tiny plastic Grey Knight 10:45, 2 July 2008 (UTC)[reply]
Okay Grey Knight -- I'll butt out, and leave you to work out how best to deal with Doug, and his scintillating prose (below). :D HrafnTalkStalk 14:18, 2 July 2008 (UTC)[reply]
Grey - I don't understand what is "at stake" other than these italics writings stumulating a debate on Intelligent Design, possibly in reference to John 14:13-14. Maybe it is time for a vote so we can count the number of secular fascists on WP. Doug youvan (talk) 17:29, 2 July 2008 (UTC)[reply]
More flame-bait
The following discussion has been closed. Please do not modify it.

I see no reason to counter GDI or ID. ID also includes panspermia, a theory attributable to Arhhenius, the same man that described chemical rates and activation energies.

My thoughts are along the lines of this being an P universe, the daughter of a NP universe, wherein it is likely P!=NP. It appears that a progenitor biological event occurred in the NP universe.

I believe that all science that is not connected to mathematics is inferior to science that is connected to mathematics.

If one asks where is the math behind Darwin, we have the metaphor of the mathematical genetic algorithm (GA). An experimental reduction to practice of GA directed evolution is cited as my own work, yet I see no connection to anything as complicated as Darwinian theory.

Mathematicians are pleased to either prove a theorem, or prove a theorem can’t be proved. If P!=NP, and the underlying math for certain biophysical phenomena is describable as NP, then there is no scientific solution to be found. For those who want to explain everything with science, P!=NP will be more limiting than even the Uncertainty Principle.

It is ironic to see Pascal as both the father of combinatorics, and his own wager (Pascal’s Wager).

It is also astounding to see the truthfulness of Einstein when he ran into the Uncertainty Principle. His work is all backed by mathematics and proved by experiment. Darwin and Hawking are at the other end of the spectrum: no mathematical proofs, no predictions, no confirming experiments, and no technology. Einstein’s technologies range from clock corrections on GPS satellites to nuclear reactors and H bombs. With Darwin and Hawking proved false by insoluble underlying NP math, no technology whatsoever is affected.

Once confronted with NP phenomena, I personally find the book of Genesis to provide mathematical beauty via simplicity. Mathematical beauty is used by physicists to pick one theory over another on the basis of the winning theory having fewer variables. Genesis presents one variable, i.e., God. Pascal’s Wager takes this a bit further as to the logic of how one might want to bet. John Calvin’s work makes it somewhat more understandable. Doug youvan (talk) 10:31, 2 July 2008 (UTC)[reply]

Wikipedia is not a place for debating topics, it is a place for editing. If you cannot edit without deliberately causing conflict, you should not be here. Can we please put an end to this garbage? JohnnyMrNinja 18:02, 2 July 2008 (UTC)[reply]

May I respectfully suggest Fark.com as a suitable place for this crankcruft? – ukexpat (talk) 19:01, 2 July 2008 (UTC)[reply]
The editor in question has been indefinitely blocked as a sock of a previously indef-blocked disruptive editor. HrafnTalkStalk 19:08, 2 July 2008 (UTC)[reply]

IE8 activities

I've just dowloaded Opera 9.50, and I noticed something it offers among new features: when on a web page, any web page, you can select some text, right-click and then open the wikipedia article about the text you have just selected (or serach the text through a search engine, or a couple other options). This gives me an idea.

It seems that all browsers are currently starting to implement such options accessed with a right click.

1) At first glance, FF3 only offers a google search.

2) Opera offers a few predefined functions, among which a wikipedia lookup for selected text. At first glance it looks like site owners can not add anything to the list of options that Opera proposes with a right-click on selected text.

3) Internet Explorer 8, still at the beta stage I think, also proposes a basic list of options (users can remove them or add some from a predefined list that comes along with the installation of IE8); but wikipedia is not among these options (MSN Encarta is the closest to an ecyclopedia among the things that they propose natively). In IE8, such options that you get through a right-click are called "activities." Still, there is something that can be done: it is possible to write some xml codes that would let people add such an "activity" on their IE8 browser, in addition to what IE8 natively propose. It's something that's pretty easy to do, and I know how to do it. Then, you have to leave a link or button with some javascript so that users can add the custom "activity" to their list of supported IE8 activities. From the user's POV it is a process similar to adding a favorite (usr clicks on link, dialog box appears, "do you want to add this activity?", user clicks OK, then he can access the relevant parts of WP from any page on the web).

So, my questions: Is there already a project of creating a wikipedia activity for IE8 users? Would wikipedia be insterested in providing a link to its users, so that they can add the WP activity to their active IE8 activities? Basically, the benefit for the web user is that he can then very easily and directly go into wikipedia to read about some intriguing concept that he's just discovered on some web page.


Here's what the xml xode for a WP activity could look like (no debugging whatsoever done yet; probably does not work as such):

<?xml version="1.0" encoding="UTF-8"?>
<os:openServiceDescription
    xmlns:os="http://www.microsoft.com/schemas/openservicedescription/1.0">
    <os:homepageUrl>http://en.wikipedia.org/wiki/Main_Page</os:homepageUrl>
    <os:display>
        <os:name>Encyclopedic knowledge with Wikipedia</os:name>
        <os:icon>http://en.wikipedia.org/w/favicon.ico</os:icon>
        <os:description>Encyclopedic knowledge with Wikipedia</os:description>
    </os:display>
    <os:activity category="encyclopedy">
        <os:activityAction context="document">
            <os:preview action="http://en.wikipedia.org/wiki/Main_Page" />
            <os:execute action="http://en.wikipedia.org/wiki/Main_Page">
            </os:execute>
        </os:activityAction>
        <os:activityAction context="selection">
            <os:preview action="http://en.wikipedia.org/w/{selection}" />
            <os:execute action="http://en.wikipedia.org/w/{selection}" method="get">
        </os:activityAction>
    </os:activity>
</os:openServiceDescription>

This has to be put into an xml file. Let's say the file is called WPact.xml, and it is put on some web site at the following address:

www.some-site.com/WPact.xml

Then, the last step is to add the following link to a webpage:

<a href="javascript:window.external.addService('http://www.some-site.com/WPact.xml');">link text</a>

Users who click on the link will be proposed to add the WP activity to their IE8 browser. Should they choose to do so, they would then be able to access WP from a right click anywhere on a web page, and to go directly to the WP article about the text they have selected.ThorinMuglindir (talk) 06:12, 1 July 2008 (UTC)[reply]

There is an add-on to do this for Firefox: [1] --tiny plastic Grey Knight 15:12, 1 July 2008 (UTC)[reply]
Anecdotically, you also have an add-on which is simply is the IE8 activities for FF. And, I wans't truly paying justice to FF3 in my first post. In fact when you change your favored search engine in FF3, it also changes the search engine that is available through a right-click accordingly. That means you can get the WP search with a right-click, natively in the basic FF3, although it would be at the expense of having google or your favorite web search engine. Probably, the add-on you link would let people have both at the same time.ThorinMuglindir (talk) 17:59, 5 July 2008 (UTC)[reply]
This is a good idea. Once IE8 Beta 2 comes out in August (which I am planning on installing), I would like to have this utility. I'm sure there are plenty of other people who would be interested in this too. -- Imperator3733 (talk) 18:49, 2 July 2008 (UTC)[reply]
Thanks for the encouragement. If others have a similar opinion, the question would be where and how to make this available to people, and how to inform users that there is someplace where they can download the IE8 WP activity. Obviously the best moment to make some noise about it would be after IE8 leaves the beta stage and Live Update has updated IE7 to the new version.ThorinMuglindir (talk) 17:59, 5 July 2008 (UTC)[reply]

Optional filter for tables

There are several long tables on Wikipedia. Take the List of unit testing frameworks for instance. Wouldn't it be nice to have a way to filter out only the results for operating system X, language Y, or licence Z. Maarten Tromp 14:30, 1 July 2008 (CEST)

I'm posting this here rather than to Bot Approvals since I think it requires more general discussion before formulating the proposal, being a social issue as much as a technical one.

I wrote and manage PseudoBot, which reverts the addition of redlinks/no-links/links-to-disambiguation-pages to the Births or Deaths sections of the date pages (e.g. 1986 or October 15) made by anonymous users or recently-registered users. This is in line with the date page policy.

I've now had a couple of people ask if I could do the same for list-sections of other articles, and given that I do a lot of recent-changes patrolling and anti-vandalism, I can certainly see the appeal - some sections seem to attract vanity and attack entries. Things that come to mind are the "Notable Alumni" sections of certain schools, "Famous Residents" of certain towns/villages, and "List of Famous Fooizens" where Foo is some country or other.

If done right, registering a section with the bot could be a less-intrusive version of semi-protection, prevent a lot of junk, and save a lot of wasted time. If done wrong, it could restrict genuine edits and bite newbies. In any case, I think it'd be best restricted to only reverting non-autoconfirmed users - that way if something is mis-reverted, any autoconfirmed editor can reinstate the text, and the bot shouldn't touch it again.

Building the bot would be technically easy; there are many ways in which sections could be registered with the bot, I've already thought of quite a lot of them, and (though it's not my place to tell people what to discuss) I think that deciding on such mechanisms are best left until the Bot Approvals stage, lest we argue about what colour to paint the bicycle sheds.

What I'd like opinions on:

  1. Is this just a terrible, terrible idea in all cases?
  2. If not, should it apply to any blanket sets of articles (such as "School stubs" or "Members of Category:Villages in Foo" or "Lists of people with no more than 5% of their entries currently as redlinks") - or should the bits of the community that are working on an article or wikiproject or antivandalism nominate individual articles as the need arises?
  3. Who should be able to register pages? Admins only, or any autoconfirmed user, or anyone?
  4. By what means should pages be unregistered?
  5. Are there any sets of pages which (like the date pages) already have a "no redlinks" policy?
  6. What notices should be put on the sections? The date pages have HTML-style comments including Do not add people without Wikipedia articles to this list.
  7. What notices should be issued to editors whose contributions have been reverted? I'd favour something fairly gentle and taking care not to imply vandalism.
  8. Anything else that people think is relevant.

Pseudomonas(talk) 13:17, 1 July 2008 (UTC)[reply]

In my view, what is needed is to establish policy for groups of pages, and then have the bot police that policy if need be. A good place to start might be "those bottom-level pageslists in Lists of people by occupation". The current style guideline (at Wikipedia:Lists (stand-alone lists)#Lists of people) says: "Selected lists of people should be selected for importance/notability in that category and should have Wikipedia articles (or the reasonable expectation of an article in the future)." If consensus can be reached to tighten that up to say "no red-links" and make it a policy (with date pages being a precedent) then policing that policy would be a good task for the bot. I don't see that as a big ask: all that the policy is saying is "create a stub first". I don't see that the BAG need be involved except at the highest level - to approve a bot to police certain kinds of pages (e.g. lists) for which there is an established no-redlinks policy. Having a separate mechanism for adding or removing pages is even worse - it just adds bureaucracy. If consensus on a no-redlinks policy is established, and the BAG have approved the bot, that should be enough. Philip Trueman (talk) 13:45, 1 July 2008 (UTC)[reply]
(e/c) I think this is an excellent idea. As far as which pages to have the bot patrol, I have no idea how you would be able to find them all. I would say, just add as many as you can find easily, and then let autoconfirmed users add more to the list if/when they find them. I think that the pages should be assumed to be permanently added to the list. If any of them became a problem, just let an autoconfirmed user remove the name. For the notice that the bot gives people it reverts, how about something like
Hi, your recent edit to Middleofnowhere High School has been reverted by an automated bot because it added a name with a red link to the "notable alumni" section. If you believe that this was an error, and the name should have been added, please leave a note on this page. Thanks, [ PseudoBot signature would go here ]
And then make the error page similar to User:ClueBot/FalsePositives. People who are autoconfirmed could review any requests that come up, and if the name is legit, they could add it to the article, and the bot wouldn't revert them. Considering how few people (relatively) leave messages on the ClueBot error page, I seriously doubt that a hypothetical error page for PseudoBot would be a major burden, and in any case, the amount of time wasted dealing with people reporting errors would be far outweighed by the amount of time the bot would save if it reverted all these other pages as well as the date pages. J.delanoygabsadds 13:56, 1 July 2008 (UTC)[reply]
I suggest starting out slowly - do this for specific sections of specific articles/lists by request only. After you have the bot doing this for a while (at least a couple of months), then I think you should come back to the community and ask if anyone objects to your expanding it as you see fit. As for who can make requests, I suggest that you be bold and let anyone do that, but that you also adopt the practice that if any experienced editor objects to deletions, you'll stop using the bot on that particular section. (Treat this as a content dispute, in which you're not going to take sides.) I think an invisible comment, similar to the one you mention, is good to add to sections. I suggest that you not notify errant editors - particularly if the comment is in place - because a lot of them are probably going to be IP editors, and that's fairly pointless (shared IP addresses, like schools, in particular). A good edit summary should suffice to let editors know why their addition was reverted. (If you find that you're answering a lot of questions about deletions, then, yes, consider posting a notice to user talk pages.)
And thanks for doing this! Bots like yours help make Wikipedia articles better. -- John Broughton (♫♫) 14:47, 1 July 2008 (UTC)[reply]
(ec)this sounds like it could work very well on the many "List of xyz Bands/Artists" articles we have here, some of them are a mass of dead links added by spa's to promote their non-notable bands, take this early version of List of Korean musicians, [2] for example--Jac16888 (talk) 14:50, 1 July 2008 (UTC)[reply]
Whilst I'm happy to be bold, I need Bot Approval Group permission to run any bot, and I need to detail the specifics of how the bot will behave before I start. PseudoBot has already been running for some months with what I consider to be a good track record, so I feel I'm at the stage of asking for expansion into perhaps more contentious areas. Interesting point you make about not notifying IPs - I wonder what the general view is about that? Pseudomonas(talk) 15:00, 1 July 2008 (UTC)[reply]

WHile I think this could be good and useful if done right, it may upset a lot of people. You'd have to be careful with it's coding and usage. RlevseTalk 20:22, 2 July 2008 (UTC)[reply]

Obviously accurate coding is important, yes. What features do you think would minimize the upset it might cause? Pseudomonas(talk) 21:15, 2 July 2008 (UTC)[reply]

WikiDataSource or WikiStatistics (Part 2)

I think users commenting misunderstood my prior post which can be seen here: [[3]] . It is my understanding that subscription websites compile data because it is hard to get, not because they pay for it. I do not suggest that people get a subscription and post the data on Wikipedia, but I do suggest that Wikipedia acts as a mechanism for people that compile data on their own to post the data. Thus, the service other webpages provided of searching for and compiling data would no longer be necessary. Academics could easily post data they have collected, provided they did not think they could make money off of it because perceived demand is low.

Many datasets would come up in Wikipedia when many researchers might not even know that data existed, and people could make use of already collected data when they do not have the resources to compile data on their own.

The idea is to create a new system, not to steal from the old. —Preceding unsigned comment added by 216.37.94.10 (talk) 20:07, 1 July 2008 (UTC)[reply]

Support: I think this is a rather good idea. There are tons of pages that use data such as List of countries by foreign exchange reserves or List of countries by GDP (nominal) that would be great to keep track of by year or even by month. --PatrickFlaherty (talk) 23:07, 1 July 2008 (UTC)[reply]

Proposal for someone to create a Wikipedic Tree of knowledge

To honor our intellectual predecessors, I propose that someone with greater technical knowledge than I create a page/portal with internal links that reproduces the Enlightened Tree of Knowledge, i.e. where all the items are internally linked to our articles on them. It would be a way of showing our connection with past encyclopedic efforts and be something of an homage to Diderot and D'Alembert by doing with internal links what their paper tree could not do. For more information on the topic, please see Robert Darnton, "Philosophers Trim the Tree of Knowledge: The Epistemological Strategy of the Encyclopedie," The Great Cat Massacre and Other Episodes in French Cultural History (New York: Basic Books, Inc., 1984), 191-213. As the previous source suggests, if we don't already, we can and should cover their Tree of Knowledge as a notable subject backed by reliable sources. Best, --Le Grand Roi des CitrouillesTally-ho! 00:42, 2 July 2008 (UTC)[reply]

As in Figurative system of human knowledge? --—— Gadget850 (Ed) talk - 19:40, 2 July 2008 (UTC)[reply]
Wow! Cool! Thanks! Best, --Le Grand Roi des CitrouillesTally-ho! 19:43, 2 July 2008 (UTC)[reply]
You are welcome. Search is a wonderful tool! --—— Gadget850 (Ed) talk - 19:56, 2 July 2008 (UTC)[reply]
Oddly enough, when I searched for The Tree of Knowledge, look at what comes up instead. Best, --Le Grand Roi des CitrouillesTally-ho! 19:59, 2 July 2008 (UTC)[reply]

The undo function generates a comment of the form "Undid revision <revision number> by <username> (talk)". While "<username>" and "talk" are live links, "<revision number>" is not. To the average user and even an experienced one, it is difficult to identify the revision being undone looking at the article's history.

Proposal: Link "<revision number>" in the comment to the diff page of the revision being undone - i.e., http://en.wikipedia.org/w/index.php?diff=prev&oldid=<revision number>.

Alternate solution: Include the date and time of the original edit in the comment text. For example, "Undid revision <revision number> by <username> (talk) from <hh:mm, d mmm yyyy>"

-- Tcncv (talk) 05:58, 2 July 2008 (UTC)[reply]

Problem: external links don't work in edit summaries. As there is no interwiki map to diffs or oldids (it's a perrenial proposal), it's impossible to create a live link in an edit summary to the diff page. Happymelon 11:41, 2 July 2008 (UTC)[reply]

Breaking up huge discussion pages (like WP:ANI)

I've devised a simple way to automatically divide up large discussion pages like WP:ANI by having a custom "new section" link start a new section in whichever subpage is the smallest. I tried to drum up interest at WT:AN#Solution to size and subpage issues where a couple people liked it but figured it would never be adopted. But WP:ANI is now at almost 500 KB(!) and barely loads in a few of my PCs so I'm bringing it up here. My original message:

Please check (and feel free to try out) the "Start new thread" link at User:Wknight94/ANI. This link is autogenerated to start a new section in the ANI page that is currently smallest. I've done five but this could be expanded to as many ANIs as needed. The idea is that if one of the ANIs becomes overpopulated by a particular thread, this autogenerated link will cause new threads to start elsewhere and thereby keep all of the ANIs around the same manageable size. It's your basic load balancer. No more subpages and no more oversized ANI. Thoughts? (Of course the templates employed could use some work but you get the idea!...)

Of course let me know if this is the wrong place to bring this up... —Wknight94 (talk) 18:25, 3 July 2008 (UTC)[reply]

Speedy warning

I recently got a message on my talk page from an admin saying that I placed a speedy tag too quickly after the page creation. That may have been true but as the page stood it was certainly eligable as not asserting notability. I could have tagged the page with the notability tag but in my opinion this doesn't really fit as it makes no reference to the fact that the page could be speedily deleted. Indeed it says 'ultimately deleted' which to me suggests it's not going to be deleted for quite some time not the matter of minutes / hours it may be deleted in if it does get speedied. If I was a new editor and had my page speedied after reading the notability tag I'd be surprised to say the least. By putting the speedy tag on the page it makes the editor aware that they need to assert notability but also alets admins to the page which means it may be gone before they get the chance. Is it worth creating a template along the lines of "this page appears eligable for speedy deletion and needs an assertion of notability if this is to be avoided" as an intermediate step. If one is not fortcoming in say an hour then the speedy tag could be added. This way the editor gets a chance to update the page if they can but the page can still be tagged by those who patrol new pages so making it less likely to be missed then if we just avoid putting the tag on for, say, the first hour. The only other speedy criteria I could see something similar applying to is the copyright tag. Sorry if this has been raised before. Dpmuk (talk) 21:38, 3 July 2008 (UTC)[reply]

I think Dpmuk's idea of a speedy-warning template is a good one. Maybe it could include a time that's set to one or two hours in the future, after which it may be deleted if not properly sourced?--SarekOfVulcan (talk) 21:53, 3 July 2008 (UTC)[reply]
I see no particular reason to add more steps and regulation to the process. While they do not need to be perfect or fully formed, articles should have sourcing and assertion upon creation. If an editor believes the article can meet the criteria, he is fully free to use {{hangon}}. seresin ( ¡? ) 21:58, 3 July 2008 (UTC)[reply]
Rather than adding yet another step to our processes, perhaps we could emphasize that editors recommending deletion for lack of notability should evaluate the possibility that a subject is in fact notable - ideally, by doing just a bit of research in cases where doubt exists, and that the more obscure the subject matter, the more an editor should lean in the direction of a "lacks notability" template rather than a speedy delete template. That way, we can be welcoming (to those who are adding articles that really are useful) while still quickly deleting cruft. -- John Broughton (♫♫) 22:06, 3 July 2008 (UTC)[reply]
Yes, they should have sourcing and assertion, but I'm sure when I was new I didn't get the edits all lined up and previewed before committing anything - lots of people will write a paragraph, save that, and so on - it's reasonable that they shouldn't be bitten too hard if there's every chance that they're about to get to the point in their next edit. Prompted, yes; slapped, no. It shouldn't be another step, just another variant template, in the same way that one can choose between any number of warning templates, using uw-vand in different situations from uw-test. I'd perhaps timestamp the notice, but wouldn't make an hour a hard limit; I'd leave it to admin discretion as at present. Pseudomonas(talk) 22:16, 3 July 2008 (UTC)[reply]

Proposal to rename the pages called List of basic x topics to Topic outline of x

This is a follow-on proposal. The initial proposal didn't get enough discussion (there were 3 support votes and a bunch of ideas floated), and it was suggested at WP:ANI that a new proposal be posted, and announced on more pages. (I'll be posting notices over the next day or two).

This proposal is to rename the set of List of basic x topics pages to Topic outline of x.

Previous discussions are located here and here.

Why change the names? "List of basic x topics" is awkward, because "list" is ambiguous, because Wikipedia has more than one list format, and the title doesn't give any indication of what kind of list the reader will be looking at. Wikipedia has alphabetical lists, unsorted lists, and "structured lists" (lists arranged by subtopic, as these are). "Topic outline" describes the format of these pages much better, and is therefore a more accurate title. "Topic outline of x" is also more concise, having 4 words instead of the current 5.

This set of pages was designed as a whole to be an outline of human knowledge. It also doubles as a table of contents system for Wikipedia. Each page presents essential topics on its subject, and each of the pages shares a standard format. The set can be found at Lists of basic topics, with many more under development at Wikipedia:WikiProject Lists of basic topics, including one for every country of the World (over 200!).

The initial proposal was to rename the pages to Outline of x, but this is ambiguous because there are two types of outlines: sentence outlines and topic outlines. This set contains the latter variety. Another ambiguity of "outline" pertains to countries. For some, "Outline of Italy" conjured the image of an old high-heeled boot.

Some people thought "topical outline" was good, but others pointed out that "topical" is ambiguous and its primary meaning pertains to "current topics", and we didn't think of "topic outline" in the initial proposal discussion.

Someone suggested that the pages be renamed to "List of x topics", but that is another set of pages entirely (See Lists of topics). Those are intended to have a comprehensive scope (like the scope of an index), with each page to include all of the topics on a given subject. Currently that set has no format standards, and the quality of that set is pretty low in comparison to this one. And many of the subjects already have a "List of x topics", making it difficult or impossible to move these pages to that set. The set of pages we are concerned with here are limited in scope to a subject's essential topics. "Topic outline" captures this context very well. Merging them into the other set of topics lists would in effect disband this set and reject its purpose, and disperse these pages amongst a bunch of lists that are in much rougher shape. That is not the intention of this proposal.

Thank you for your time. I look forward to your comments, suggestions, opinions, and ideas. The Transhumanist    06:18, 4 July 2008 (UTC)[reply]

  • That is true, they are lists. But if you look at each page, you'll see that there are multiple lists on each (each page is really a list of lists). That is because these are outlines, a particular kind of list. More accurate titles are useful, and the new titles would better convey the purpose of these pages. Together they are an outline of human knowledge. Not just a hodgepodge of lists thrown together into a bunch. The Transhumanist    20:31, 4 July 2008 (UTC)[reply]
  • Yep they are lists, but "Topic outline of x" doesnt convey what the message is where as List of primary xx topics" . Example "Topic outline of Plants" is what one would expect from the article Plant where as a "list of primary Plant topics" is clear. The issues are in the choice of words to me basic, outline are both ambiguous terms as is the lack of identification as to how the information is presented. Gnangarra 02:56, 5 July 2008 (UTC)[reply]
  • 'Prefer Outline of topics in X as per Jheald.
  • Oppose direct migration. But we need both - "basic topics" for fundamental things, and "topic list" to provide an indication of the full range of things covered by a subject-title, with being a full list of all articles cobered by the title. Melcombe (talk) 12:36, 4 July 2008 (UTC)[reply]
  • "Topic outline" is ugly, even barbaric, as Jheald noted, and as such is not a reasonable name. The current name is equally infelicitous. "Topical outline" would be better, although I favour Jheald and Melcombe's alternatives over "Topic[al] outline" and Gnangarra's proposal. Angus McLellan (Talk) 13:48, 4 July 2008 (UTC)[reply]
  • All I can say is that my parser does not like "Topic outline". I have no problem with a rename, only some other form of words with the same sense sense would suit me better. I expect a noun to be preceded by an adjective, not another noun. Adjectiving nouns weirds them even more that verbing does. Angus McLellan (Talk) 22:30, 4 July 2008 (UTC)[reply]
  • Prefer Outline of major X topics, to make clear to both readers and editors that the outline is not, and is not intended to ever be, comprehensive. Otherwise there will be a constant addition of minor topics to the outline by well-meaning editors who don't realize the purpose of the outline. Sure, you can have a statement at the beginning, but if one word can make an important improvement in how well the title describes the page, I say go with it. ike9898 (talk) 14:39, 4 July 2008 (UTC)[reply]
  • Let's try "major" on for size: major earthquake, major industry, major development, major religion, major decision, major volcano, major technology, major river, major opera, major Big Science, major sports, major baseball, major construction, major game, major art, major Asia Major, major Asia Minor, major career, major literature, major crafts, major scholarship, major exercise, major relationship, major politics, and major finance. What would Outline of major film topics be about? Major films, like Star Wars? The Transhumanist    22:08, 4 July 2008 (UTC)[reply]
  • Big no-no. You stated that "the word 'list' is ambiguous", I believe that "topic" is even more ambiguous because it doesn't tell you what kind of contents it will contain. I also dislike the fact that you're spamming virtually every single WikiProject's talk page to the point that it starts to look like cavassing. Surely you could have posted it on Community portal, attracting more input and spent less time from using AWB? OhanaUnitedTalk page 16:01, 4 July 2008 (UTC)[reply]
  • How in the world is contacting WikiProjects a bad thing? Many people don't hang out on the community portal (I for example) and would've missed the opportunity to have a say in things. The people who hang out on Wikiprojects are generally those who manage such outlines/lists, to not contact them when decisions such as these are made would be a disservice to Wikipedia. Headbomb {ταλκWP Physics: PotW} 16:20, 4 July 2008 (UTC)[reply]
  • The last time around, I got bitched out at ANI for not contacting the relevant WikiProjects. So you are damned if you do, and damned if you don't. You just can't please all of the people all of the time. In the previous name change of all 400+ of these pages, the editors on a single page complained. That is, of all of the 400+ pages that were renamed, only one generated complaints. That's not bad in my opinion, but it's the entire reason this proposal had to be started over again. It's why we're here right now! The Transhumanist    19:09, 4 July 2008 (UTC)[reply]
  • Oppose - For consistency, they should be called lists, as they are lists. Also, what's the benefit to this? Are readers being confused by the current names? Will it somehow make the lists better? Until I can see a tangible benefit, I can't support this. Mr.Z-man 17:05, 4 July 2008 (UTC)[reply]
  • The benefit would be to make their purpose clearer. This set of pages is a major component of Wikipedia's table of contents system, or more accurately, its site map system. At the same time, they are an effort to map out the structure of human knowledge itself. "List" just doesn't convey these connotations. The Transhumanist    20:11, 4 July 2008 (UTC)[reply]
  • I think you are too narrow in your view of what constitutes a list. Even if organized in an outline form, these are still just lists of topics. A structured hierarchy of topics is still just a list, albeit a structured list. ···日本穣? · Talk to Nihonjoe 20:25, 4 July 2008 (UTC)[reply]
  • We both agree. They aren't mere lists, but a specific kind of list. Outlines are lists, and these lists are outlines. So why not make the title more accurate by calling them that? If you are talking about a small domesticated mammal with pointy ears and tail, it isn't particularly helpful to keep referring to it as just a mammal. "Your mammal is cute" makes it seem like you don't even know what kind of mammal it is. Would you hand a person an outline of a book and say "here's a list of basic topics that the book covers?" The current titles of these pages are just awkward, and they don't seem to fit common usage. The Transhumanist    20:37, 4 July 2008 (UTC)[reply]
  • Support Jheald's alternative: Outline of topics in X.
  • I would also suggest renaming most of the pages in Category:Topical indexes to "Index of topics in X". These renames would help clarify the structure and intent of these 2 groups of article-types, and help differentiate them from the usual list-style articles. -- Quiddity (talk) 18:51, 4 July 2008 (UTC)[reply]
    • Good point. Then Wikipedia would have indexes and outlines. Nice combination. But that will require another proposal, and having that discussion here would just confuse this discussion like it did during the previous proposal to rename this page set. The Transhumanist    18:56, 4 July 2008 (UTC)[reply]
  • Oppose - for the obvious reason that these articles are not "topic outlines". They are lists, and calling them anything else is only going to cause more confusion. Gatoclass (talk) 03:52, 5 July 2008 (UTC)[reply]
  • Support - An outline is a special kind of list. I'd also support projectifying (where a project on the subject exists). Most projects already have a simple topic outline, which could then link to one of these as a project subpage. --Latebird (talk) 17:36, 5 July 2008 (UTC)[reply]

Proposal to keep the lists of basic topics together. Someone has renamed one of them so it no longer matches the set!

The maintainers of the List of basic opera topics have renamed that list to List of opera topics. That page has the same scope and the same standard format as the rest of the basic topic lists. And the set of pages called Lists of topics that it has been moved into are comprehensive in scope. The page is clearly a member of the wrong set of pages now.

I propose that the Lists of basic topics be kept together, and that they retain the standard names of the set they belong to. If they are to be renamed, they should be renamed together as a set, as in the proposal in the previous section above.

If the pages can be renamed by local consensus individually on each one's talk page, then the discussion in the previous section above won't make much difference, as any of the pages could be renamed by anybody at anytime on a whim. Every time a page is moved out of the set, it creates a hole in the set's coverage, or at least has the potential to create confusion over what the purpose and scope of the renamed page is.

List of opera topics should be renamed back to List of basic opera topics, since that matches the naming convention currently in use for the set it was designed to be a part of. And if the discussion in the previous section above determines a new name for the set, it should apply to its opera component as well. The Transhumanist    19:22, 4 July 2008 (UTC)[reply]

Proposal for changes to Wikipedia's Content Disclaimer

1st revision

I am moving a copy of my proposal to the Village pump. Per RockMFR's recommendation at Wikipedia talk:Content disclaimer#NPOV Issues I concede that the Village Pump is a better location to discuss changes to Wikipedia:Content Disclaimer. The reason for this proposal is that the Content disclaimer has some sentences which could be shortened and clarified per Wikipedia's guidelines for NPOV. Please consider the following for implementation.

  • Please change In any case, Wikipedia is a work in progress, and many articles contain errors, bias, duplication, or simply need tender loving care. to
    • Wikipedia is a work in progress which may contains bias, duplication and errors.
  • Please change We encourage readers to help us fix these problems. to
    • Readers are encouraged to collaboratively work at fixing any of these problems.
  • Please change The great majority of articles are written primarily or solely by individuals who are not subject matter experts, and may lack academic or professional credentials in the area. to
    • Generally, material is written by individuals with unverified academic, subject matter expertize and/or professional credentials. Readers are advised to read Wikipedia's General Disclaimer
  • Please change Wikipedia contains obscure information that would not be covered in a conventional encyclopedia. to
    • Wikipedia may contain information not covered in conventional encyclopedias.
  • Please change Wikipedia's coverage of subjects is patchy, based on the whims of its volunteer contributors (in particular, subjects of interest to young technical people are likely, but not certain, to receive heavier coverage than other subjects). to
    • The coverage of some obscure subjects may sometimes becomes an interest to the technically inclined volunteer contributors at Wikipedia.

I don't see the purpose of the second change, it seems contradictory to WP:BOLD, you don't need to collaborate to fix an error. The third change also seems unnecessary, it seems to imply that most users claim some sort of expertise but we have no method of verification. The current wording is more accurate as it suggests most of Wikipedia is written by random people with no special expertise, or claim of expertise, whatsoever. Considering all the disclaimers are prominently linked on top of the content disclaimer page, an extra sentence to link to the General Disclaimer (which is also where the "Disclaimers" link on the bottom of every page leads to, so odds are people got to the content disclaimer through the general one) is unnecessary. The fourth change seems odd as well - "may contain" - you mean there's a chance that we don't? And the last change seems incorrect (and confusing) as well. The current sentence is quite clear, coverage of some subjects may be patchy because of the interests of most of our contributors, the suggested replacement makes no mention of patchy coverage but changes the meaning to say that we may have extra good coverage of "obscure" technical subjects. Mr.Z-man 19:56, 4 July 2008 (UTC)[reply]

  • Oppose The lines in red sound like they are written by humans. Protonk (talk) 15:30, 5 July 2008 (UTC)[reply]
    • side note: Hello Protonk. The objective of this proposal is to diminish redundant words and phrasing and to make our disclaimer as concise as possible. Perhaps if you read on my 2nd proposal, addressed to Mr.Z-man, you will better understand why I think this should be done. --CyclePat (talk) 16:43, 5 July 2008 (UTC)[reply]

2nd Proposal

Hello MR.Z-man, thank you for you feedback. I agree with some of your comments and have made necessary changes within a 2nd proposal + some critical comments. Again, thank you for your positive feedback. Here are the my recommended changes with some explanations :

  • 2. The problem with this sentence is "we" are using the subjective personal pronoun "We". I think this should be avoided. Also by adding the word collaboratively there is a type of reference to the guideline Wikipedia:Etiquette and Wikipedia's official policy Wikipedia:consensus. I believe if most users respected these guidelines and rules "we" could avoid many unfortunate blocks. Yes, WP:Bold is important element of Wikipedia, however, the objective of bold appears to be a type of guideline to encourage "constructive" or "collaborative" editing. Take for example where it is stated "Be bold and drop your opinion there.", "...but be careful" or "the safest course is to find consensus before making changes, but there are situations when bold edits can safely be made to contentious articles. Always use your very best editorial judgment in these cases and be sure to read the talk page." The Bold guideline even links to WP:CON policy which leads me to believe that it is inspired by this rule. (After all, we are currently using the WP:Etiquette guideline so we can edit the Wikipedia:Content Disclaimer protected page. Side note: perhaps we could discuss implementing further details regarding "protected page" disclaimers. Despite my attempt to rebut your comment, I still see and understand what you mean but here is my second proposal:
  • Please change We encourage readers to help us fix these problems. to
The majority of edits to articles aren't made with any sort of consultation whatsoever. If you see an error in an article, just fix it, that's why Wikipedia works, we don't require people to tell other people about errors or learn how to discuss things to fix a mistake, we tell people to just do it. Mr.Z-man 17:05, 5 July 2008 (UTC)[reply]
  • 3. Wikipedia doesn't really have a proper way of verifying who is really editing. All we really know is that someone using an alias, who purports to be MR. X (Hey! is Mr. X a cousin of yours b.t.w? just kidding). We have had at least one RfC that showed how a users has lied about his credentials, and this user at the time I believe was even working for Wikimedia (See Wikipedia:Requests for comment/Essjay for further details). Even if Wikipedia managed to install a state of the art login system there will always be liars, defrauders, people that could send in fake diplomas and the possibility of someone else login under someone's "trusted account". So, in fact, you are correct regarding your inference that "most users claim some sort of expertise but we have no method of verification." I do however concede. The issue which struck me the most was that we currently say "The great majority of articles". Please consider my recommendation which removes the word "great" and changes the word "articles" for "content":
  • Please change The great majority of articles are written primarily or solely by individuals who are not subject matter experts, and may lack academic or professional credentials in the area. to
    • The majority of Wikipedia's content is written primarily or solely by individuals with unverified academic, subject matter expertize and/or professional credentials.
This doesn't really address my concerns at all. I don't believe that most users claim some sort of expertise. Most users are just random, average people, so the current wording is more correct. Mr.Z-man 17:05, 5 July 2008 (UTC)[reply]
  • 4. I see what you mean. I've made the change but I still want to avoid the word obscure which feels like a pejorative towards Wikipedia (even though it is directly refering to information). My personal preference, perhaps a type of POV, is to try and keep negative aspects in seperate sentences allowing the end user to come to the conclusion that perhaps the information on Wikipedia is obscure (perhaps it isn't). All that to say that this is a subjective qualifier which is better treated in item #5 (bellow).
  • Please change Wikipedia contains obscure information that would not be covered in a conventional encyclopedia. to
    • Wikipedia contains information not covered in conventional encyclopedias.
This is fine. Mr.Z-man 17:05, 5 July 2008 (UTC)[reply]
  • 5. The reason I avoid the word Wiktionary:Patchy is because it has two meaning. Also the meaning we are using is of Finnish background. I think this should be avoided. If necessary we should explore the words "wiktionary:inconsistent" or even "wiktionary:intermittent" which appear to have one clear definition. Furthermore, I question the necessity of actually stating this. Every and any work is never really complete and will have some inconsistencies, intermissions or patches! No matter the case we should not be using parenthesis to explain something. Anyways... Young is a subjective adjective which I think shouldn't be in our disclaimer. Here is my 2nd revision
  • Please change Wikipedia's coverage of subjects is patchy, based on the whims of its volunteer contributors (in particular, subjects of interest to young technical people are likely, but not certain, to receive heavier coverage than other subjects). to
    • The coverage on material may sometimes include obscure subjects based on the various interests of Wikipedia's volunteer contributors.

Please tell me what you think. Thank you. --CyclePat (talk) 16:43, 5 July 2008 (UTC)[reply]

This still changes the meaning of the sentence, at least how I'm reading them. I read the current sentence as mainly saying: Coverage of subjects may be unequal and we may not have good coverage of certain things, while the proposed wording just says that we cover obscure topics. Mr.Z-man 17:05, 5 July 2008 (UTC)[reply]

Top 10 Wikipedias

Hi all.

I would like to request your attention to a vote that will start this midnight, regarding a rearrangement of the top ten Wikipedias that are displayed on the main wikipedia portal (http://www.wikipedia.org).

This topic has been wandering around for a long time on Talk:www.wikipedia.org template, coming to surface in many occasions, especially on the times around the milestone of 100.000 articles of the Chinese and Russian Wikipedias.

After a tentative wrap-up of all the proposals made in that page throughout the months in Talk:www.wikipedia.org template#rethinking the top ten, a discussion was launched in Top Ten Wikipedias, to which all the major Wikipedias have been invited to in their village pump.

A lot of good opinions have been collected and discussed, and a vote proposal has been made and received some feedback. That proposal was now implemented on Metapub. Please head to the poll to vote. I hope to see you there! --Waldir talk 12:46, 5 July 2008 (UTC)[reply]