Wikipedia:Village pump (proposals)/Archive 33

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Main Page redesign survey

There is an ongoing proposal to redesign the Main Page. Some alternate designs have been created, but larger input is needed to make a page good for readers and editors. A survey has been created, and all users are encouraged to give thier input. Thanks, --NickPenguin_(contribs) 03:25, 12 August 2008 (UTC)

Delete protection

Maybe there should be a kind of protection called "Delete-protection". For example, someone tries to delete "George W. Bush" for VANDALISM, he deletes it, another admin restores all revisions. Maybe to prevent that, it would not be deleted. It will also be bundled with Move-protection. Only Bureaucrats could delete them, and even then only when consensus is reached. Narutolovehinata5 ^tccsdnew 11:45, 5 August 2008 (UTC)

We have this - it's called Requests for Adminship. We only grant the technical ability to delete pages to users we trust not to abuse it. Happy‑melon 11:53, 5 August 2008 (UTC)

No. What I meant is that sometimes, admins abuse their sysop status. MAybe if they are caught deleting something, maybe they could just be de-sysoped. Narutolovehinata5 ^tccsdnew 12:11, 5 August 2008 (UTC)

When admins abuse their sysop status, we deal with it on a case-by-case basis. That's far more efficient than going through 2.5 million articles and deciding which to protect against deletion. And yes, when an admin is "caught" deleting something that clearly should not be deleted (as happens very, very rarely - usually a password compromise on an inactive account) then yes, the admin is de-sysoped immediately. -- John Broughton (♫♫) 13:01, 5 August 2008 (UTC)

Admins are automatically prevented from deleting pages with 5000 edits. Gimmetrow 14:21, 12 August 2008 (UTC)

Watchlist/Log tags concerning recreated material

I think that it may help slightly if when browsing through logs(like recent changes) if that a page was deleted, and it is then created again, that instead of it being listed as Created, it should be listed as Recreated, and possibly specify under what previous policy it was deleted.— Dædαlus ^Contribs /_Improve 05:17, 11 August 2008 (UTC)

Yes Please! That would make new page patrol a lot easier. However, the programming might not allow this, so you might want to take it to Bugzilla. Paragon¹²³²¹ 05:24, 11 August 2008 (UTC)

Bugzilla? What is this?— Dædαlus ^Contribs /_Improve 06:48, 11 August 2008 (UTC)

https://bugzilla.wikimedia.org/ - Icewedge (talk) 06:59, 11 August 2008 (UTC)

Well, and therein arises another problem. I don't know what to search for, or what to do.— Dædαlus ^Contribs /_Improve 07:11, 11 August 2008 (UTC)

Well, I don't think we have enough consensus here to go and submit a feature request just yet but if that time comes follow the guide at Wikipedia:Bug reports and feature requests. - Icewedge (talk) 07:19, 11 August 2008 (UTC)

Unfortunately I'm still confused, wouldn't a bug be classified as an error in the software code that prohibits the functionality of the software in one way or another, minor or major?— Dædαlus ^Contribs /_Improve 07:24, 11 August 2008 (UTC)

That would make sense. I guess non-existence is a an error in the software code that prohibits the functionality of the software in one way or another, I dunno, but they do handle new feature requests there regardless. - Icewedge (talk) 07:40, 11 August 2008 (UTC)

Ahhh, I understand now. Also, seems my eyes missed an important bit of information, specifically, the enhancement type of bug. I understand now. Now all we need is consensus to do it, right?— Dædαlus ^Contribs /_Improve 08:34, 11 August 2008 (UTC)

Comment about 'bugs'–Bugzilla and other 'bug-tracking software' are often used both for true bugs and for feature requests, typically within the same project instance. I wouldn't say this is best practice by any means, but it is a common expediency. --User:Ceyockey (talk to me) 01:00, 12 August 2008 (UTC)

Support - this sounds like a sensible proposal that could be very useful to some. It Is Me Here (talk) 08:40, 11 August 2008 (UTC)

Support - but I note that there is absolutely no requirement to achieve consensus before filing a bug report. Developers may ask for such a showing before working on the bug, but often they see that the change is going to be non-controversial, or is clearly an improvement, and simply go ahead and implement it. (They can also implement it as an option for individual language Wikipedias to decide whether to turn on, or leave off.) So I suggest going ahead and filing at bugzilla. -- John Broughton (♫♫) 16:08, 11 August 2008 (UTC)

Support - benefit is obvious, I can see no downside on our end. ~ JohnnyMrNinja 18:31, 11 August 2008 (UTC)

Support with some caveats—this would be quite beneficial. However, one should not necessarily assume that an article that is created with the same title has been re-created. Consider Jamie Brooks; there have been three people attributed to this title: a porn actress, a footballer and a musician. Deletion of the musician and creation of the footballer would not constitute re-creation but rather title recycling, which happens not infrequently (once in the given case, and it could easily have been twice if the PROD had run to completion). The safer term to use might, in fact, be "Title reused". Another thing to consider is how many things are deleted with an associated policy tag. For instance, to the best of my knowledge, only WP:CSD has boilerplate for deletion descriptions that would be bot-readable; a prerequisite to application across the gamut of article deletion cases would be to standardize a full set of policy tags for all deletion types. I don't think that is a pre-requisite to establishing the functionality, but it would be for full utility across all deletion types. Regards, User:Ceyockey (talk to me) 00:56, 12 August 2008 (UTC)

Question Can I copy that into the feature request? Those are some well thought-out points.— Dædαlus ^Contribs /_Improve 06:06, 12 August 2008 (UTC)

You can copy anything you want; nobody owns their comments here. -- John Broughton (♫♫) 15:36, 12 August 2008 (UTC)

Linking to portals

Is it recommended for articles to link to the portals they fall under? I notice that some articles have little navigation boxes with icons, while most do not. Should linking to portals become the norm instead of the exception? I think portals should receive more attention. SharkD (talk) 09:41, 12 August 2008 (UTC)

I agree that portals should receive more attention, but don't think there should be links to them in any article that "belongs to the portal". Broad overview articles should always link to the relevant portal (Germany and History of Germany should link to Portal:Germany), but I don't think any specific biography should link to Portal:Biography. Kusma (talk) 11:14, 12 August 2008 (UTC)

My concern is that people won't visit these overview articles as frequently as more specific articles, and therefore may never learn of the portals' existence. IMHO, I don't think a link to a portal would be inappropriate in the example you cite. SharkD (talk) 16:31, 12 August 2008 (UTC)

New Usercheck template

Hello everyone. I was recently browsing Template:Usercheck/doc#Other user signatures, looking for an appropriate one to put on my user page for anyone who wants to quickly dissect my account, but then I noticed that no one template included every category. Thus, I have made {{Usercheck-full}}, in which I crudely welded together every appropriate Usercheck category I could find. I would appreciate any feedback on it, as well as any improvements to it, and once it has been cleaned up and approved, I suggest that it be added to Template:Usercheck/doc#Other user signatures.

Here, incidentally, is {{Usercheck-full}} applied to me (it will automatically update as the template itself is changed):

It Is Me Here (talk · message · contribs · global contribs · deleted contribs · page moves · user creation · block user · block log · count · total · logs · summary · email | lu · rfas · rfb · arb · rfc · lta · checkuser · spi · socks | rfar · rfc · rfcu · ssp | current rights · rights log (local) · rights log (global/meta) | rights · renames · blocks · protects · deletions · rollback · admin · logs | UHx · AfD · UtHx · UtE)

It Is Me Here (talk) 21:39, 7 August 2008 (UTC)

Wow! that is long! I can't imagine when or why or where it would be needed, but I also don't see how my lack of imagination should limit its inclusion in the usercheck documentation. − Twas Now ( talk • contribs • e-mail ) 21:43, 7 August 2008 (UTC)

Well, like I say, I'm intending to put it on my userpage so that I (and anyone else) can easily find out about any aspect of my account. Also, I thought that it was odd that none of the existing templates should include every category for users, so I made one. It Is Me Here (talk) 06:48, 8 August 2008 (UTC)

A few notes: it has 2 links to the same edit counter. The "total" link uses the old query.php, which is going to be removed very soon, it should use [1] instead. It has 2 "logs" links (both of which are probably unnecessary as it has links to every log individually). There's also redundant links for block log, listusers, RFA, RFB, RFAR, RFC, RFCU, SSP, and pagemoves. The "current rights" link is redundant to the other listusers link. The "Ut+" link is the same thing as the "message" link at the beginning. It also has an extra '•' between "block log" and "count" and an extra | at the end. Mr.Z-man 20:34, 9 August 2008 (UTC)

Thanks for the information. You have to bear in mind that I really have very little grasp on what all the code in the template does (I've not yet mastered the advanced WikiMarkup present in such templates) and it's all I can do to paste different bits onto the same page, delete bits and make all the bullet points look the same. Having said that, I have now carried out all the changes that you suggested which involved removing a superfluous criterion which linked to exactly the same page as another one. Thus, I have removed one block log link, one count link, one logs link, one lu link, the moves link and the Ut+ link. Furthermore, the apparently superfluous bullet point between the block log and count criteria was caused by yet another rfcu criterion which disappears when {{Usercheck-full}} is applied to me for some reason; I have now removed it as it does the same thing as another rfcu link, so that should also no longer be a problem. As for all the other things that need doing, I need some help.

• I can see that there are two criteria related to:
  • Requests for comment (rfc, rfc)
  • Requests for arbitration (arb, rfar)
  • Requests for checkuser (checkuser, rfcu)
  • Sockpuppets (socks, ssp)

However, the two groups of links work in different ways, with the same sort of link from each group actually leading to a different page (with me, at least, where the categories are empty [at time of writing]). Thus, I'm unsure which system would be the better one for this template, although the first one of the two in the template where nonexistent categories' links are grey seems the more convenient. Also, I'd like a greyed-out rfb link to link to Wikipedia:Requests for adminship#About RfB, rather than just linking to Wikipedia:Requests for adminship - is that possible? Again, I don't think I know the code well enough at present to edit the pages the rfb criterion links to without breaking it in some way. On the other hand, perhaps both groups of links should remain, in case some people prefer using one system and others prefer using another? I do want this template to include all conceivably useful user-related criteria, after all.

• I have not been able to find the superfluous RFA or RFB links - could you give the exact names of the criteria as they appear on the template, please?
• I cannot change the total link because I am unsure about how to change your URL which is specific to me to one which can be applied to anyone - I would be very grateful if someone else could do that for me (again, my knowledge of the code behind the {{Usercheck-full}} template is currently not adequate for me to make any serious changes to it).
• The apparently superfluous | sign at the end of the template is actually supposed to be an Online / Offline indicator which does appear on the Template:Usercheck-full page itself, but disappears for some reason when the template is applied to me. Again, if someone could edit that section of the template so that Online or Offline always appears after UtE, that would be very much appreciated.
• I have noticed that the UHx, UtHx and UtE links do not work - if someone could fix them, then that would be great.

It Is Me Here (talk) 14:13, 10 August 2008 (UTC)

hmmm... it's possible that you could make an expandable list (rather than just hitting the page with everything at once) - maybe each section having it's own little expando-bit. I'm not sure how that would look, though.  :-) --Ludwigs2 08:22, 13 August 2008 (UTC)

brainstorming an idea about blocking....

I'd like to suggest a new, compulsory, field that admin.s must fill in when issuing blocks - labeled something like 'Steps you must take which will result in the block being lifted' or somesuch. To my mind, this would smooth many a heated situation, aid communication in the admin community, and just generally be a very good thing. Thoughts, feedback, and particularly suggestions for how to best discuss this most welcome! cheers, Privatemusings (talk) 04:25, 12 August 2008 (UTC)

An interesting idea. Usually it is just "Stop doing whatever the block reason was" anyway, and some people, e.g. grawp, WoW, etc, won't be unblocked for any reason. Typically this would be handled on a per-user basis on their talk page, so a field in the block message is likely unnecessary. Prodego ^talk 05:08, 12 August 2008 (UTC)

sure, in some cases 'self evident' would be an acceptable summary.. in others though, being explicit to the offender can really help, and saying 'this is what you need to do' actually empowers the user to (alert! alert! - Dr. Phil moment coming up....) 'own' their choices, and the resolution of the problem. It also allows the broader community (and other admin.s) to clearly review the basis of the block. What would you think about an optional field? Privatemusings (talk) 05:55, 12 August 2008 (UTC)I think encouraging admin.s to think in this way has a myriad of other benefits too.. but let's take it slow :-)

How would such a field be useful in instances when no unblock was possible, say blocking the sock of a banned user or blocking a vandal bot like Grawp? MBisanz ^talk 08:55, 12 August 2008 (UTC)

Looking at the last couple hundred block log entries, the vast majority of blocks seem to be vandalism, spam, open proxies, and username blocks. This wouldn't be useful in most cases. To go even further on Prodego's reply, if they don't understand that their behavior is disruptive even after being blocked, where they need someone to guide them through being less disruptive, do we really want them? Mr.Z-man 15:41, 12 August 2008 (UTC)

In the vast majority of cases, such a field wouldn't make much sense. In the few (but important!) cases where it does, it's probably easier and more intuitive to explain this on the user's talk page -- I'd be fine with encouraging admins to do that, and potentially modifying existing block templates to that effect. – Luna Santin (talk) 22:34, 13 August 2008 (UTC)

Newcomers' move requests

Would it be possible to have a page for non-autoconfirmed users to request that autoconfirmed users perform uncontroversial page moves for them? For example:

Please move A to B -- 12.345.678.90(talk)

OK, done it --Example(talk)

Please move George Bush to "Stupidest president" --VandalRegisteredYesterday(talk)

Not done, vandalism --Example(talk)

Please comment.--Thanks, Ainlina(box)? 11:11, 12 August 2008 (UTC)

Perhaps instructions in that direction should be added to the "Uncontroversial proposals" section of Wikipedia:Requested moves. We should not split up move requests into more than one page, though. Kusma (talk) 11:16, 12 August 2008 (UTC)

What do new editors see when they try to do a move (or is the move tab totally invisible)? It would certainly be nice if they were given a link to the "Uncontroversial proposals" section of Wikipedia:Requested moves rather than simply getting a "no can do" message (implicitly or explicitly). -- John Broughton (♫♫) 15:44, 12 August 2008 (UTC)

The move tab is invisible to new users. If they somehow find their way to Special:MovePage/100 (or whatever) without it, they get a link to requested moves. Algebraist 16:09, 12 August 2008 (UTC)

Specifically, they see MediaWiki:Movenotallowed. Algebraist 16:15, 12 August 2008 (UTC)

We get these requests fairly often on the Help Desk, by both new users and by IPs. --—— Gadget850 (Ed) ^talk - 18:01, 12 August 2008 (UTC)

So perhaps it could help lighten the load for the Help Desk? I personally like the idea, and perhaps would be willing to help out with the moves -Sykko-(talk to me) 23:44, 12 August 2008 (UTC)

It's not much of a heavy load. There are maybe 2–4 requests per week. With the number of people watching the Help Desk, it's a non-issue. — Twas Now ( talk • contribs • e-mail ) 04:33, 13 August 2008 (UTC)

Yes- the Help Desk is already doing these types of moves pretty readily, once we figure out what the requester really wants. You could propose this on the HD talk page. --—— Gadget850 (Ed) ^talk - 15:28, 13 August 2008 (UTC)

"Disputed" by who on what

I see in many heavily edited articles the tag while the talk page is completely spammed by discussion, most of it being about POV. Where is a system to show who posted the tag for what discussion. The whole thing makes me think the whole discussion and generally communication between wikipedians system is completely bogus. Maybe a forum system should be devised leaving wiki codes and tags only for articles. --Apotetios (talk) 15:04, 13 August 2008 (UTC)

It would be helpful if you would provide a couple of examples. -- John Broughton (♫♫) 16:03, 13 August 2008 (UTC)

With such tags, typically the user who tags the article should explain why they've tagged it on the article's talk page -- thereby justifying the action and providing a paper trail in one fell swoop. If an article is spuriously tagged, the template can be removed. If it's difficult to tell who tagged what because many users are disputing the content, does it necessarily even matter which precise user did the tagging? – Luna Santin (talk) 22:32, 13 August 2008 (UTC)

I also don't think it matters precisely what user tagged the page, so long as a comment(s) is made on the talk page so that consensus to keep or remove the tag and the for whys of the tag are easy to see. Deamon138 (talk) 00:03, 14 August 2008 (UTC)

Add (watch) to Special:Contributions

Would anyone else besides myself find adding (watch) to Special:Contributions a desirable thing? I filed Bugzilla:15093, but I probably should have brought it here first to see if it's even something that other people want. I personally like to (selectively) watch pages I edit, or see what other people are up to (good or bad). The response on Bugzilla says that, among other things, it would clutter the UI, but i don't clutter is really an issue on that page. Thoughts? ~ JohnnyMrNinja 17:31, 11 August 2008 (UTC)

That sounds like a lot like wiki stalking to me. - Icewedge (talk) 17:34, 11 August 2008 (UTC)

Oh dear, it does doesn't it? Let me clarify, so people don't think I'm creepy. I have been moving a lot of images to the commons, and wanted to make sure I had them all watched so that I could fix any problems that MetsBot came up with. I don't want to watch every edit that I make, as I make many small edits I do not care to follow up on. I was simply trying to think of other uses, and I hope nobody thinks I am waiting in their bushes or something. ~ JohnnyMrNinja 18:05, 11 August 2008 (UTC)

Aren't ninjas well known for doing things like hiding in the bushes? :) In all seriousness - I can see some benefit to what you are suggesting, but I do have a feeling that the added ability to "snoop" on other users is likely to raise too many hackles to get support for this. Shereth 18:08, 11 August 2008 (UTC)

I imagine that there are many editors who do things in batches, like putting {{db}} tags on New Pages or articles in a certain category (something I also do a lot). If people were too worried about others watching their actions, then I don't think we'd have Special:Contributions in the first place. ~ JohnnyMrNinja 18:15, 11 August 2008 (UTC)

You could probably make a script to do that. Prodego ^talk 05:12, 12 August 2008 (UTC)

User:Tra#User watchlist. -- John Broughton (♫♫) 15:39, 12 August 2008 (UTC)

An interesting idea, but a whole variety similar links can be useful for any number of batch jobs, and it would be impractical to add all of them in all cases for all users; you may wish to install a script specifically for such a purpose, or consider something like popups which can allow for a great deal of versatility. – Luna Santin (talk) 22:36, 13 August 2008 (UTC)

• I'd love the ability to watchlist vandals contributions. There is a userscript that does this; I haven't tested it - but it seems like it would show you everyone's contributions of whose pages you had watched - which I don't want, I've got some talk pages I watch, but don't particular want to see all their contribs. Perhaps someone can re-juke that script a little bit. –xeno (talk) 00:57, 15 August 2008 (UTC)

Adding a lead section template to articles

I recently has a conversation with some wikipedians at the London wikimeet about how some of our articles are too difficult for many of our readers to understand. In particular we were worried about mathematics articles, but other subjects such as medicine were also mentioned. An experimental lead summary template was produced and trialled at Westminster School and Abelian Group.

The one at Abelian group has been taken down for now, whilst the discussion is continuing. I am a little concerned that the mathematicians are writing articles for themselves, and are so used to mathematical notation and jargon that they don't even see the problems with the article.

So I'm inviting comments from a wider audience. Please come to Talk:Abelian group if you wish to express an opinion on the merits of the idea or if you want to poo poo it as a load of old rubbish of one. Theresa Knott | The otter sank 07:07, 12 August 2008 (UTC)

I totally agree with you. You can add philosophy, linguistics and occasionally art (though that tends to be galleries/artists writing their own articles). I think there should be something along the lines of your lead trial, but not as a lead, just as a box somewhere in the article, which is "Layperson's guide" and which should aim at a certain target audience (The Sun?). However, this is only necessary for technical articles. Something like Westminster School shouldn't need it. I found the one on Abelian group[2] was not much better than the existing article. It still required a knowledge of specific terms, rather than using everyday language to communicate the basic principles of the subject. Ty 14:46, 13 August 2008 (UTC)

A related discussion is at Wikipedia:Village_pump_(miscellaneous)#English_wikipedia_use_far_too_difficult_language_on_many_articles.2C_this_should_STOP. Ty 07:53, 14 August 2008 (UTC)

(outdent) all I see at Westminster School is a pretty box. Surely the language would be the same with or without the box? Most subjects should be able to be written clearly and succinctly for laypeople to read I agree. It is tricky to address sweeping statements really. I am sure article writers would be happy to substitute plainer English terms if meaning can be kept. Cheers, Casliber (talk · contribs) 11:48, 14 August 2008 (UTC)

Dead space to right of TOC

Long articles have long TOCs, see e.g. Dinosaur, and this leaves a lot of dead space to the right of the TOC. I wouldn't like to float the TOC left of the main content since: long articles also usually have infoboxes, and the text would be sandwiched; I don't like float left in general, as it makes the text harder to read by varying the start positions of lines. My own preference would be to shorten the TOC, e.g.:

• multi-column, similar to {{reflist|2}}. The tricky part might be making sure it does not overlap the infobox if one is present.
• horizontal layout for lowest-level headings, wrapping to multiple lines if needed, e.g.

Level 1

   Level 1.1

      Level 1.1.1   Level 1.1.2   Level 1.1.3

      Level 1.1.4   Level 1.1.5   Level 1.1.6

I suggest a brainstorm. Any other ideas? -- Philcha (talk) 08:00, 12 August 2008 (UTC)

Maybe you will find what you need here. SharkD (talk) 08:17, 12 August 2008 (UTC)

In some cases you may also want to manually enter the TOC; see List of NHL statistical leaders by country for an example. — Twas Now ( talk • contribs • e-mail ) 13:08, 14 August 2008 (UTC)

Current date and time

I would like to propose that the current date and time be prominently displayed, maybe among the very top row of links (username, preferences, log out, etc.). At the very least I think it should be displayed when editing pages, when viewing watchlists and when viewing article histories. SharkD (talk) 08:17, 12 August 2008 (UTC)

Special:Preferences > Gadgets > User interface gadgets > A clock in the personal toolbar that shows the current time in UTC and also provides a link to purge the current page. --—— Gadget850 (Ed) ^talk - 18:10, 12 August 2008 (UTC)

Thanks a lot! That is very helpful. SharkD (talk) 22:20, 12 August 2008 (UTC)

Nice! Can I get it without seconds? --Apoc2400 (talk) 19:28, 14 August 2008 (UTC)

Proposal: Move main page to a different namespace

The discussion to rename the Main Page was archived, so I moved it to Village pump (proposals)/Persistent proposals to prevent archiving ~ JohnnyMrNinja 23:52, 14 August 2008 (UTC)

Proposal to renovate WP:TFA/R

It's been proposed that a new process be designed to replace the current one at WP:Today's featured article/Requests. Input from those who have ideas for how main page article requests should be filed is needed at WT:TFA/R. Thank you. —Scott5114↗ [EXACT CHANGE ONLY] 22:30, 11 August 2008 (UTC)

To think, all this time I thought WP:TFAR was "templates for arbitration" or somesuch. — CharlotteWebb 15:17, 15 August 2008 (UTC)

FORUM

Maybe Wikipedia should have a forum (can be off-topic, about Wikipedia, or just want to say hi). It will be useful for questions like "Why is Wikipe-tam more commonly used than Wikipede?" . It could also be on talk pages, however, as using thetalk page as a forum is prohibited, this could be a good idea. Narutolovehinata5 ^tccsdnew 13:59, 15 August 2008 (UTC)

See Wikipedia:IRC channels. Woody (talk) 14:30, 15 August 2008 (UTC)

We have the Wikipedia:Help desk for asking question about using Wikipedia, and the Wikipedia:Reference desk for questions on various topics. However, Wikipedia is not a social networking site (well, officially). Pretty much anything you find on Wikipedia should be of at least some benefit to the encyclopedia. — Twas Now ( talk • contribs • e-mail ) 14:31, 15 August 2008 (UTC)

Well I can't use IRC (it is only a free trial), plus It would be easier than IRC (not everyone has IRC) Narutolovehinata5 ^tccsdnew 03:14, 16 August 2008 (UTC)

You can always use IRC for free; IRC is a completely open standard, there's nothing to prevent you from programming your own client to the specifications, although you should really be able to find a no-cost client for whatever OS you're on. If you're on a Linux system, irrsi will be fine, or xchat or Pidgin if you prefer a graphical interface. In the windows world, you can also use Pidgin. Celarnor ^{Talk to me} 03:27, 16 August 2008 (UTC)

Adding the Article Creation Date

Not sure if this has been previously mentioned given that I am relatively new, but what about having the article creation date instead of just the last modification date. I am usually curious when articles have been first added, and am often scrolling through the history pages. Bjmartin (talk) 14:23, 15 August 2008 (UTC)

If you scroll the history to the first edit, that is the article creation date. — Twas Now ( talk • contribs • e-mail ) 14:27, 15 August 2008 (UTC)

I know, but rather than have to click twice, and scroll down in the history, it could simply appear on every page, no? Bjmartin (talk) 18:46, 15 August 2008 (UTC)

As I was creating a mockup for how this feature could look, I discovered that when on the History page, if you click the "Earliest" link, it will start at the last page of the history. The first edit to the page is the one at the bottom of that page. -- Imperator3733 (talk) 04:33, 16 August 2008 (UTC)

Improvement - Links or Bookmarks Page

I suggest an improvement or additional feature to Wikipedia.

When a user is logged in, he could bookmark a Wikipedia page that he frequently visits. The bookmark would be placed on a page similar to the 'watchlist', but he could organize them under different sections. I think this would be useful to many users and avoid users to search for a useful page that they visited in the past and often visit.

The list of Wikipedia links (bookmarks) could also be made public, if the user wants. This might be useful in many cases, example: a teacher that has useful links related to his class, etc.

Most browsers have a bookmark feature. Just use that. Paragon¹²³²¹ 16:42, 15 August 2008 (UTC)

It would be nice, but even if it's never implemented you can still sort of do it by creating a WP:SUBPAGE in your user space (User:Bewildebeast/Bookmarks or whatever). It can't be made private and you can't add bookmarks directly from article pages (may be possible with a WP:SCRIPT), but it's something. — Matt Eason ^{(Talk &#149; Contribs)} 17:52, 15 August 2008 (UTC)

Editorial Council

Please go read my proposal here about establishing an Editorial Council, which would in a nutshell act like an ArbCom for content disputes. Thank you! --Hemlock Martinis (talk) 02:07, 16 August 2008 (UTC)

Namespace for featured content pages

A short while ago, I moved four of the featured content pages (and their subpages and related talk pages) to the portal namespace. This brought them in line with the main featured content page (which was moved from the Wikipedia namespace in December) and two of the other featured content pages, but it quickly became evident that I was too bold in performing these moves without explicit discussion. So they've been reversed, and I now seek to initiate said discussion.
I regard it as self-evident that the current mishmash is illogical and confusing, and I'm fairly certain that we can agree that consistency would be preferable. I propose that the four featured content pages in the Wikipedia namespace (Wikipedia:Featured articles, Wikipedia:Featured pictures, Wikipedia:Featured lists and Wikipedia:Featured topics) be moved to the portal namespace, but moving the other three featured content pages (Portal:Featured content, Portal:Featured portals and Portal:Featured sounds) to the Wikipedia namespace would make more sense than the current setup. Opinions? —David Levy 22:09, 3 August 2008 (UTC)

I agree it is illogical too. Why do you favour it all being in the Portal namespace than the Wikipedia one? Deamon138 (talk) 22:16, 3 August 2008 (UTC)

I favor such a setup simply because the root pages are portals (reader-oriented gateways to encyclopedic content), not behind-the-scenes project pages intended for editors. —David Levy 22:25, 3 August 2008 (UTC)

The (aborted) move raises a number of questions. What about FAC and FAR archives? What about the actual pages, WP:FAC, WP:FAR, WP:FAS, WP:FFA, etc? What about pages like WP:GO? What about the many templates and instruction pages that go with these processes? What are the limits/boundaries to what all gets moved? How does that impact all the bots and scripts that keep everything going in the background (thinking of GimmeBot on {{articlehistory}} and Rick Block on pages like WP:WBFAN, as well as various Dr pda scripts)? And, in terms of something like WP:SIGNPOST, how is Wikipedia space defined anyway, relative to a Portal? Just moving WP:FA and its talk page raises a lot of questions. Conclusion: I suspect that moving those three portals back to Wikipedia namespace will leave far less ripples everywhere, but I'd want to hear from the guys behind the bots and scripts that keep everything rolling at minimum (Gimmetrow (talk · contribs), Rick Block (talk · contribs) and Dr pda (talk · contribs)). SandyGeorgia (Talk) 22:24, 3 August 2008 (UTC)

Are you proposing that only the showcases are moved into project space and the FLCs/FACs remain in Wikipedia space. That strikes me as inconsistent. I don't think FA/FL should be in the Portal namespace, though I understand the need for consistency. I personally don't have that much of a problem with FA/FL showcases being in the portal namespace, I just think it should have been discussed first, not least because of the technical issues with bots etc that keep these processes working. Woody (talk) 23:20, 3 August 2008 (UTC)

For those new to this topic, discussions on this have gone on at User_talk:Raul654#Wikipedia:Featured_articles_-.3E_Portal:Featured_articles and User_talk:David_Levy#WP:FA. (I haven't missed anywhere have I?). Deamon138 (talk) 23:23, 3 August 2008 (UTC)

There were a couple of other spots, but those are the only two I've seen with substantial discussion. --CBD 23:30, 3 August 2008 (UTC)

Others might not consider losing a bot writer and operator substantial, but it significantly impacts the work involved in the featured processes: User talk:SandyGeorgia#FAC paperwork. SandyGeorgia (Talk) 07:59, 5 August 2008 (UTC)

???. --CBD 14:50, 5 August 2008 (UTC)

Ok cool. People, feel free to add any of the others if you feel they warrant notification. Deamon138 (talk) 23:33, 3 August 2008 (UTC)

The locations of pages should be based on their roles in Wikipedia, not the convenience of bots or gnomes. Pages highlighting featured content serve as portals to the encyclopedia and, therefore, should be located on portal namespace. RichardF (talk) 23:30, 3 August 2008 (UTC)

I don't know you RichardF, but I hope you thought about the consequences of making that statement before you typed it. Real people operate those bots, and the featured processes are going to be a lot more work without their valued contributions. Thanks, SandyGeorgia (Talk) 01:14, 4 August 2008 (UTC)

I don't think that Richard intended to belittle bot operators; I interpreted his statement to mean that bots should be programmed to accommodate the setup deemed best by the community (instead of the community basing its setup on what the bots have been programmed to do). —David Levy 01:22, 4 August 2008 (UTC)

I hope he volunteers, then, to write those bots. SandyGeorgia (Talk) 01:26, 4 August 2008 (UTC)

SandyGeorgia, I don't know you either, so we're even on that one. My intent is not to offend bot programmers. My intent is to state my position that the primary basis for making a design decision should not be the convenience of implementing it. I stand by that position. Namespaces exist for specific purposes and pages should be placed in their most logical locations. To do otherwise diminishes the utility of the encyclopedia. Bots need to support that utility. Nothing more, nothing less. RichardF (talk) 01:36, 4 August 2008 (UTC)

SandyGeorgia, a bot that has been programmed to do something in namespace X can easily be modified to do the same thing in namespace Y. Bots can also be programmed to modify only tagged pages. RichardF doesn't need to write the bot for such a bot to be easily available. − Twas Now ( talk • contribs • e-mail ) 05:38, 5 August 2008 (UTC)

Ah, because I've been trying to be polite, I keep getting responses implying that I might be ignorant of simple coding :-) Fact is because of a series of bone-headed and unfortunate moves similar to the way this proposal was launched, we've lost a bot operator, who has found the work to be too much of a drain, just as the bot was due for a planned rewrite. We now need a rewrite and a new bot operator, and it is a time-intensive bot. Ideally it should be operated by someone who works well with others, so that lowers the pool of potential operators. SandyGeorgia (Talk) 08:06, 5 August 2008 (UTC)

No, the problem isn't your politeness (if you regard it as "polite" to refer to someone's good-faith attempt to improve the encyclopedia as "bone-headed"); it's your refusal to actually listen to what people are telling you instead of continually insisting that we don't appreciate the bot operators' hard work and don't care if we break their scripts. —David Levy 13:14, 5 August 2008 (UTC)

We have always had some 'portals', that is 'pages which aid navigation to both community processes and encyclopedia content', in other namespaces. For instance, the Main Page was the original archetype for portals... it is the 'portal' to all of Wikipedia. Likewise, Wikipedia:Current events is a 'portal' which deals with events in the world, but links to our encyclopedia articles on the topics and a few pages of community processes for updating the current events. Since the various types of 'featured' page were used far more to coordinate community processes than to showcase the materials they were housed in the Wikipedia namespace. The featured content page on the other hand was created primarily as a showcase with just general links to the community processes and thus makes sense in the Portal namespace. The 'problem' is that these pages were all linked together into a unified whole... which is actually a very good thing in terms of consistent navigation, but creates this conflict over which namespace they should reside in. --CBD 23:38, 3 August 2008 (UTC)

In response to SandyGeorgia's concerns above, if the original moves of Wikipedia:Featured content, Wikipedia:Featured portals and Wikipedia:Featured sounds didn't cause any hiccups with any bots (presumably there must be bots that use those pages), then moving the whole shebang now (either way) shouldn't cause to many hiccups, right? Deamon138 (talk) 23:56, 3 August 2008 (UTC)

No, the 'featured article' process is much older and more convoluted than those others. The featured picture process is also particularly involved, though I don't know if there are any bots tied into it. That said, any 'technological' issues resulting from page moves would require minor updates if any. --CBD 00:03, 4 August 2008 (UTC)

Oh I know that the others are probably more convoluted, but I made sure to explicitly word myself correctly, hence "shouldn't cause too many hiccups" (though I typoed by using "to" instead of "too"). Deamon138 (talk) 00:07, 4 August 2008 (UTC)

Responding to several queries above, I really don't know most of the answers, I'm asking the questions. GimmeBot and Rick Block's scripts were originally set up to deal with FAs, and have gradually expanded, but no, they don't cover all processes yet (at least, I don't think they do, I could be wrong). I don't know where the boundary is drawn if we start moving pages. I don't know how bots are affected, or what auxiliary pages and templates would go along in the move (I rarely visit portals, and have probably never been to the featured content portal). I'm asking that we take these issues into consideration, so bots and scripts aren't caught unprepared if pages are moved. We don't want to end up doing a lot of work manually in the event of a move. SandyGeorgia (Talk) 00:24, 4 August 2008 (UTC)

Erm is it just me, or hasn't User:Dr pda not been notified about this? Deamon138 (talk) 00:31, 4 August 2008 (UTC)

My scripts should be unaffected either way. Dr pda (talk) 00:50, 4 August 2008 (UTC)

Erm, four hours ago I was preparing to promote/archive some FACs and take the day off of Wiki when somebody moved the Island; I can only do so much at a time :-) I've now left notes for Rick Block, Gimmetrow and Dr pda. Next, the FLC directors need to be notified. SandyGeorgia (Talk) 00:52, 4 August 2008 (UTC)

We have to go back! (well maybe not) ;) Deamon138 (talk) 01:48, 4 August 2008 (UTC)

Too late, anyway. SandyGeorgia (Talk) 01:56, 4 August 2008 (UTC)

This would cause minor modifications to the tools I run, which now maintain WP:WBFAN, WP:WBFLN, and WP:WBFTN - which brings up the question of these pages as well. And, then there's WP:FA2008, WP:FL2008, WP:FT2008, in addition to WP:FAC, WP:FAR, WP:FFA, etc that Sandy mentions. Is there an exhaustive list of pages that are proposed to be moved? -- Rick Block (talk) 01:24, 4 August 2008 (UTC)

I haven't understood that issue yet either; Gimmetrow appears to have given his answer on my talk page. Thanks, SandyGeorgia (Talk) 01:28, 4 August 2008 (UTC)

Presumably FC, FA, FP, FL, FPo, FT, FS, and all sub-pages thereof. --CBD 01:36, 4 August 2008 (UTC)

Does that mean all archives, templates, instruction pages, candidate pages, criterion pages, everything related in any way? What about pages like WP:GO. What about Rick Block pages that track contributions? What about WP:FFA? Can anyone tell us exactly what is being proposed here, because I don't think it's as simple as the initial moves appeared. Is this anything related to featured content? I don't frequent portals, so it would be helpful if someone could spell this out clearly. SandyGeorgia (Talk) 01:43, 4 August 2008 (UTC)

No, pages that exist primarily for the benefit of editors should not be moved to the portal namespace (unless they're subpages or talk pages of pages that exist primarily for the benefit of readers). —David Levy 02:01, 4 August 2008 (UTC)

Yes, I propose that Wikipedia:Featured articles, Wikipedia:Featured pictures, Wikipedia:Featured lists and Wikipedia:Featured topics (along with their subpages and the corresponding talk pages) be moved (joining the three featured content pages already located in the portal namespace).

The pages listed above by Rick Block pertain primarily to managing behind-the-scenes Wikipedia processes (not to guiding readers to encyclopedic content), so they belong in the Wikipedia namespace. —David Levy 02:01, 4 August 2008 (UTC)

Still confused; why would you move those pages, for example, and not WP:FFA? What is the difference? I'm really not seeing the distinction you all are drawing, perhaps because I don't venture into portal space and have never found them useful. I'm still unclear how you are defining "subpages". SandyGeorgia (Talk) 02:17, 4 August 2008 (UTC)

The portal namespace's purpose is to guide readers to encyclopedic content of particular value and/or significance. WP:FFA exists not for this purpose, but for the benefit of editors (who are encouraged to improve the listed articles).

A subpage is a page that exists at another page's location followed by a slash and additional characters. For example, Wikipedia:Foo/Bar would be a subpage of Wikipedia:Foo. —David Levy 02:26, 4 August 2008 (UTC)

Per the original post that started this thread:

... but moving the other three featured content pages (Portal:Featured content, Portal:Featured portals and Portal:Featured sounds) to the Wikipedia namespace would make more sense than the current setup ...

Yes, do that. The toll of the alternate proposal (moving scores of long-standing pages to portals) is too high, and unnecessary. It appears to be a proposal based on an after-the-fact definition of what kinds of pages are supposed to be what, and most of our readers (heck most of our editors) don't know the difference. The cost of switching over will be too high, with no payout. The toll of the proposal has already been too high. SandyGeorgia (Talk) 01:49, 4 August 2008 (UTC)

1. What toll is that?

2. Do you understand what the portal namespace is for? I'm not being sarcastic or derogatory; you expressed a lack of familiarity, and I'm not sure that you realize that the distinction isn't arbitrary. This proposal exists "after the fact" not because someone suddenly redefined the namespaces' purposes, but because the portal namespace didn't exist during Wikipedia's formative years. —David Levy 02:01, 4 August 2008 (UTC)

1. The toll of redesigning and programming new bots that affect many processes, templates and pages (beyond featured content).

2. No concern that I will misinterpret that you are being sarcastic or derogatory; I have already mentioned several times that I don't see/understand the utility/urgency of the "portal" distinction, and that I have almost never visited portals on Wiki, and I appreciate your explanations. I doubt that I'm an unusual editor in terms of rarely frequenting portals, and I doubt that our readers know if they are on a portal or a page of any other name. I understand the expressed intent of portal namespace, but I'm unconvinced it matters to or is noticed by readers. From a practical point of view, pls help me understand why it matters what a page is named, particularly considering the toll of switching featured content pages over, when those pages existed before portal space, and many processes have been built up around them.

3. What does matter is that Wiki is a volunteer venture, and if we lose people who support the processes in the interest of name changes that have little bearing on how our readers view pages, we lose. SandyGeorgia (Talk) 02:45, 4 August 2008 (UTC)

1a. You stated that "the toll of the proposal has already been too high," and I interpreted this to mean that said toll already had been paid. Perhaps I misunderstood.

1b. I've seen no indication that the proposal's implementation would require anything more than minor modifications to bots (and I have a sufficient understanding of bots to strongly believe that this would be the case).

2. The distinction matters because we're trying to guide readers to pages that benefit them. You're basically citing our partial failure to properly organize the site as justification for itself. (If we were to consistently place portals in the correct namespace, readers would come to better understand and utilize the distinction. By placing some portals in the Wikipedia namespace, we deprive them of the ability to rely on the prefix to guide them to their desired content.)

3. I don't see how/why the proposed changes would drive away contributors. —David Levy 03:10, 4 August 2008 (UTC)

"Can anyone tell us exactly what is being proposed here, because I don't think it's as simple as the initial moves appeared." It isn't as simple you're right. So I think it's an open ended question now. Maybe everyone should suggest what limit they would put on stuff to move. Deamon138 (talk) 01:51, 4 August 2008 (UTC)

I believe that this has been addressed above. —David Levy 02:01, 4 August 2008 (UTC)

Arbitrary break 1

Quote from original proposal:

...moving the other three featured content pages (Portal:Featured content, Portal:Featured portals and Portal:Featured sounds) to the Wikipedia namespace would make more sense than the current setup. Opinions? —David Levy 22:09, 3 August 2008 (UTC)

I disagree with this assertion and oppose any such move. Those pages are for readers and they belong in portal namespace. Moving them back would be a regressive action. The originally proposed moved pages are for readers as well and they also belong in portal namespace. RichardF (talk) 02:44, 4 August 2008 (UTC)

I largely agree with you, of course. My point was that it would be better to have all of these pages in either namespace than to have them divided between the two. —David Levy 03:10, 4 August 2008 (UTC)

If we do define featured content into Wikipedia space then that might argue for some sort of 'clarification'/limitation of Portal space to only apply if the underlying topic is itself a subject of the encyclopedia. We don't have encyclopedia articles on our featured process, ergo a page on that theme has a 'non encyclopedic' topic and falls into the Wikipedia namespace by default... despite having 'reader oriented' content which isn't normally found there. Of course, that wouldn't jive too well with Portal:Contents or Portal:Current events. At that, Help:Contents is directed at both readers and editors too... its a 'portal', in the help namespace. The problem is that the namespace standards bend alot, especially around the 'johny-come-lately' portal namespace.

All of the things which fit the 'editors AND readers' criteria of 'portal' but aren't in the Portal namespace seem to reside in the namespace of their primary topic... the Main Page 'topic' is the encyclopedia as a whole and thus it exists in the primary 'Article' namespace, the 'topic' of Featured articles is a wikipedia process and thus it is in the Wikipedia namespace, Help:Contents is about help and in that namespace, et cetera. They could all be housed in the Portal namespace, but they have strong connections to the namespaces they are in. Maybe we just leave them as exceptions... pages so closely bound up with a non-portal namespace that they reside there despite being 'portals'. --CBD 11:33, 4 August 2008 (UTC)

See Move Main Page to different namespace for another example of attempting to place Wikipedia pages based on logical design considerations, rather than inertia. RichardF (talk) 12:19, 4 August 2008 (UTC)

As far as I can tell, the only opposition to moving Wikipedia:Featured articles, Wikipedia:Featured pictures, Wikipedia:Featured lists and Wikipedia:Featured topics, their subpages, talkpages and talksubpages, is that it might create complications with automated scripts. I'm sure the owners of the bots affected are grateful for that consideration, and as mentioned, it is vital that any affected operators be made aware of this change before it is made so they have the opportunity to make any necessary changes; however as Rick Block has said above, solving such problems are almost certain to be trivial (I can't think of a situation where it would require changing more than a handful of variables). Are there any other reasons not to consolidate these pages in the Portal: namespace? Happy‑melon 12:41, 4 August 2008 (UTC)

Looking at the subpages of WP:FA (they're only 5 of them), they seem to be about the process, i.e. they more properly belong in the wikipedia namespace than the portal namespace. On the other hand the subpages of WP:FP are more like sub-index pages (arguably sub-portals). WP:FT's subpages are mixed but are mostly the topic boxes themselves (which are navigation boxes that would seem to naturally fit into the template namespace, but they don't seem to be transcluded much of anywhere). I think the bottom line is we need to treat the subpages on a case-by-case basis. Also, it would seem odd to me to have FA and FFA in different namespaces. Will we keep the WP:FA etc. redirects (even though they'd become cross-namespace redirects)? I understand the idea behind these moves, but is there any practical problem so long as Portal:Featured content remains in the portal namespace? It seems to me that this page is the portal page for featured content. You could view WP:FA as a sub-portal page for featured articles, but I actually don't think that's its (current) main purpose. Instead, I think WP:FA serves as the official (process-related) list of FAs. I'd imagine a featured article portal page built from scratch would end up far different, and perhaps rather than move these pages someone should build portal versions of them. I don't actually care much about this, except that I'd strongly prefer there be some easy to mechanically parse page that lists all the FAs (and other featured content types). -- Rick Block (talk) 14:16, 4 August 2008 (UTC)

It would probably be better to move them one at a time to give everyone time to update any bots/scripts. SharkD (talk) 14:37, 4 August 2008 (UTC)

Certainly the "move all subpages" feature should not be employed :D I think case-by-case is the way to proceed. Happy‑melon 15:14, 4 August 2008 (UTC)

1. The current interface already comes across as a series of portals. I don't see a problem with having process-related pages as portal subpages (given the fact that the various processes fuel the portals), but a viable option is to leave them in the Wikipedia namespace (moving over only the reader-oriented pages).

2. WP:FFA doesn't strike me as reader-oriented, but I'd be fine with moving it to something along the lines of Portal:Featured articles/Former featured articles.

3. The practical problem is that the current setup is sloppy and confusing. If we want readers to understand and utilize the distinction between the portal and Wikipedia namespaces, we need to abide by it. —David Levy 15:22, 4 August 2008 (UTC)

No one yet has answered the simple question of what benefit accrues to either our readers or editors by simply renaming a page from Wikipedia to Portal, with no other content or any other type of change to the page. Unless there is something in the works that hasn't been explained, it looks like change for the sake of a name only, with no other effect except work for bots/scripts. No one has addressed how this name change affects readership in any way. On the other hand, there have been a lot of dismissals regarding the bot/script work that will be needed to address the change, coming right on the heels of other bot/script issues caused by another recent announced change (this deprecation of people who make the processes work is an ongoing issue at Wiki). Given that Gimmetrow has not weighed in to say that the updates needed are trivial, I'm finding it curious that others are stating such. Perhaps the transparency and efficiency of the amount of work that has gone into building articehistories, archiving FACs and FARs, converting templates on GAs and PRs, renaming FAs, tallying GAs, removing GAs once they're promoted FA, and much more than I can remember has gone unnoticed because it has been done so well. I'm wondering who is planning to take on all of these chores? SandyGeorgia (Talk) 14:52, 4 August 2008 (UTC)

I remember saying this before, although I can't remember if it was to you or someone else: not all changes have to be attempts to 'solve a problem' - genuine improvements are just as acceptable. It would not be correct to say that WP:FA being in the Wikipedia: namespace is a serious problem, but that doesn't mean it shouldn't be moved. Currently we have a page that is very heavily geared towards the readers, in a namespace that is not intended to hold reader-facing content. Imagine the situation whereby a derivative project (bringing static copies of the wikipedia encyclopedia to isolated African villages or something) is considering how best to use its meagre funds to do the most good. An obvious decision is to take a database dump and take into the wilderness only that content that is 'reader-facing' - there's no reason why they would need the User:, Help:, xxx talk: namespaces, etc. The Wikipedia: namespace is very likely to get the chop in that situation, leaving the derivative project without a valuable reader-facing page. When viewing wikipedia as a cohesive whole, where everything is just a click away, it's easy to forget that it's supposed to be able to be broken up in just that fashion. We're making a small amount of work for ourselves in order to provide a better experience to those who use and reuse our content. Isn't that pretty much the definition of our mission??

I'm stating that the changes required will be trivial because all of my bot-operation experience tells me so: I simply cannot think of a way in which any bot or script could be sensibly coded such that it is not so. If in fact Gimmetrow's code is structured in such a fashion, I would be very interested to see it so as to develop my own coding skills, as well as to render any assistance as I might be able to provide. I am not aware of any "deprecation" of editors' efforts in any areas of wikipedia I have been involved with. Although I would never claim to speak for him, my reading of the message on your talk page is simply that Gimmetrow is concerned that his extensive 'backstage' work is limiting the time he spends writing articles, a legitimate concern. Of course I'm as anxious as you are to receive confirmation from him that this proposed move does not pose any problems for him or his bot scripts. Happy‑melon 15:14, 4 August 2008 (UTC)

I think I've made my concerns as clear as I'm able, so I'm pretty much done here; I hope I'm proven wrong and others will step up to assume all this work that they believe is so simple (maybe it is, time will tell), but I've got a very bad feeling about this. Happy-melon, are you aware of the number of hours Gimme puts in to keep a large number of processes, pages and talk pages clean, tidy and afloat, the amount of talk page monitoring and feedback required, including abuse from other editors, and are you offering to take on all of that work? I see a lot of people stating it's a simple matter of coding, without apparently factoring the hours of dedication that go into all the maintenance work that has kept everyting functioning so well for almost several years now. SandyGeorgia (Talk) 15:45, 4 August 2008 (UTC)

Why do you keep replying to us as though we've declared that we don't appreciate Gimme's hard work and intend to break his scripts and drive him away from the project? You seem to believe that we're referring to his tasks as trivial, when all that we're saying is that it should be trivial for him to update his scripts and continue utilizing them as usual. And if, for some reason, that isn't the case, we want to hear from him and address the situation accordingly.

I'm simply baffled by your response. —David Levy 15:56, 4 August 2008 (UTC)

Or, alternately, perhaps Rick Block could pick up some of the slack? I do have concerns that it is much more than just coding, and that we need an experienced and courteous editor involved, so that we don't get into BetaCommandBot scenarios, as the "bot" is frequently mistakenly attacked for "closing" FACs, FARs, GANs, etc. and often has to deal with irate editors for merely updating templates into articlehistory. SandyGeorgia (Talk) 15:58, 4 August 2008 (UTC)

What are you talking about? I don't understand what scenario you believe might arise. —David Levy 16:02, 4 August 2008 (UTC)

1. I've expressed my opinion that the current setup is sloppy and confusing and that the pages in question are located in an incorrect namespace (based on our standards). The basic content need not change, as it already reflects the portal format (which is why it doesn't belong in the Wikipedia namespace).

You've cited our users' (including your own) lack of understanding regarding the portal namespace's purpose, and I contend that consistent implementation would help to alleviate the situation.

2. You need to understand that to someone with basic knowledge of how scripts work, the idea that a mere namespace change would necessitate a dramatic overhaul seems far-fetched. It really should be as simple as updating some parameters.

Nonetheless, no one is advocating that we proceed before hearing from the bots' operators, let alone that we ignore their input and break things. We're assuming, for the sake of discussion, that the proposed moves would require only minor scripting changes, and if we learn otherwise, we can go from there. Okay? —David Levy 15:22, 4 August 2008 (UTC)

I just looked into Portal:Featured content and WP:FA and I think current classification is justified. While the former looks like a geniune portal, the latter is just a technical list intended mainly for editors. The last statement is also true for other lists (WP:FL and WP:FP). WP:FT may be somewhat different, but I don't see any compeling reason to move it either. Readers don't usually come to Wikipedia to read a featured article; they just want to read something about topics they are interested in. Ruslik (talk) 16:32, 4 August 2008 (UTC)

On the contrary, our featured content exists primarily for the benefit of readers (many of whom do seek it out, as traffic data clearly indicates). It's for the benefit of editors only in the respect that their efforts to create and improve content are motivated by the attention that it will receive from readers when promoted to "featured" status.

Why would we have a portal consisting of links to content intended primarily for editors? That simply doesn't make sense. —David Levy 16:45, 4 August 2008 (UTC)

This is a reply to SandyGeorgia because I expect I might be one of those editors viewed as guilty of, "No one has addressed how this name change affects readership in any way. On the other hand, there have been a lot of dismissals regarding the bot/script work that will be needed to address the change..."

Back at Portal talk:Featured content#move to portal namespace, I wrote:

I posed this basic question at the Portal peer review: Contents and megaportals. Viewing portals as the doorways to the encyclopedia, I support having this and all six featured content pages in portal space. Project-related pages for peer reviews and candidacies can stay in project space. To me, that's just the most consistent organizational message to send to novice readers, in particular.

Four key namespaces of Wikipedia
Portal namespace: The doorways to the encyclopedia. Contents/ (Outlines) → Featured content → Megaportals → Current events/ → Portals →	Main namespace: The encyclopedia's articles.	Category namespace: The network of classification systems to organize pages.
Wikipedia namespace:  The project's workspace, including WikiProjects on developing high quality articles in disciplinary subject areas and the Bookshelf.

RichardF (talk) 20:52, 2 January 2008 (UTC)

My interest in moving the reader-facing featured content pages to portal space is because that is my understanding of how Wikipedia is designed. If I'm mistaken on this, someone please enlighten me. Taking the next step, the issues of implementation must come secondary to issues of design. Otherwise, nothing difficult would be attempted. The benefits of implementing a well-developed design for Wikipedia are that all parties concerned – readers and the community that implements this volunteer project – will better understand how the encyclopedia and its supporting project are organized, making them easier and more productive to navigate. Any inferences that my intent is to devalue the efforts of any project participants, simply because I have taken the position that top-level design considerations should take precedence over non-trivial yet manageable implementation issues, are misplaced. RichardF (talk) 16:38, 4 August 2008 (UTC)

David Levy said, "You need to understand that to someone with basic knowledge of how scripts work, the idea that a mere namespace change would necessitate a dramatic overhaul seems far-fetched. It really should be as simple as updating some parameters." I agree. While I know next to nothing about coding a bot, for someone well versed in that, I can forsee them finding this as hard as a user of Microsoft Excel would if he changed the location of lots of variables on his spreadsheet and then had to update lots of the other cells that refered to the variables original location i.e not very hard for that person. So until we hear otherwise from one of the bot operators, there's no need to cast this proposal down in flames. Unless there would be a serious problem with a bot due to this, I fail to see any reason not to go through with this proposal. Why shouldn't (at least, content is debatable) featured portals and sounds be in the same namespace as featured articles, pictures, lists and topics? Deamon138 (talk) 16:56, 4 August 2008 (UTC)

It's not even that difficult: I would describe it as being equivalent to having a large array of cells containing data (Wikipedia pages), and a handful of cells (variables in the program) that point to particular cells in that array (thereby pointing to particular pieces of data, in this case Wikipedia pages). All the cells that perform calculations and computations refer to those 'pointer' cells rather than the raw data. So updating the page accessed is as simple as changing the one or two variables in the bot script that contain the 'address' of the page. Those variables are then read by the program every time it needs to know where to go. Happy‑melon 19:08, 4 August 2008 (UTC)

If I've read this correctly, I believe this is basically what I meant with my Excel analogy. Deamon138 (talk) 20:57, 4 August 2008 (UTC)

Strongly agree with everything RichardF said above, especially that clear infographic explanation.

All 7 of the featured content portals belong in portalspace. -- Quiddity (talk) 01:32, 5 August 2008 (UTC)

• For what it's worth, I agree with Rick Block above (I came to this discussion when what appeared to be my entire watchlist was moved the other day). It seems more appropriate to me for WP:FA to be the hub for WP:FAC, WP:FAR, WP:WIAFA, WP:FFA then for P:FA to serve as the hub. Would we also move WP:GA to P:GA? And have P:GA be the hub for WP:GAN, WP:GAR, etc? I would rather a P:FA start from scratch, and consist of something more creative and inviting than a simple directory of FAs. I agree with Rick that WP:FA is more of an official list for project purposes than something intended to be a gateway for readers. WP:FA, WP:FAC, WP:FAR, etc., have been clearly designed as a cohesive unit for as long as I've participated there. --JayHenry (talk) 04:55, 5 August 2008 (UTC)

• I don't support moving at this time. If we actually intend to move all pages that readers would be interested in to non-project namespaces, we should begin with more crucial ones like WP:NPOV and WP:V. The featured article list is not useful without those pages, which are necessary for a basic understanding of what it means for an article to be featured. I also believe that the featured article process should remain primarily internal, until the level of quality assurance matches what would be expected from a professional publication. We are there in some aspects but not in others. Christopher Parham (talk) 05:22, 5 August 2008 (UTC)

1. WP:NPOV and WP:V are primarily for editors. The portal namespace is for the benefit of all readers (including those who never edit the site).

2. Your desire to keep featured articles "primarily internal" clearly reflects neither consensus nor the current state of affairs. These pages are quite public, irrespective of which namespace they're in. It's just sloppier and more confusing to have them divided between two different namespaces. —David Levy 05:58, 5 August 2008 (UTC)

"Sloppier" may soon take on a whole new meaning throughout the featured content processes and article talk pages. After other unannounced actions (not just this one) just as planned bot upgrades were in the works, we've lost a crucial bot operator to the featured content and other processes, who has found the work to be a drain. (No wonder: no sooner do you write something, it gets changed, unannounced.) In all this discussion, I still haven't seen anyone stepping up to volunteer to write and run a new time- and customer-intensive bot, but minus one hard-working bot operator who works well with others and keeps a lot of processes and pages afloat, we could be looking at a "sloppy" transition. Until a new bot operator appears, we can go back to managing FAC and FAR manually (if an admin resurrects some of the old templates); I don't know about the other processes, I don't know who is going to help with the work, but we're going to need help, and editors may have forgotten what it was like in the "olden days" (two years ago, before GimmeBot) when things were done manually. Of course, what we name the page we park all of this fabulous content on is important, too, as long as we retain good people who can put something on that page; I hope we'll find someone to do the work as well as Gimmetrow has. I've tried to say this as politely as possible, and the message on my talk page after all this started was straightforward, but perhaps polite discretion is not an effective communication method among the increasingly younger Wiki population; if anyone still doesn't understand, I don't know how to make it clearer. Happy-melon, you've said the work is "not even that difficult": are you willing to write, maintain and run the bots that keep all of the featured content processes, and some others, afloat, and deal with the endless questions and requests from editors that go along with the task? We need a new bot operator in less than a few weeks, and the bot was due for a rewrite. SandyGeorgia (Talk) 07:33, 5 August 2008 (UTC)

Hit me :P. Happy‑melon 09:20, 5 August 2008 (UTC)

I've started summarizing on my talk page, and we'll see which way it goes from here, but I don't think it's going to be easy. Please follow there? It's a big commitment, and what we've seen over the last few months is that bot work is undervalued, underappreciated, undernoticed and your work can be swept away by the whims of others just after you complete it :-) If you're on board, we need the help now. SandyGeorgia (Talk) 15:38, 5 August 2008 (UTC)

1. What bearing does this have on the proposal? Over and over again, you've pointed out that no one is volunteering to "write, maintain and run" new bots (though Happy-melon just did), and over and over again, we've tried to explain to you that this change wouldn't necessitate new bots or even major changes to the existing ones. But you just keep attacking this straw man, and you're even convincing other people to oppose the proposal on the basis of this nonexistent threat.

2. Again, Happy-melon's comment regarding the work being "not even that difficult" referred to the actions necessary to update the existing scripts. No one has claimed that bot authorship or operation is trivial. Why do you continue to misrepresent people's comments after this has been explained to you? —David Levy 13:14, 5 August 2008 (UTC)

No bearing at all on the proposal now; the damage has already been done. Perhaps developers and other editors will consider in the future, though, how very important things like communication, coordination and respect are to the well-being of the entire project. What happened here is that we have a sideshoot to fundamental processes, where people never even discussed any of it on the main process pages, causing a lot of problems for basic processes. I see that you don't grasp the full consequences when key bot writers and operators become so discouraged that they give up. As I see it, Portals in a portal may make sense, Sounds for some reason set itself up in a portal, and now long-standing processes are supposed to change their names to agree with those two in spite of no discernible benefit to our readers, yet none of this was ever discussed on any of the featured content pages. I'm not misrepresenting you David Levy; I'm trying as politely as I can to get you to open your eyes wider to the broader consequences of what some think are trivial actions and what happens when key participants become discouraged. I'm glad Happy-melon just volunteered (how long have I been banging this drum to make that happen? :-)) If you hold me responsible for the failure of this proposal, I do hope that as a result, editors making similar proposals in the future will think long and hard about the importance of involving others in key changes and decisions, to avoid unnecessary work and agida. And respect the gnomes and bot operators when proposing or implementing change, because doing it without them is not going to be fun. SandyGeorgia (Talk) 15:38, 5 August 2008 (UTC)

1. What are you talking about? I erred in moving some pages without adequate discussion, they were quickly moved back, I repeatedly apologized, and then I followed your advice to initiate a centralized discussion on the matter. Why, when you acknowledge that the proposal's outcome has no bearing on the bot situation, do you seek to derail it (by repeatedly implying that it will break bots)? To punish me for making a mistake?

2. "No discernible benefit to our readers"? Have you read the entire discussion? If so, please explain why you disagree with our rationales (instead of issuing a blanket implication that they don't exist).

3. Yes, you are misrepresenting people's statements. When someone notes that the namespace change would necessitate only easy updates to the scripts to ensure their continued functionality, you misconstrue this as a declaration that the bot operators' work itself is easy (and question whether someone else intends to step up to replace the scripts that we purportedly intend to recklessly break because we've deemed them unimportant). You've done this over and over again, despite attempts to alleviate any possible confusion on your part.

4. Once again, you've falsely implied that we're failing to "respect" the gnomes and bot operators. No, we're not. No one has denigrated their work, they've been invited to participate in the discussion, and the response that we've received thus far confirms our belief that the proposed namespace change would necessitate only minor script updates. And yet, you just keep insisting that the sky will fall. It's quite frustrating. —David Levy 18:28, 5 August 2008 (UTC)

Oppose per Christopher, Sandy, and Jay. No one has articulated how the reader will be in the slightest way helped by the move. And no one suggesting it has the first clue how awful it is to manually close the reviews. If Gimme is not onboard, I want nothing to do with this. Marskell (talk) 07:57, 5 August 2008 (UTC)

1. It has been articulated how the reader will benefit; he/she will be able to rely on the namespace prefixes to understand which pages exist for his/her benefit (as is supposed to be the case). And as noted by Happy-melon, the change will ensure that entities reusing our content are able to include all of the reader-oriented pages (instead of omitting some because they reside in a namespace intended for editors). It's for reasons such as these that we have the portal namespace.

2. Contrary to the FUD spread by SandyGeorgia, the implementation (or non-implementation) of this proposal has absolutely no bearing on whether Gimme continues operating his bots. (He's indicated that the workload is too great, but that's a separate issue.) For some reason, SandyGeorgia refuses to stop insisting that a simple namespace change would necessitate a thorough code rewrite (despite several bot operators' insistence that it wouldn't).

3. What setup do you advocate? Should we leave some of these pages in the portal namespace and others in the Wikipedia namespace? —David Levy 13:14, 5 August 2008 (UTC)

Oppose at this time, after some thought. I see David's point about keeping things logical so that all Featured content is in the same place. However, I rarely visit portals and I tend to believe that few Wikipedia readers do, either. I think the move of some of the Featured content pages may have been ill-advised, and I do not see the problem with keeping FA in WP: space. Also, no one's going to look for FA at P:FA, and the move to portal space can only detract attention from FA (because portals aren't, for the most part, heavily visited). Firsfron of Ronchester 08:37, 5 August 2008 (UTC)

Arbitrary break 2

Several portals are among the most highly visited pages on Wikipedia. Repeatedly devaluing portal space devalues Wikipedia.

Wikipedia article traffic statistics Most viewed articles in February 2008
Rank	Article	Page views
11	Portal:Current events	1,248,112
17	Portal:Contents	1,072,081
36	Portal:Featured content	675,223
262	Portal:Contents/Portals	277,552
427	Portal:Science	216,781
466	Portal:History	208,879
761	Portal:Biography	160,746
844	Portal:Arts	151,725

RichardF (talk) 12:55, 5 August 2008 (UTC)

This statistics is somewhat misleading. While these number look big by absolute value, they pale in comparison with other pages: main page—453,219,819; Barak Obama—2,253,851. Ruslik (talk) 18:51, 5 August 2008 (UTC)

1. The statistics were posted in response to the speculation that "few Wikipedia readers" visit portals. Obviously, that isn't true.

2. You misread the list; Special:Search had 453,219,819 views, with Main Page receiving 136,036,288 views. —David Levy 19:07, 5 August 2008 (UTC)

Put another way, the rankings show the relative popularity of page visits. Eight pages in portal space make the top 1,000. Four of the 548 "regular" portals (~ 0.7%) are on that list. This is compared to a liberal count of 1,000 out of 2,490,801 articles (~ 0.04%). And, Portal:Current events (rank: 11, visits: 1,248,112) is more popular than Sex (rank:12, visits: 1,221,250)! >;-o) RichardF (talk) 19:36, 5 August 2008 (UTC)

Why do you think what the page is named has anything to do with those numbers, rather than (as an example), the prominent placement of the featured content portal on the main page? Why would the numbers be any different if the page prefix was Wikipedia or Portal or JoeBloe? (Separately, I've been visiting that portal since this discussion started and I became aware of it, and I'm more than slightly concerned that we are elevating processes to the main page, several of which haven't yet attained consistent quality standards or widespread input. I'm also concerned that there's no notification of articles randomly run on that page, so that vandal protection can be put in place. And concerned that random generation of some very old and not-up-to-standard pages are put forward to our readership. As an aside, on one of my few visits, there was an HTML error on the page.) SandyGeorgia (Talk) 19:43, 5 August 2008 (UTC)

The point is not that people read the pages because of how they're named; it's that people visit portals. —David Levy 20:36, 5 August 2008 (UTC)

Consistent quality standards? Advance notification of 'random' results so that pages can be protected? Processes?

I think you've gotten the wrong idea about the featured content page. See, it has very high 'quality standards' for its 'processes'. Content to be displayed there is protected in advance absolutely never that I can recall. 'Old and not-up-to-standard' pages are removed on a very timely schedule of when the mood strikes me. 'Widespread input' is taken from the 20,000+ people who visit the page on average each day. Suggestions are always welcome. Or just go ahead and change anything you like... editing freely is 'in process'.

These are the 'processes' which have been in place since before FC was 'elevated to the Main Page' and, more significantly, the sidebar... about a year and a half ago. --CBD 21:38, 5 August 2008 (UTC)

1. As RichardF pointed out, readers do visit portals. If we were to make it easier for them to rely on our namespace system (so that they wouldn't have to waste their time scouring the Wikipedia namespace for content relevant to their needs), the portals' popularity would increase even more.

2. "The problem with keeping FA in WP: space" is that we're trying to convey to readers that said namespace contains content intended for editors. Do you not see the benefits of organizing the encyclopedia in a consistent, understandable manner?

3. In case it wasn't clear, all of the existing page titles and redirects (including shortcuts) would permanently function as redirects, and the entire infrastructure through which users are led to the pages would remain the same, so no one would have a harder time finding them. You aren't suggesting that people would stop visiting/following links to the featured article page if its name contained "Portal:" instead of "Wikipedia:", are you? —David Levy 13:14, 5 August 2008 (UTC)

Do you not see the benefits of organizing the encyclopedia in a consistent, understandable manner? I believe I already stated immediately above that "I see David's point about keeping things logical so that all Featured content is in the same place," so such a response seems strange, like what I wrote wasn't read. Repeatedly devaluing portal space devalues Wikipedia. is a sentence I cannot parse; have I "devalued" portal space repeatedly? I stated I believed few readers visited portals. This was a statement based on my own experiences, and I appreciate the statistics links, which are the only parts of the above two arguments that make any sense to me. Firsfron of Ronchester 13:38, 5 August 2008 (UTC)

Yes, you indicated that you "see [my] point about keeping things logical so that all Featured content is in the same place," but that could refer to having all of the featured content in the Wikipedia namespace (which jibes with your statement that you "do not see the problem with keeping FA in WP: space," which is what I was replying to). I'm referring to the importance of having all pages intended to guide readers to encyclopedic content (not merely the featured content pages) in the portal namespace.

To clarify, what setup do you advocate for the featured content pages? (Should they all be in the Wikipedia namespace, or should we retain the seemingly random mishmash that we currently have?) —David Levy 14:11, 5 August 2008 (UTC)

Readers will still visit these portals no matter what they are named. SandyGeorgia (Talk) 15:38, 5 August 2008 (UTC)

I'm glad to see you acknowledge that they're portals. —David Levy 18:30, 5 August 2008 (UTC)

(Ec)

David, first off, we should all admit that no one has a free pass to make significant namespace changes, but that no one has a veto over them either. Perhaps this change can happen. But the people who are directly involved in the FA process should be respected. It's not OWN; it's a simple courtesy that makes sense for the encyclopedia. Sandy has literally made tens of thousands of FA-related edits: to article space, to Wiki space, to Talk:Template, and to just about every other namespace that exists. I find some of your responses to her needlessly glib (including the last one). You can go ahead and make a change, but she'll be the one who has to deal with all the shit that falls out afterwards (and there will be shit—in templates, in redirects, and so on). I'll personally claim thousands of similar FA edits, though not quite tens of thousands. Raul's opinion also matters, of course, and he does still have a de facto veto.

So, speaking as a person involved in FA, I'm wondering: "what's broken?" Nothing, that I can see. Cosmetic name changes for the sake of cosmetic name changes make no sense to me with a process this large and this old. You keep mentioning a mish-mash; sure, FA is a mish-mash in some ways. But it keeps working. You can tell me in theory that a name change make sense, but until you have a plan for the practice of it, there's nothing here. And by a plan, I don't mean a table suggesting "this" be renamed "that"; I mean you agreeing to take on specific work that Sandy, Gimme, and others do at present. In the absence of such, we would be giving the pig new lipstick for no needed reason.

Finally, the logic behind this proposal is half-done. If we want to move FA to Portal, why not V, NOR, and NPOV (as someone hinted at above)? Those are "reader facing" pages. What about the deletion process? What about GA and B-Class and all of the other assessment processes? What about all those essays in user space? Perhaps, David, you need to think about a wiki-wide proposal for invigorating the Portal namespace and/or deprecating the Wikipedia space. I have had thoughts of that sort over the years and might actually support you. Unilaterally renaming FA pages is not the way to begin, however. Marskell (talk) 19:38, 5 August 2008 (UTC)

1. No one is being disrespected. I initiated this discussion at Sandy's request and immediately invited all concerned parties to participate. I don't understand your objection to my replies, as I've continually assumed good faith on Sandy's part (and replied in kind), despite Sandy's repeated distortions of other users' comments and reference to my good-faith attempt to improve the encyclopedia as "bone-headed."

And when I performed the moves, it was because I mistakenly believed that they would be uncontroversial, not because I disrespected anyone. I've repeatedly apologized for my error, so I don't know what else you want from me.

2. Please expound on your claim that there will be a large amount of "shit" to deal with "in templates, in redirects, and so on." (For the record, I was in the process of updating templates when it became clear that my moves wouldn't stand.)

3. Is the current setup broken? That depends on one's definition of the term, but I'll say "no." Could it be improved? Yes.

As has repeatedly been explained, non-editing readers are supposed to be able to ignore the Wikipedia namespace entirely. By placing some portals there, we deprive them of this ability (by forcing them to waste their time scouring the Wikipedia namespace for pages that are relevant to their needs).

And as Happy-melon noted, entities that reuse our content are supposed to be able to reply on this demarcation to determine which pages to include (with the Wikipedia namespace being an obvious choice for omission).

It's for reasons such as these that we have separate namespaces. Why else would they even exist?

And frankly, it's downright unprofessional to have the featured content pages split between two namespaces. (That—and not anything confined to the FA segment—is the "mishmash" to which I'm referring.) As I noted in the beginning, even placing all of these pages in the Wikipedia namespace would be preferable to the status quo.

4. When you suggest that I should "[agree] to take on specific work that Sandy, Gimme, and others do at present," what do you mean? Nothing about this proposal should have any effect on your work (which I sincerely appreciate). I'm simply baffled by comments along these lines, as it almost feels as though we're discussing two entirely different things.

5. WP:V, WP:NOR, WP:NPOV, the deletion process pages, the assessment process pages, and most essays are for editors. Pages intended for editors do not belong in the portal namespace.

More specifically, the portal namespace is for organized pages that guide readers (including non-editors) to specific types of encyclopedic content, not for just any reader-oriented pages.

6. I don't understand what you mean when you suggest that I "think about a wiki-wide proposal for invigorating the Portal namespace and/or deprecating the Wikipedia space." We already have standards in place. All that we need to do is follow them. —David Levy 20:36, 5 August 2008 (UTC)

I think Marskell has a point about making a clearer proposal for the Portal space to have the role you suggest. There's never been a clear expression of consensus on the role or purpose of the Portal namespace, and the description of them that you provide above sounds little different from a list, which fits fine in the mainspace. Personally I think Portals are like road signs in a world where everyone can teleport from place to place - intended to be helpful but thoroughly outmoded by search. Clearly establishing the role of the Portal namespace (that is, determining the "design considerations" Richard mentions) would be a better place to start than this move. Christopher Parham (talk) 01:44, 6 August 2008 (UTC)

Is there really a dispute as to the portal namespace's basic role? I don't mean the exact page format. Is there actually a dispute regarding the claim that portals serve to direct readers (including non-editors) to specific types of encyclopedic content?

To me, asking why WP:V, WP:NOR, WP:NPOV, the deletion process pages, and the assessment process pages don't belong in the portal namespace (as Marskell has done) demonstrates a lack of understanding regarding its fundamental purpose. All of those pages clearly are intended for editors, and referring to them as "reader facing" (as Marskell has done) implies that every page on the site is "reader facing." —David Levy 08:51, 6 August 2008 (UTC)

I don't dispute that portals serve to direct readers to encyclopedic content, but this function is also served by pages in many other namespaces, and there is no need to make every such page a portal. The portal space in my view exists to complement existing, similar pages in other namespaces, not to absorb them.

To your second point, I don't think it is in the spirit of the wiki to make such a stark distinction between readers and editors as you do. Ideally every reader would read WP:NPOV and WP:V to better understand the point of this project and what we are shooting for in these articles. Certainly nobody has a good understanding of what it means to be "featured" without reading those pages. I think one of the most attractive aspects of the wiki process is that readers are invited to look behind the curtain and making stricter delineations between "editor" space and "reader" space is contrary to this. Christopher Parham (talk) 05:13, 7 August 2008 (UTC)

1.Please cite examples of the pages in question. (I'm not denying their existence; I just want to know what we're discussing.)

2. I'm not suggesting that non-editors can't benefit from reading our policies, guidelines, et cetera. I'm saying that they should be empowered to decide for themselves. If someone wants to read the encyclopedia only, he/she shouldn't have to scour namespaces intended for different types of pages to find the content that he/she seeks. You seem to be suggesting that this inconsistency is good (because it increases the likelihood of users accidentally encountering pages that you believe they should read), and I couldn't disagree more.

And again, our encyclopedic content isn't merely for use at this website. To borrow Happy‑melon's example, we shouldn't be making it more difficult for an entity with limited resources to distribute static copies of the encyclopedia to the residents of an isolated African village (for whom most of the topics covered in the Wikipedia namespace are utterly irrelevant). —David Levy 06:02, 7 August 2008 (UTC)

A polite suggestion. Considering that we may soon be botless across a lot of critical pages, would there be any possibility that the proponents of this portal idea could recognize that the timing was most unfortunate, tag this closed for now, let us focus on getting a bot back together, and re-open the portal discussion once we've sorted the fallout from losing the bot operator that kept a lot of pieces running smoothly? I think you may find a different audience if we aren't dealing simultaneously with the problem that this move came about unannounced, right on the heels of a similar situation which affected the bot, and just as a major rewrite of the bot was in the works. Had there been any mention on any of the involved talk pages, or among any of the most involved editors, you would have known this in advance, and the double whammy could have been avoided. Any chance we can just be practical, defer the discussion for a month or so until the air clears, and give the rest of us time to put the bot issue back together again? Yes, David Levy, I did suggest a centralized discussion to get it off of Raul's talk page, but some of the subsequent comments made about bots and bot operators caused a higher toll than I expected. I'm sorry you don't see that as clearly as I do; I know you meant well. SandyGeorgia (Talk) 19:30, 5 August 2008 (UTC)

I totally support deferring any implementation of this proposal based on resolving the above issues first. What's not at all clear to me is if consensus exists to move the pages in principle, based on design considerations. Once the bot considerations are resolved, should the proposal proceed? RichardF (talk) 19:48, 5 August 2008 (UTC)

I see the logic in said postponement, but it's unfortunate that we need to do something analogous to discontinuing red M&M's. —David Levy 20:36, 5 August 2008 (UTC)

1. At the moment, my primary goal is to convey the fact that the proposal's implementation (or non-implementation) has absolutely no bearing on the bot situation. You've conflated the two issues to the extent that some people believe that we intend to break the bots, and while I see the logic in postponing the proposal until things have settled down, I worry that ending the discussion completely would reinforce that false impression.

2. I haven't seen anyone other than you interpret the comments in question as belittlement of bot operators. They really, really aren't. —David Levy 20:36, 5 August 2008 (UTC)

Well, then I will go on record as saying any deferral of this discussion is not a reinforcement of any conclusion, rather a courtesy intended to generate a better and calmer discussion at a later point. The moves may not have broken the bots, but coming right on the heels of another similar action and in the face of planned and needed rewrites, they may have impacted the motivation and will of the bot operator to do the needed upgrades, often aiming at a moving target. In the last similar situation, there were several responses along the lines of, "sorry, submit a bugzilla report" (although in fairness it was eventually resolved satisfactorily), so I hope you understand the hesitancy involved when an unannounced Wiki-wide change affects long-standing processes, and the volunteers who are doing the work are told, sorry, deal with it. Advance notice is always nice. The messages on your talk page show Gimme was concerned when over 200 pages were moved, I'm sure he or someone will be able to sort everything with advance planning, but we do need to sort through things and see what ripples there might be and get another bot operator in place now, or go back to doing closings manually. I've been spending my time sorting how to replace Gimmetrow, who is darn good at what he does. (Look at this Signpost article to see what talk pages looked like back in the olden days of multiple templates, before articlehistory.) I'm convinced no belittlement of bot operators was intended, but I think I have a good sense of what Gimme has dealt with for two years, he never descended to BetaCommandBot levels, and I'm sensitive to the work and how much help it has been on featured content closings, talk page cleanup, and several other processes. When critical elements and people involved in a process are taken by surprise, it's not the best circumstances for making good decisions. Perhaps it was my mistake to have suggested a centralized discussion right away, but Gimmetrow posted his news to my talk page after I made that suggestion, and now I'm just asking for the courtesy of time, knowing that many editors are going into summer break period and we need time to sort the bot issue. No prejudice about the renaming to portals or conflating of the issues is intended, just a matter of allowing for a better focused discussion, unencumbered by the surprises this one generated, and smoother implementation of the ultimate conclusion. And a plea for better communication in the future :-) SandyGeorgia (Talk) 21:54, 5 August 2008 (UTC)

Okay, let's postpone the proposal. I do sincerely appreciate the hard work that bot operators contribute to the project (and have no intention of messing up their efforts), but I can see how the timing is less than ideal. —David Levy 22:30, 5 August 2008 (UTC)

Can David or one of the other proponents of this move respond to my suggestion above about creating new pages, clearly designed from scratch to be portals, instead of moving the existing pages (which I claim serve the primary purpose of being authoritative lists)? If the point of WP:FA is to be an inviting portal to the variety of FAs here, IMO it nearly completely fails. It's simply a list. Per my comments above, I think there needs to be a list, and I actually think keeping this list in the Wikipedia namespace makes sense. I'd further argue that there's no particular need to keep an FA portal complete, unlike an authoritative list. We have over 2000 FAs. Mentioning them all on one portal page seems unlikely to result in an inviting, easily navigated page. -- Rick Block (talk) 22:21, 5 August 2008 (UTC)

I'd be fine with that implementation. —David Levy 22:30, 5 August 2008 (UTC)

I'm willing to work with David Levy, CBDunkerson, Quiddity and anyone else who is interested in designing and implementing a more comprehensive Portal:Featured content presentation. For example, perhaps one way to go would be to expand this existing portal with a set of seven subpages, one for each type of featured content. Conversations on next steps could continue at Portal talk:Featured content. RichardF (talk) 00:17, 6 August 2008 (UTC)

Actually... I went ahead and threw together a quick draft/sample. See Portal:Featured articles. The real question is... given all that is said above about limited resources, would there be anyone to maintain such portals? --CBD 00:30, 6 August 2008 (UTC)

Thanks CBD! A quick glance at the page contents makes me think it's another type of process summary, rather than a reader enticement. If the portals were more content oriented, then they probably could be more automated. Expanding the existing portal a bit, rather than creating seven new portals also would help reduce maintenance. RichardF (talk) 00:44, 6 August 2008 (UTC)

(Replying to Rick above) For the record, Wikipedia:Featured articles is the definitive list of what is and is not a featured article. Articles that are listed there are featured articles; articles that are not listed there are not. I don't make any effort to ensure the accuracy of the thousands of FA talk pages, or the featured article category, etc - that would be virtually impossible given Mediawiki's limitations. I do ensure that that that list of accurate. Pruning is down to be more user friendly is absolutely out of the question. If that's what you want, then I suggest creating a seperate portal (which I see CBD has already done). Raul654 (talk) 03:50, 6 August 2008 (UTC)

I don't think that anyone advocates altering that list. Obviously, it must remain complete. —David Levy 08:51, 6 August 2008 (UTC)

in fact, any page that does not include the entire list defeats the purpose of such a portal. In effect, Portal:Featured content is a special case of Portal:Contents. That's the information that needs to be in a portal. The detailed information of managing the processes can and should stay in project space. RichardF (talk) 14:35, 6 August 2008 (UTC)

Comments

The main argument for moving pages around seems to be "consistency". We all know what Emerson said about "consistency". It's at best a minor benefit, but could easily be worse.

People have different notions about the portal namespace. I, for one, have a difficult time thinking of a list of articles on unrelated subjects (WP:FA) as a portal. Wikipedia:Portal and Wikipedia:Portal guidelines discuss portals in terms of a topic: "Portals are pages intended to serve as "Main Pages" for specific topics or areas" and "portals should be about broad subject areas". The topic of Portal:Cricket is cricket, the subject area of Portal:Germany is Germany. What would be the topic and subject area for something called Portal:Featured articles? Cover stories and cover art?

WP:FA (and WP:FL and WP:FFA and WP:GA and so forth) are not "reader-facing" pages. Their "topic", if that term can be used at all, is a Wikipedia process which internally identifies pages. That an article is so identified is not primarily "reader-facing" - a few significant editors involved with the WP:FA process would happily remove the controversial star and have absolutely no indication of FA status on the article.

Perhaps the problem is that we have too many pages in portal space that belong in wikipedia space. Gimmetrow 04:16, 12 August 2008 (UTC)

By this reasoning, where does Portal:Contents logically belong? Portal:Featured content is simply a special case and subset of it. Where the parent goes, so should go the child. RichardF (talk) 16:04, 13 August 2008 (UTC)

I don't care one way or another about the outcome of this discussion, but RichardF, this page can easily be re-categorized after a move. If the child doesn't fit in at home, it can run away and find a new one. — Twas Now ( talk • contribs • e-mail ) 16:29, 13 August 2008 (UTC)

Well, WP:FA lists articles, so by your reasoning it's a subset of articles and belongs in article space? The non-flip answer is that WP:FA and other other featured processes have been been around for a long time. Any page which wants to claim parent status needs to respect that autonomy. If someone started Wikiproject War about all things war-related, military history would be a subset. Do you think WP:MILHIST would start taking orders from Wikiproject War? Gimmetrow 16:58, 15 August 2008 (UTC)

So, the basis of your argument appears to be that of squatters rights - first come, first served. By this logic, Portal space always will be given the stepchild status, which it obviously has. Portals are intended to introduce and showcase content. In effect you're saying featured content is exempt from being a part of Wikipedia's contents structure because featured articles were written by editors working on the project to create Wikipedia's best articles. ...(Where is the sense in that?)... RichardF (talk) 03:46, 16 August 2008 (UTC)

No, my argument is the WPFA isn't a portal, and it doesn't become a portal because some other page in portal space claims it as a "subpage". Gimmetrow 19:48, 16 August 2008 (UTC)

Agree with the first comment in this subsection by Gimmetrow (talk · contribs). Cirt (talk) 16:24, 16 August 2008 (UTC)

Wikipedia:Good topics

• Wikipedia:Good topics - A proposed process to highlight topics where all articles are of WP:GA quality or higher. A straw poll is taking place at Wikipedia talk:Good topics#Straw poll which will end on August 24. (Discussion can also take place at Wikipedia talk:Good topics) - Cirt (talk) 19:30, 17 August 2008 (UTC)

Wikipedia:Obscure topics

I just wrote this essay (guideline-to-be) a few days ago, hoping to address the Qubit Field Theory issue, since general readers do not need to know this quantum science topic and are not interested in understanding this theory. It is important to quantum scientists, though, and Wikipedia asks editors to write in tones which general audience can understand, but editors in actuality can not give a lot of details in the article while express them clearly in layperson's terms, thus making the article less useful to quantum scientists. So I'm going to let this essay be a guideline to let editors write obscure topics which are unfamiliar to general audience and they do not need to understand but necessary to professional audience (philosophy, historiography, geography, jurisprudence, mathematics, physics, chemistry, biology, earth sciences, social sciences, technology ane engineering in particular) in non-layperson's terms. Of course accesible to both general and professional audience is best, but only accesible to professional audience is not bad, since meeting all the audience's need is impractical in some situations, thus English Wikipedia has thousands of topics whose general and professional editions are separated, e.g. evolution and introduction to evolution). --RekishiEJ (talk) 17:39, 7 August 2008 (UTC)

(ec) How on earth are you going to decide which topics "general readers do not need to know"? That seems a bit insulting to general readers everywhere. Please note that WP:NOT PAPERS, which your essay says to ignore, is policy, not a guideline. Have you seenWikipedia:Make technical articles accessible? That might provide the additional guidance you are seeking. Karanacs (talk) 17:46, 7 August 2008 (UTC)

By common sense and wisdom. In fact, even Jimmy Wales, the encyclopedia lover can not understand what Qubit Field Theory is, and it is unimportant. I just want to solve "obscure science topics" problem, which editors wish to follow WP:NOT PAPERS and Wikipedia:Make technical articles accessible can not fully describe all the facts about them in the "obscure" articles. In my opinion, Wikipedians should only apply these two rules in non-obscure topics, so that the "stub" problem can be fully solved. Nearly 50 percent of English Wikipedia articles are mere stubs, and is heavily criticised both internally and externally, see Criticism of Wikipedia. --RekishiEJ (talk) 19:59, 7 August 2008 (UTC)

Stubs are not just because articles are "obscure topics". This particular part of WP:MTAA should cover the area I think you are trying to address:

For highly specialised topics where it is simply not possible to even give an overview in terms with which a general audience will be familiar, it may be reasonable to assume certain background knowledge. For example, many topics in advanced mathematics fall into this category. However, the technical discussion should be preceded by a discussion aimed at a more general audience, which attempts at least to put the topic in some broader context. "Common sense" is not often a good measure of how to classify articles, as what one person might consider obscure another person thinks is mainstream. As for the article you keep citing, Qubit Field Theory, it doesn't look like anyone has even tried to expand the article beyond what it is now. If no one has tried to present it in a more accessible format, how do you know it can't be done? Karanacs (talk) 20:13, 7 August 2008 (UTC)

The "obscure science topics" problem is not a problem. The "stub problem" is not a problem. The "criticism problem" is not a problem. We edit and structure the encyclopedia according to best practices, not to flinch away from criticism that is not necessarily insightful anyway.

One of our best practices is that if you can make an obscure topic more accessible to a general audience, you should. A lot of technical details can't be explained to a lay audience (such as Wiles' solution to Fermat's Last Theorem), but that doesn't mean you can't explain to general readers what the significance of the topic is to the specialized field (or to the world in general), or what its general implications are. I can understand what Qubit Field Theory is, up to a point, if someone would just explain it to me. We can and should serve both audiences.--Father Goose (talk) 20:16, 7 August 2008 (UTC)

I know that when writing obscure topics in science, we should assume that most readers are professonal in the area but let general readers know the significance in the specialised field . But it is impossible for use to let them know the details of it, so I just wrote the guideline-to-be to let editors deal with this kind of topics. After all, most people do not need to know advanced academic topics, if there's something they should know, it is the significance of a particular field. And as statistical data show, most people come to Wikipedia to consult topics about current events, sex, popular culture and global issues. In conclusion, if we can let both audiences read a topic quite pleasantly and fully understand it is best, if no matter what we do only professional audience can fully understand it, it is not bad, since in this kind of situations the topic is absolutely obscure, in other words, quite unimportant. --RekishiEJ (talk) 23:02, 7 August 2008 (UTC)

There are absolutely some Wikipedians willing to expand Qubit Field Theory, the reason that the article has not been expanded because they do not know how to present the article in layperson's terms and give the article full detail at the same time, see Wikipedia talk:Fame and importance#No. --RekishiEJ (talk) 23:09, 7 August 2008 (UTC)

• Strongest Possible Oppose. I couldn't disagree more with this current proposal. Have you even looked at WP:MTAA? There it says, "Articles in Wikipedia should be accessible to the widest possible audience." If it is possible to open an article up towards a general audience, then it should be done. "After all, most people do not need to know advanced academic topics." Who are you to tell people what people need to know? I for one would love to be able to comprehend Qubit Field Theory (looking at the article, I reckon it wouldn't be too hard for someone with a bit more expertise than me to expand it). "most people come to Wikipedia to consult topics about current events, sex, popular culture and global issues" Therefore we should just get rid of all the information the "proles" don't need to know. Clearly science is unimportant. Have you ever stopped to think that maybe most science articles don't get frequented enough because they are too hard? If we made them easier, people would go there more often. "since in this kind of situations the topic is absolutely obscure, in other words, quite unimportant" Anything to do with Quantum Mechanics really isn't "unimportant". Quantum Mechanics is very very important. Who are you to diss that? Wikipedia's very own policies dictate that if a topic is notable we have an article on it. So unless Qubit field theory gets sent to AfD, I say it's notable, and therefore important. At least as important as anything else on Wikipedia. Finally, ever thought that Wikipedia is an encyclopaedia, so it is designed for the layman, not for the professional. Most professionals will have their own sources for gathering info anyway. That is not a mark against Wikipedia, no, it comes from the fact that Wikipedia is an encyclopaedia.
• Anyway, no offense but Wikipedia doesn't need this essay or guideline, and seriously I hope it fails. Deamon138 (talk) 23:32, 7 August 2008 (UTC)

• I write about a lot of fairly advanced topics (advanced data structures and topics in computational complexity) and ideally, an article should begin with a gentle introduction, but it's completely reasonable to assume some amount of background with the general area, as long as technical terms are linked on their first use and other reasonable measures are taken to help someone get the background they need to understand it, if they don't already have it, such as specifying the context. It doesn't make sense to recapitulate the entire background of the field in every article, but nothing is more frustrating than reading something you can't understand but need to, and having no idea what you need to do to develop your background. Dcoetzee 23:37, 7 August 2008 (UTC)

I noticed that this attempted guideline was brought into existence by this comment by Jimbo Wales over FOUR YEARS AGO:

" 'fame' and 'importance' are not the right words to use, they are merely rough approximations to what we're really interested in, which is verifiability and NPOV. I understand and appreciate where people are coming from on the 'Yes' vote, but feel that they will only get the unanimity necessary in a wiki environment if they rephrase the issue in those terms. Consider an obscure scientific concept, 'Qubit Field Theory' -- 24 hits on google. I'd say that not more than a few thousand people in the world have heard of it, and not more than a few dozen understand it. (I certainly don't.) It is not famous and it is arguably not important, but I think that no one would serious question that it is valid material for an encyclopedia. What is it that makes this encyclopedic? It is that it is information which is verifiable and which can be easily presented in an NPOV fashion. (Though perhaps only as a stub, of course, since it's very complicated and not many people would know how to express it clearly in layperson's terms.)"

Well that was four years ago, so more info will be able to expand on that since then. Moreover, he is no physicist, so he is not likely to know if it can be done better not, since only an expert can comprehend a theory and then write it into layman's terms. Also, the comment does nothing to back up the case for this guideline here. Jimbo is basically saying that it might be hard to find people to write the article in layman's terms, but that isn't a reason to LIMIT FORCIBLY VIA A GUIDELINE articles to non-layman's terms. It is a reason why it is a stub, and may well continue as a stub, but it is not a reason to force it to be a stub, because there is the off chance that an expert will come along that knows how to write it into layman's terms.

To clarify, Jimbo is not saying here that Qubit field theory should be limited to only the technical aspects, only that it is limited to only the technical aspects because of a lack of expertise in writing for the layman. I am sure that if that expertise came along, Jimbo would welcome it. Deamon138 (talk) 23:50, 7 August 2008 (UTC)

Thich Quang Duc oppose I cannot oppose this suggestion any more strongly. Let me quote the project's founder: Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing. This proposal flies in the face of the spirit of Wikipedia. Mr. IP 《Defender of Open Editing》 18:47, 8 August 2008 (UTC)

Very Strongly Oppose per everyone above. Not only that, but I recommend that the essay be deleted. It's borderline nonsense. --Pwnage8 (talk) 19:10, 8 August 2008 (UTC)

Strongest possible expose. Everything is obscure to somebody. This isn't something you can quantify. We aren't here to present only stuff that someone who failed out of high school can understand. Dumbing Wikipedia down only results in it being useless. Celarnor ^{Talk to me} 19:25, 8 August 2008 (UTC)

Who's to say that someone who failed out of high school wouldn't understand Wikipedia? Bottom line: everyone has different interests, and what is obscure to one person would be central to the mind of another. Wikipedia treats everything the same. --Pwnage8 (talk) 20:20, 8 August 2008 (UTC)

For the reasons stated previously by others, I also oppose this (not to mention that I am currently proposing that more or less the opposite of what is proposed here be done). It Is Me Here (talk) 15:51, 9 August 2008 (UTC)

• Oppose This seems to be yet another attempt by mathematician/theoretical physicists to assert that Wikipedia's policies and guidelines don't apply to them. The result of this arrogance is that articles on such topics are poor, lacking inline citations, good style and general comprehensibility. I feel sure that we can do better. As for Qubit Field Theory, the problem there seems to be that it is borderline notable even within the scientific community and so there are few good sources. Perhaps what we need is the scientific equivalent of Wikipedia is not the news to exclude leading edge speculation which is still too new to be covered in an encyclopedic manner. Colonel Warden (talk) 10:08, 10 August 2008 (UTC)

• Comment Well though different persons view a topic's importance differently, Qubit Field Theory IS an obscure topic since it is not mentioned in university-level general physics textbooks, general-oriented science books and television programs. So I infer that most people do not need to understand it, but it may be important to quantum scientists, so I say that as a certain topic is not mentioned in university-level textbooks, general-oriented books and television programs, and it's not about daily life and is closely related to mathematics, natural sciences, technology, engineering or programming (humanities and social sciences are much easier to learn than those fields), we can apply this guideline-to-be to solve "stub" problems in articles about obscure topics. --RekishiEJ (talk) 22:23, 10 August 2008 (UTC)

• Comment Also, not only general readers read Wikipedia articles, many professional readers do the same thing as well. For instance, my web programming and software engineering teacher often read articles about web application or the like on Wikipedia, so professionals also have high desire to read the pages. --RekishiEJ (talk) 22:44, 10 August 2008 (UTC)

• "Also, not only general readers read Wikipedia articles, many professional readers do the same thing as well." If it ain't broke, don't fix it. If they already come here for info, they don't need it to be changed then do they.

• "we can apply this guideline-to-be to solve "stub" problems in articles about obscure topics." This guideline solves the problem of stubs about obscure topics by forcing them to be stubs? That doesn't make any sense. Unless you are saying we make the articles intentionally complicated? If so, I present you with WP:NOT PAPERS. Qubit Field Theory may be obscure, but it is important to whoever wants to read it, quantum physicist or not, and if it is notable (which it is) then I will protect the article for the interests of those that may want to read it. Deamon138 (talk) 01:07, 11 August 2008 (UTC)

• • Really? Most general readers DO NOT READ advanced science topics at all. And I proposed the guideline just to solve the Qubit Field Theory problem. Finally we need to add some exceptions in WP:NOT PAPERS. Not every topic can be both clearlly and in great detail written in layperson's terms. This situation should apply WP:IAR, though policies usually do not allow exceptions. (Sigh) Wikipedia is going to be a bureaucracy strictly enforcing all the policies without considering diffrent situations. All the policies and notability guidelines are like laws in the U.S.A.. Policies are not laws, they just simply describe what Wikipedia should be and give it to the right direction, so sometimes we don't need to follow ALL the statements in them. Guidelines only supplement policies and guide the editors how to edit in different situations. --RekishiEJ (talk) 12:55, 11 August 2008 (UTC) typo error correction 13:13, 11 August 2008 (UTC)

"Really? Most general readers DO NOT READ advanced science topics at all." How can you possibly know that? Do you know every general reader? Besides, even if that is true, the statement indicates that SOME general readers read advanced science topics. Also, why might a lot of general readers not read science articles? Maybe it is because they are overly complicated as is. This idea of yours will just put the general readers who do read science articles off, and put those general readers who would like to read them but can't at the moment because of their complexity, further off too. It would have a negative effect on Wikipedia. Regardless, I believe that statement to be most likely false. Deamon138 (talk) 00:30, 12 August 2008 (UTC)

"Finally we need to add some exceptions in WP:NOT PAPERS. Not every topic can be both clearlly and in great detail written in layperson's terms." WP:NOT PAPERS doesn't say that it has to be written into layperson's terms. It says "A Wikipedia article should not be presented on the assumption that the reader is well-versed in the topic's field", which is the complete antithesis of your proposal. Besides, again how would you know if a topic can be written in layperson's terms anyway? Who are you to say what should and should not be written in the most understandable way possible? An article will be created in the most intelligible way an editor can make it. Then more editors will come along over time and make it more intelligible (hopefully). Thus it can be seen that with enough time, and the right editors, any article can be made intelligible, via this almost organic process a la Darwinian evolution (only with Intelligent designers this time). An article should not be forced to be made unintelligible, and an article should not be considered a lost cause.

"This situation should apply WP:IAR, though policies usually do not allow exceptions." The way I understand WP:IAR is that you can't just go "I want to do something so I shall ignore all rules". You have to provide good reason(s) for ignoring a rule. You have provided none.

"Wikipedia is going to be a bureaucracy strictly enforcing all the policies without considering different situations." Better it be a bureaucracy than an oligarchy! Besides, we actually have something that says the opposite: WP:NOTBUREAUCRACY. We do consider the different situations, but there is no situation where your proposal would make the encyclopaedia better. It is not like there is just one tiny policy (note: both the letter and the spirit of them) against this proposal, but many. That is not rigidly following the rules. That is rigidly getting shot of a bad idea. I also find it ironic that you complain this is a bureaucracy when you yourself are proposing a new guideline!

"Policies are not laws" Well no, most aren't. But there is at least one policy that is a real law: WP:LIBEL. Plus, if Wikipedia itself has any laws, then it must be WP:CONSENSUS? It is effectively a law of Wikipedia, since if something is done that doesn't follow consensus, it is generally a bad thing. Deamon138 (talk) 00:30, 12 August 2008 (UTC)

Strongly oppose. I also think that Introduction to evolution should be deleted, redirected to Evolution. A properly written lead paragraph (a rare find indeed) provides the summary you are looking for. Emmanuelm (talk) 14:16, 15 August 2008 (UTC)

• Comment I've modified the guideline-to-be to address the issues you mentioned. The final goal of it is to solve the accesibility issues in mathematical and natural science articles. Maybe I should later expand and rename it into "Writing about math or natural sciences" to replace WP:MTAA. In principle while writing about this kind of articles we should first determine the importance of an article (can do so by consulting college-level general textbooks, such as general chemistry college textbooks), then try to suit both general and professional readers' needs in crucial articles. If no matter how we try both needs can not be satisfied, then we should separate the article into ... and introduction to ... (actually there are AfD debates in introduction to ...... articles, they finally are kept, though). If the topic is not crucial (especially when is is obscure), then we should still strive to fit both. In situations both can not be satisfied at the same time, we should only meet professional needs. After all, though Wikipedia does try its best to make each article accesible to general educated persons, it is quite impractical in many situations when the article is about math or natural sciences and it is so unimportant and advanced that general readers do not need to know and have no ability to know, such as Qubit Field Theory (I've mentioned it above). --RekishiEJ (talk) 04:20, 18 August 2008 (UTC)

• But why force an article to say at a highly technical level like you want to do with this proposal? That doesn't make any sense. Either it is possible to make an article more accessible (so it shouldn't be forced to be inaccessible if that is possible) or it isn't possible, in which case, no guideline is needed to force it to stay at an inaccessible level, since it will stay inaccessible, guideline or not! There is no good reason to limited forcibly the accessibility of an article! And I oppose any attempt to replace WP:MTAA with this, since this is effectively the opposite of WP:MTAA. Deamon138 (talk) 23:42, 18 August 2008 (UTC)

creating a new guideline...?

I'm trying to see about creating a new guideline here, but most of what I can find relating to establishing pages with Wikipedia backed umph deal with the creation of policies. I'm not looking to do that becuase the materail in question is unsuited to a policy backing, but I can't seem to find any simple steps dealing exclusively with guidelines. Can someone tell me what to do to get the ball rolling on this? The page I'm looking to establish as a guideline is Wikipedia:Coordinators, which began as an essay when only large projects were instituting coordinator departments, but more and more I see this term cropping up among Wikiprojects, enough so that I feel making this a guideline is now certifiably nessicary. TomStar81 (Talk) 08:17, 17 August 2008 (UTC)

Have you looked at WP:EIW#Policy, which covers both policies and guidelines at Wikipedia? -- John Broughton (♫♫) 23:11, 17 August 2008 (UTC)

Basically start discussion on the talk page saying that you want to make the essay a guideline then add the discussion to template:cent to get wide coverage of your proposal. - Icewedge (talk) 02:06, 18 August 2008 (UTC)

Thanks. That make things sooo much easier. TomStar81 (Talk) 09:32, 18 August 2008 (UTC)

Automatic Home Page Search Box feature

How about making the user's cursor automatically populate the home page search box so he/she can begin his/her search immediately after the home page loads?

This would be a tremendous help for me as I often do search after search for an hour or more at a time.

This has been proposed, and rejected, so many times that it has its own FAQ question at the technical village pump. Have a look at Wikipedia:Village pump (technical)/FAQ. Happy‑melon 19:56, 15 August 2008 (UTC)

However, I think it is available as a gadget... Soxπed93^(blag) 03:12, 20 August 2008 (UTC)

Edit throttling

Would it be possible to prevent editors (at least anons and new registered ones) from making a large amount of successive edits, such as happened here: [3][4][5][6]? StaticGull  Talk  15:24, 18 August 2008 (UTC)

That's one of the many things the proposed Abuse filter could deal with. Algebraist 15:31, 18 August 2008 (UTC)

Let's hope it gets passed, then :-). StaticGull  Talk  12:02, 19 August 2008 (UTC)

I want to know the age of some fiber filled plaster board

Resolved

 – Redirected user to WP:RD SoWhy 14:09, 22 August 2008 (UTC)

There is a house in country victoria (Australia)... One part is lined with large ,i think prefabricated sheets of plaster board. These are predominantly fiber, possibly coconut, with plaster all through the fiber mat and creating a paintable plastered internal suface. I hope somone knows when they might date from. —Preceding unsigned comment added by Merelyn saunders (talk • contribs)

This is not an appropriate place for such questions. You might want to try and ask at the reference desk. SoWhy 13:56, 22 August 2008 (UTC)

Please someone delete this, it has nothing to do with this page --Itemirus^{Talk Page} 14:01, 22 August 2008 (UTC)-

I don't think that is necessary. I have copied the discussion to the user's talk page and we can leave this here, if the user reads here first. If noone answers in this section again, the bot will archive it soon anyway. SoWhy 14:09, 22 August 2008 (UTC)

"Thumb" as implicit parameter for image display?

Are there any issues (other than developer time) if the image syntax were to be changed so that the parameter "thumb" were to be implicit? (Currently, editors can add a "right" parameter to image display specifications, but the default - if alignment is not specified - is already "right", so this parameter is unneeded. I have in mind doing the same thing for the "thumb" parameter.)

The advantage seems fairly straightforward: simplification. With this change, the normal image syntax would simply be [[Image:ImageName.ext|Words for the caption]], which is easier for new editors to understand. (Use that syntax today, and the caption won't display (as well as a huge image being displayed); non-intuitive.) There would have to be an "unthumb" parameter, of course, for those relatively rare cases where more than a thumbnail image should be shown, but it seems to me that such cases would almost always involve experienced editors, who would (at minimum) know where to look to find instructions to override an implicit "thumb" parameter. -- John Broughton (♫♫) 16:23, 22 August 2008 (UTC)

It would be technicaly posible yes. Would cause issues with infoxes mind.Geni 20:31, 22 August 2008 (UTC)

There are also a number of templates that group images and place them within a common frame. Examples may be found in Category:Graphic templates. --—— Gadget850 (Ed) ^talk - 21:00, 22 August 2008 (UTC)

could be wroked around through a unthumb. The idea looks good but figureing out what that level of syntax change would cause is kinda tricky.Geni 21:09, 22 August 2008 (UTC)

The problem is working out which pages need an update. For plain inline images it would be fairly easy, but for things like infoboxes, where the image syntax might be cobbled together with parser functions and template parameters, it would be more difficult. Mr.Z-man 21:54, 22 August 2008 (UTC)

I like the idea but I do not think it's doable. As pointed out above, it would require to change millions of pages...I would rather suggest changing the way the way the button in the editing toolbar works to insert [[Image:Example.jpg|thumb]] instead of [[Image:Example.jpg]]. SoWhy 22:01, 22 August 2008 (UTC)

It would definitely require changes to many many pages as SoWhy says. Incidentally, I just edited an image in an article and it didn't have its location specified, but defaulted to the left until I added the "right" parameter. That seems really odd to me. Deamon138 (talk) 23:30, 22 August 2008 (UTC)

Very informative. Regarding the last comment, Wikipedia:Extended image syntax says, regarding location: 'right', 'left', 'center' or 'none'. Determines placement of the image on the page. Defaults to 'right'.

I know it says that, that was why I thought it strange that what I was editing defaulted to the left. Deamon138 (talk) 01:54, 23 August 2008 (UTC)

And on what page could I post a suggested change to the edit toolbar button, so that it inserts [[Image:Example.jpg|thumb|Caption]]? -- John Broughton (♫♫) 01:09, 23 August 2008 (UTC)

You can try posing your question on the MediaWiki talk page for the edit toolbar, located here. Sswonk (talk) 02:10, 23 August 2008 (UTC)

I think a better solution than defaulting to 'thumb', though a far more complex one, would be to auto-thumb conditionally based on dimensions of the image being added. This would mean that images that have a pixel width greater than some threshold would auto-thumb, which could be suppressed using the 'unthumb' parameter. There is a lot more that could be proposed and speculated here, but I will leave this potential alternate approach bare so that the concept can be discussed rather than the implementation. --User:Ceyockey (talk to me) 02:27, 23 August 2008 (UTC)

Proposal to move "Village pump"

Please see Wikipedia talk:Village pump#Move Proposal

Old topic. Sign to archive. Garion96 (talk) 14:55, 23 August 2008 (UTC)

Proposal concerning date-autoformatting

WP:MOSNUM has moved from mandatory recommendation to slightly on the negative side of optional over the past year. Debate has been particularly enthusiastic over the past month. There's currently a proposal to add "[Date autoformatting] should not generally be used unless there is a particular reason to do so." There's a lot of background to this proposal, so please ask there if you need to be linked to it. Tony (talk) 14:01, 18 August 2008 (UTC)

Just to let people know that the change has been made here at MOSNUM in accordance with consensus here. Tony (talk) 13:29, 23 August 2008 (UTC)

expansion of numerical ordinal searches

I think that when searching WP, values such as "1st", "2nd", "3rd", etc. should be expanded to "First", "Second", "Third". For example, I believe the query "14th Knesset" should be treated as "Fourteenth Knesset". Instead, the page 14th Knesset does not exist. I understand that it would be possible simply to redirect all of the pages like this, but I think that is an inferior solution. One problem I see with this proposal is: are there any instances where the numerical and the spelled out queries should lead to different pages? I have not been able to think of any, but one solution to this potential problem is to have the search engine first try to find, say, the "14th Knesset" page, and if it is successful lead the user there; if it is unsuccessful, it should automatically try to redirect the user to "Fourteenth Knesset", if that page exists. Many people might think that if a searcher tries "2nd" and is unsuccessful, instead of being discouraged, she would try the query again with "second". However, besides being extra time, I think that some users would not think to try the other way.PGScooter (talk) 04:47, 23 August 2008 (UTC)

While the manual of style may specify one behavior over the other, there are conceivably times (such as names of movies and novels containing "1st") where this would disallow the existence of the page at its proper place. I don't think the minimal benefits this gives are worth these problems, which can already be solved by redirects, which are trivial to produce at page creation. Celarnor ^{Talk to me} 04:55, 23 August 2008 (UTC)

Hi Celarnor. Allow me to dissect your points and respond to them individually:

• "there are conceivably times (such as names of movies and novels containing "1st") where this would disallow the existence of the page at its proper place."

If I understand you correctly, you are referring to the problem that I posed above with my proposal. If this is the case, please see my "solution" to this problem. If it is not, please clarify.

• "minimal benefits [of this proposal]"

I agree that the benefits would not be massive. However, I think that the proposal is inline with Wikipedia's philosophy of making every effort to reach out to everyone. And, although it may sound silly, there are types of people who think in terms of numerical ordinal numbers.

• "redirects, which are trivial to produce at page creation"

I agree that in many cases you are correct, especially when there are not a lot of redirects to do (for example, First World War and Second World War). However, when there are many redirects to make (for example, 1st through the 43rd President of the United States), the extra labor does seem considerable. And, not only is the labor important, but also we are assuming that people will recognize that they need to make those extra redirects in the first place. I have not found this recognition widespread, except for the most popular articles.PGScooter (talk) 08:21, 23 August 2008 (UTC)

The cases where you have many elements of a sequence (i.e, presidents) sound like a good idea for a bot. It wouldn't be that difficult to code, either, not much else other than JWBF declarations and a for loop for whatever pages you need them for.

For bonus points, you could grab a static HTML dump and grope through that for the page names you would need to create redirects for, then dump them all to an array and work on them element by element; for further epic bonus points, you could have it watch the new page creation log and operate on those after its initial run.

There are reasons why the search mechanisms on en.wiki aren't fully implemented to their full intelligence and are limited to their current system of stagnant, deterministic raw in-text searching; CPU cycles being one of them. I don't really think modifying the search engine to add cycles to check its results whenever certain strings are present, enter conditional steps, mutate them, and repeat the search and step out as you propose is a particularly good idea in the "costs vs benefit" category. Celarnor ^{Talk to me} 08:49, 23 August 2008 (UTC)

Celarnor- thank you for the replies and for the explanations! I am pretty ignorant as far as how the scripts and bots work, but I will do some research on this. Although I do not know how the search mechanisms work, it seems that you do know a good amount so I trust your judgment as far as the costs and benefits. Thanks. PGScooter (talk) 08:58, 23 August 2008 (UTC)

Well, don't take my word for it, I'm sure other people will reply sooner or later. I'm not a dev, but I do know Mediawiki's innards fairly well, and while what you propose wouldn't be difficult to implement, when you're talking about adding steps like that to something that can't really be cached like content can, you're probably going to see a pretty noticeable performance hit. If the particular "some stuff may need the number expressed the other way" caveat, this wouldn't be as difficult, as you'd only have to mutate the string once and then be done with it. Celarnor ^{Talk to me} 09:13, 23 August 2008 (UTC)

I don't think this is a bad idea at all. It would be useful, especially to those like me who like to type as little as possible when searching. There might be the odd problem in relation to disambiguating "ordinal" pages that already exist as something else, but someone well versed in bot coding shouldn't have too much trouble. Deamon138 (talk) 16:34, 23 August 2008 (UTC)

I understand that it would be possible simply to redirect all of the pages like this, but I think that is an inferior solution. I fail to see why MediaWiki software would be able, somehow, to figure out any exceptions (that seems to be the "inferior" part), while a bot (which would create redirect pages) wouldn't be able to. It is in fact far simpler just to have a bot add redirects, as needed, than to expect developers, say, to add yet another special case to the search engine. -- John Broughton (♫♫) 21:48, 23 August 2008 (UTC)

Hi John. Either you or I misinterpreted the phrase that I quoted: "redirects, which are trivial to produce at page creation". You interpret it as referring to bots creating the redirection pages, whereas I understood it to mean people manually making the redirection pages (it is this latter interpretation that I think is an inferior solution). I agree that a bot seems like an excellent way to go. PGScooter (talk) 22:24, 23 August 2008 (UTC)

sidebar proposal

proposal to add to the sidebar here: MediaWiki_talk:Sidebar#add_to_navigation 86.44.22.174 (talk) 22:26, 23 August 2008 (UTC)

Wikipedia:FlaggedRevs_fact_sheet#Suggested_configuration

Discussion has begun on ways of implementing 'Flagged Revisions' on this wiki (the english wikipedia!) - though I have concerns about how this might effect project dynamics / entropy in the long term.... it's certainly time for us to consider something, I'd say..... take a look! Privatemusings (talk) 01:26, 26 August 2008 (UTC)

WP:DeSysop

what it says on the tin, really.... a proposal that if a clear community consensus is present for the removal of a user's 'admin' flag, a bureaucrat is authorised to instruct a steward to make the switch... Privatemusings (talk) 01:51, 26 August 2008 (UTC)and having suggested several impossible things, I'm off for breakfast :-)

Clearing Category:Wikipedia administrator hopefuls with a bot?

This discussion was moved to Wikipedia talk:List of administrator hopefuls. SoWhy 20:09, 26 August 2008 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hey, within a discussion at WT:RFA Balloonman pointed out quite correctly that Category:Wikipedia administrator hopefuls is quite useless to allow people to maybe find new candidates to nominate for adminship because it is completely bloated. So I wondered if it was possible to just set up a bot to remove the {{User wikipedia/Administrator someday}}-template (and it's clones) from the user-pages of all users who have not edited for 3-6 months to weed out the inactive. But I have no idea on how to do so or if that could be done just like that, it is removing stuff from other people's user pages after all...what do you think? SoWhy ^{review me!} 18:27, 15 August 2008 (UTC)

Personally, I think this is a great idea, so long as we can write the bot to leave a message on the user's talk page letting them know that the box has been removed.---Balloonman ^PoppaBalloon 09:16, 16 August 2008 (UTC)

Agree with Balloonman (talk · contribs) - good idea SoWhy (talk · contribs). Cirt (talk) 16:18, 16 August 2008 (UTC)

I also agree with Balloonman. Inactive users aren't likely to become admins anyways. -- Imperator3733 (talk) 20:20, 16 August 2008 (UTC)

I guess I'll be the one to stand and object to the idea then. As far as policy is concerned, if a user wants to have a userbox that says they want to be an admin someday, it is their choice to have it on their page. Policy specifically allows any user to have anything (within reason) on their userpages, and they do not need the communities permission to do so. Forced removal of the userbox (or anything within reason from a userpage) would, in my opinion as an administrator, constitute vandalism. I don't care if the BAG approves a bot like this (and I don't think they will), I will block it for vandalism. -Royalguard11(T) 00:31, 20 August 2008 (UTC)

What if the inactivity period were expanded, say instead of 3 months perhaps 6 months or even 1 year? Cirt (talk) 00:43, 20 August 2008 (UTC)

Or it simply added a parameter to the userbox suppressing the category? –xeno (talk) 00:46, 20 August 2008 (UTC)

That is an even better idea. Cirt (talk) 01:06, 20 August 2008 (UTC)

Yeah, as I was reading Royalguard's comment, I thought the same thing, so it must be a good idea. :D WODUP 01:11, 20 August 2008 (UTC)

While users have great latitude on what they can out on their user pages, there are limits and community consensus trumps that latitude. It does not qualify as vandalism and if you were to unilaterally block such a bot that would be an abuse of your admin privileges. Blocking is not for implementing your own personal opinions.

That said, is your concern with only removing the user box? Would you be satisfied if the userbox was left, but they were still removed from the category? -- JLaTondre (talk) 01:10, 20 August 2008 (UTC)

But blocking can be used if a violation of policy has happened, which it would in my opinion. Users are allowed to have whatever they want on their userpage without having to be vetted by the community. One user can't just say "you can't have that on your page" and take it off. So yes, my concern is with that material on the page, the userbox. If you want to remove the category from the userbox, that would be fine.

I would disagree with selective categorizing per user. It is not the communities job to judge whether a user is "ready" for some category. If they want to be listed in a category, they are allowed to. To not let them would be elitist and would really be against the spirit of Wikipedia. Wikipedia is not some University with clubs and frats where certain users can say whether one user can be part of one or not. Everything steams from the principle that "Everyone can edit" and from being completely open about everything. There is no cabal that decides who is allowed to move up the Wiki ladder. Users are not ranked or judged good enough.

If some user wants to put something on their userpage and then leave and it doesn't violate policy, there's nothing we can do about it. We cannot just say "they're not coming back so who cares". Just look at usurp requirements. We can't just change old userpages just because they don't fit in our schemes. Some users will probably never be admins, but just like the idea of the userbox just like kids like the idea of being a policeman or firefighter when they grow up. But to say to them before they even think of ever applying to become an admin that they've "taken too much time"? It's elitist, and unwikilike. -Royalguard11(T) 17:52, 20 August 2008 (UTC)

There's nothing elitist about uncategorizing an inactive user from that category. The bot will leave them a message letting them know and if/when they come back, they can clear the paramater. Those individuals will still be "findable" via "whatlinkshere", if someone decides they want to nominate an inactive user for adminship. We're not ranking them or judging them not good enough - we're just making a category a little easier to traipse through looking for possible (and active) admin candidates. Heck, if it would alleviate your concern, we can create a subcategory Category:Wikipedia administrator hopefuls who are inactive. –xeno (talk) 17:56, 20 August 2008 (UTC)

Xeno is correct. The category's purpose is not to have a list of people who want the mob but primarily for other users to find suitable candidates to nominate. There is no elitism in that because it does only judge by the fact that those users are not active. Anyone can become active and can put that userbox back. So, yes, there is not a snowball's chance in hell that a user who has not edited for months will ever pass RfA. That is the reality. If it makes you happy, we could create a subcategory - but I'd rather call it Category:Wikipedia administrator hopefuls who are active. So that the original purpose of the category is served - being able to find suitable candidates. SoWhy 18:16, 20 August 2008 (UTC)

In theory the main cat would be the active people and the subcat the inactive ones. –xeno (talk) 19:57, 20 August 2008 (UTC)

As an admin, you really should be more familiar with WP:VAND and WP:BP then you appear to be. There is nothing in either that would allow you to make such a block if there is consensus for this task. Admins are not allowed to use the block button to implement unilateral decisions. Stick to making a rationale argument as to why this is a bad idea. Stating that you don't care about consensus and will block based upon your opinion alone is not acceptable. You are quite correct that there is not a cabal so don't act like you are part of one. -- JLaTondre (talk) 19:50, 20 August 2008 (UTC)

Removal of material would be vandalism. If someone came and deleted a userbox off my page then I would rollback it and warn them for vandalism. There does not appear to be "consensus" for the task either (we have like <10 users here in favour, hardly consensus for such a task). I'm not really sure when user categories were ever useful. They were on all userboxes to match the userbox with a category, that was it (then we stopped doing that because it was stupid). The category was made to match the userbox, not for the purpose to helping to find future admins. You can look yourselves, the category was made to match the userbox, that's it. I must say that if we have resorted to trying to find new admins through a userbox category, then RFA must indeed be more broken then I thought (it was always a bit of a dog and pony show anyways). -Royalguard11(T) 23:20, 20 August 2008 (UTC)

If we take SoWhy's suggestion and break it off into Category:Wikipedia administrator hopefuls who are active, then we won't be making any changes to user's who cannot respond to their messages and have set their userpage the way they like it. That way they can stay in the category. Depending on the distribution, it may be softer on the number of edits. –xeno (talk) 23:37, 20 August 2008 (UTC)

Removal of material is not inherently vandalism. If you think it is, then you really do need to reread the first line of WP:VAND. I am neither arguing for or against this proposal. I am not saying that there is consensus for this task. What I am saying is that your immediate threat to block was inappropriate. You should have made your objection known and had it discussed without immediately jumping to a block threat. This page is about proposing new ideas, discussing the pros and cons, and to determine if the there is consensus or not. It is not for a single editor to attempt to trump discussion by fiat, especially not if it's an admin trying to do that by threatening a block that has no basis in policy. The other participants have been willing to discuss and propose suggestions to address your concerns. You would have gotten the same response even if you hadn't threatened to block. People who see cabals often do so because they see admins trying to dictate their opinion. If you truly believe there should not be cabals, then don't act like that. -- JLaTondre (talk) 01:45, 21 August 2008 (UTC)

Here here. And just because you block the bot, that doesn't stop another admin undoing your block, and then you can either wheel war or discuss the issue. Your threat of a block should be removed from the table because it has no bearing on the debate. Hiding T 13:40, 21 August 2008 (UTC)

The idea was more to create discussion about this. I admit, my threat to block was a bit over the top and I rescind it. -Royalguard11(T) 18:19, 21 August 2008 (UTC)

Good on you! Hiding T 22:30, 21 August 2008 (UTC)

• Now all the bot has to do is add |nocat to the userbox ({{User wikipedia/Administrator someday|nocat}}) and the category will be suppressed. This is the necessary modification for any clones of this userbox that include the category. –xeno (talk) 01:22, 20 August 2008 (UTC)
  • Thanks Xenocidic (talk · contribs) for taking the initiative to make that change. Cirt (talk) 02:35, 20 August 2008 (UTC)

Agreeing with JLT that this would not constitute vandalism but cleanup but I think, for the sake of avoiding arguments, that xeno's way will be more effective. The bot'd still have to leave a message at the user's talk page and explain the change though.

I think Royalguard will not object to this way as it leaves the userbox on the page and just delists it from the Category so the Category is more useful. So I decided to be bold and added Xeno's switch to the remaining clones (as far as I found them). SoWhy 09:07, 20 August 2008 (UTC)

setting those who have edited within 6 months as "active" to add them to a sub-subcategory

if anyone can give me a list of people in the category who have edited within 6 months (I'm just not sure how to parse that) I can set the parameter to "active" which will put them into the subcategory Category:Wikipedia administrator hopefuls who are active, if this is an acceptable solution to Royalguard's concern. –xeno (talk) 00:37, 21 August 2008 (UTC)

Easy enough to do. It's simply the opposite of what the bot would have done (instead of checking if greater than 90, check if less than 90). I can generate the list and drop it on your talk page if you would like. However, that will only solve the original concern for the short term unless the subcategory is actively maintained (both in adding editors who don't use the parameter, but are active and in removing editors who stop being active). -- JLaTondre (talk) 01:45, 21 August 2008 (UTC)

Shouldn't be a huge problem to parse the lists everyone once in a while, right? –xeno (talk) 02:33, 21 August 2008 (UTC)

Feel free to past the list at User:Xenocidic/sandbox and let me know when it's there. –xeno (talk) 04:03, 21 August 2008 (UTC)

I'd rather the admin hopefuls category only contain active users. I don't want to categorize the inactive users in the main category and have a second, more awkward-sounding category for the group that this category is meant to categorize. I thought about agreeing to a separate category for inactive admin hopefuls, but that category would not be useful. Why would anybody want to find someone who wants to be an admin but who doesn't have a chance at passing an RfA? Let's just remove the category from those who are inactive. WODUP 03:03, 21 August 2008 (UTC)

I believe Royal still has an issue with that. –xeno (talk) 04:03, 21 August 2008 (UTC)

I'm sorry that xe has an issue with that, but I think that this is the best solution. If we have cat:active admin hopefuls or similar and all of the inactive users are in cat:admin hopefuls, cat:admin hopefuls would be a useless category and would be deleted. There is no reason to categorize people who wanted to be admins when they were active, but who are no longer active. I think that it's important to remember that the purpose of user categories is to aid in facilitating coordination and collaboration between users for the improvement and development of the encyclopedia. Categorizing inactive users does not help. WODUP 04:20, 21 August 2008 (UTC)

Simply modifying the category should not be a problem. If it is, we need to delete WP:UCFD too. How is removing a category from all user pages fine while removing a category from inactive user's pages vandalism? And then modifying a category on active user's pages is fine? This is just silly, just add the |nocat parameter to inactive user's pages. Mr.Z-man 04:37, 21 August 2008 (UTC)

Personally, I'm not sure that removing it subjectively from userpages (active vs. non-active) is going to not be disruptive.

Based on the discussion above, I'm going to nominate the category for discussion at WP:UCFD. - jc37 10:21, 21 August 2008 (UTC)

Ok, nominated. - jc37 13:39, 21 August 2008 (UTC)

My objection is that we are unfairly ranking members of the community. Removing the category is just unbiasedly deleting it, while giving certain users different categories is subjectively ranking them. Besides the different user rights levels, users are not ranked according to some standard. -Royalguard11(T) 18:25, 21 August 2008 (UTC)

no futzing with categories or people's userpages - just generate a list from it

• Can a bot add every person in the category to a list along with the date the person last edited. That way everyone gets to have their cake and eat it. The userbox is probably more intuitive than adding yourself to a list, and if the bot patrols once a week the list is maintained. Thios idea is so good I must be missing something. Hiding T 11:37, 21 August 2008 (UTC)

That would be the same thing but rather messy. I think the list should, if done, be in sections like "People who has edited this week", "...this month", "...the last 90 days" and within these sections alphabetical, but with the last edit time I guess. I think that would be a easy modification to make and the list could be added to the Category as a subpage, couldn't it? SoWhy 11:50, 21 August 2008 (UTC)

Yes, using the main category to create a list that is routinely updated would be easy. It's actually easier from a bot perspective than the original suggestion as only one page needs to be edited. Multiple sections is fine also. Including it in the category makes sense. -- JLaTondre (talk) 12:00, 21 August 2008 (UTC)

Good to know. Let's see if Royalguard is happy with that :-) SoWhy 12:24, 21 August 2008 (UTC)

That would probably work without having to futz around with people's userpages or categories. Make it sortable by last edit date. –xeno (talk) 12:30, 21 August 2008 (UTC)

I have code lying around that can do nearly all of this - currently used to update WP:LA. In particular, the bit that maintains Wikipedia:List of administrators/Inactive would be essentially identical to what is being talked about here. -- Rick Block (talk) 14:27, 21 August 2008 (UTC)

In the words of a great man....make it so! –xeno (talk) 16:52, 21 August 2008 (UTC)

Xeno is right. It would save JLaTondre any hassle with bot requests as you already have a Bot running and just need another task added to it and it can be done within minutes. We can have a list of administrator hopefuls who looks the same as WP:LA and the userbox can serve a purpose again. Great idea! SoWhy 17:09, 21 August 2008 (UTC)

Works for me. Just a list of who's in a category by last edit is a fair list. People can interpret from there instead of just by what category they're in. -Royalguard11(T) 18:31, 21 August 2008 (UTC)

Rick Block (talk · contribs) has now created an initial (partial) version at Wikipedia:List of administrator hopefuls. I have already provided some feedback but I think the others here should be able to do so as well. I think he did great work, what do you think? :-) SoWhy 14:30, 25 August 2008 (UTC)

Alright. It's not what I expected, I thought that it would be a list of all users in the category sortable by last edit date, but a list of category members who have made 30 edits in the previous three months that's sortable by first edit date is okay, too. It works. WODUP 00:18, 26 August 2008 (UTC)

That's why I posted it here, so Rick can get input. I think he will add a list of all category members as another section as well :-) SoWhy 09:33, 26 August 2008 (UTC)

The remaining members of the category will be added, with "last edit" date. The point of using "first edit" date for the "active" editors is that it shows how long they've been around (although not necessarily active for the whole time) and won't change frequently (which permits a significant performance optimization as well - the tool doesn't have to check contribs of these users unless the previously collected data is not enough to show they're active). For less active editors, the last edit date will show how long it's been since they edited (which, if they've left project, won't change ever again). -- Rick Block (talk) 14:50, 26 August 2008 (UTC)

Hmm...is there a way to ignore users who are admins by now but still have the UBX somewhere on their pages? Alternatively, could the bot do such a check and leave those users a message to remove the UBX? I noticed it with WBOSITG for example... SoWhy 15:40, 26 August 2008 (UTC)

Well, it's just code. Ignoring or indicating admins would be fairly easy. Leaving a message less easy. I'll put it on the to do list. Perhaps it's time to move this discussion to Wikipedia talk:List of administrator hopefuls? -- Rick Block (talk) 16:08, 26 August 2008 (UTC)

Good point. I went ahead, behaved boldly and moved the discussion there and archived this discussion here. SoWhy 20:09, 26 August 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I have found a phrase that defines Wikipedia...

Whilst browsing WikiQuotes, in the Irish section I found a humourous quote summing up Wikipedia:

= Knowledge is like manure, it's only good when spread. =

Meh. I just thought I would share it with you guys.

Lol! To be honest, some articles do look like public toilets, with all the vandalism they receive...

PS: Using equal signs as you have can cause problems; we normally use these for headings. The strange thing is that one had to edit the entire page to find the part after the equal sign; it was otherwise invisible in edit mode. I have fixed the problem, but be careful with what the software can interpret as code. See here for help with this.

PPS: This venue is for proposals. Are you suggesting that we should replace "Wikipedia, the free encyclopaedia" with the manure quote? ;-) Waltham, The Duke of 14:37, 23 August 2008 (UTC)

Close. I would prefer something closer to "Wikipedia - spreading manure one article at a time" ;) Calor (talk) 16:42, 23 August 2008 (UTC)

Hi. Please consider contributing to Motto of the day. Thanks. ~AH1^(TCU) 16:59, 23 August 2008 (UTC)

That's funny! :) GO-PCHS-NJROTC ^(Messages) 03:39, 27 August 2008 (UTC)

Infobox and other tables solution discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This is a copy of a discussion at the Manual of Style. The discussion should continue here as it involves major encyclopedia formatting questions. The most current comments after this posting may need to be copied here. Sswonk (talk) 19:09, 23 August 2008 (UTC)

EXAMPLES of what is being discussed: Ponte Vecchio and Cellini Salt Cellar - Hidden infoboxes.

Proposed solution: test page

Copied from MOS discussion

Watchers of this page might be interested in this discussion. --AndrewHowse (talk) 14:42, 21 August 2008 (UTC)

Yes, indeed. And rather than pipe the link secretively, let me add that it's a discussion of a resolution of the infobox issues, one that is meant to offer an elegant display, which will not compete with and crowd encyclopedia text. An example may currently be seen at Ponte Vecchio, formerly an infobox sorepoint: see Talk:Ponte Vecchio.--Wetman (talk) 14:57, 21 August 2008 (UTC)

We seem to have been pointed here for discussion of this issue. - Denimadept (talk) 20:26, 21 August 2008 (UTC)

Wetman has come up with a brilliant solution to the dreaded infobox, unfortunately, Ponte Vecchio has been reverted back and you can no longer see his idea and the beautiful image of the medieval bridge is again over shadowed by the box. - Epousesquecido (talk) 21:29, 21 August 2008 (UTC)

If they really want to see his ugly condensed version of the infobox on that bridge, they can check the article history. I didn't mind him hiding it so much as I did his (or someone's) reducing the content and the format. - Denimadept (talk) 21:31, 21 August 2008 (UTC)

Denim, would you like to pick a forum and stick to it? I'm happy to discuss all this at length wherever you like, but may we simply refer people to one venue rather than fragment it? Cheers --Joopercoopers (talk) 22:03, 21 August 2008 (UTC)

We've been told to take it either here or some other place I forget. This seems most sensible to me, and we've already been here, so unless Wetman wants to post his proposal the other place, this seems to be what we've been requested to do. Personally, I'd just as soon drop the issue and leave things alone, but Certain People won't allow that. - Denimadept (talk) 23:59, 21 August 2008 (UTC)

For the sake of completeness I will simply repost, more or less, what I said at Editor Assistance:

I think a visible infobox, the contents of which reflects a general sense of restraint, is preferable to a hidden one. Two reasons. First, the casual user will never see the "show" button unless it is conspicuously highlighted. I'm *not* a casual user and I missed the button on both the example pages above. An hide / view preference toggle (or a neon 'show' button) would largely fix that problem, but it wouldn't solve the second, which is that once infoboxes can be hidden as a matter of course, infoboxes will - I guarantee it - begin to accumulate cruft and clutter like your crazy aunt's attic. Every time someone proposes adding yet another stray fact to an infobox, they'll defend it in the same way: "*Someone* might find it useful, and, if you don't like the clutter, then just hide it." The only thing keeping infoboxes remotely sensible now is that we all have to look at them. Let's leave them them as they are.

I said two reasons but really it's three. The third is, too many things on line are buried behind hyperlinks already. We click enough as it is. We should just present the text and let the reader simply take in the page, without having to contemplate how they are intended to *interact* with it. Finally, if an infobox looks cluttered or suffers from too much only marginally useful information, fix the infobox. Don't salt it away like we're ashamed of it. JohnInDC (talk) 01:05, 22 August 2008 (UTC)

I agree completely with JohnInDC. Especially the statement The only thing keeping infoboxes remotely sensible now is that we all have to look at them. older ≠ wiser 12:29, 22 August 2008 (UTC)

• In regard to the use of the "Facts-At-A-Glance" hidden infobox at Cellini Salt Cellar, I think that is a really poor option. There are only three facts in the hidden infobox; I think we should default to showing information rather than hiding it. If you want the facts to be shown at a glance, the best way to do so is to actually display the infobox rather than require people to click on it to find them. If people don't like the way infoboxes are now, it would be better to improve the infoboxes rather than have them hidden. --Metropolitan90 (talk) 17:17, 23 August 2008 (UTC)
• I also oppose hidden infoboxes, for the reasons I gave at WP:EA, and in agreement with those above. (I've added permalinked-diff examples at the top of this thread.) -- Quiddity 17:52, 23 August 2008 (UTC)

Tabbed interface

Joopercoopers has posted a solution test page which answers many concerns. It maintains focus on the text and major images of the article as is desired by many opposed to clutter from infoboxes yet allows for presentation of a variety of formated table structures in a tabbed environment. The major concern I suppose would be the additional clicks that would be required to check facts and vandalism. I support Joopercoopers' method as a solution for the issues raised in this discussion, pending further comments from interested parties. Sswonk (talk) 15:19, 23 August 2008 (UTC)

Joopercoopers' solution is even more elegant than my own.--Wetman (talk) 15:23, 23 August 2008 (UTC)

While I appreciate the thought and effort that went into it, and agree that it is an improvement over an obscure (and obscuring) Show button, I have two main objections to this latest proposal. The first is both esthetic and practical: The layout (and concept) brings nothing so much to mind as the Windows Control Panel window. And, when you hide so many things behind a so many different buttons, the only way to find out whether any of them are valuable to you is simply to click through to each one - a laborious and time-consuming process. Again I strongly prefer an article that says what it needs to say on a single page that one can read, in its entirety, simply by scrolling. Indeed scrolling is *far* less an imposition on those who dislike infoboxes, than click-previous page, click-previous page, click-previous page, click-previous page is going to be for those who find infoboxes useful. The second objection here is the same as my second objection above, which is that by moving information out of sight, you remove the single greatest constraint on poor content - namely, the eyes of other editors. In all this seems like *way* too much work for clearing out a few infoboxes that some editors don't like. JohnInDC (talk) 15:49, 23 August 2008 (UTC)

While I like the possible major reformatting of darn near every article on the project, I wonder how practical it is. While I agree to some degree with JohnInDC, I find Joopercoopers' idea to take better advantage of the medium. Is there some reason that hyperlinks in the TOC are more efficient than both a TOC and a kind of meta-TOC? The main problems would be to

1. determine just how we want to do this
2. how to present it (look like Windows, look like Linux, look like a Mac, look like something else)
3. how to do the conversion, and hardest
4. to convince the rest of the project to do this.

In general, the best change is the least change. For now, unless you really want to attack the big change right now, try concentrating on what you want now. Then air this major reorg in a page where it can be seen by the largest number of editors. I'm very interested in this. "infobox" qua infobox is not my main point: I want a way to see a summary. I've got to think about this. I think a tabbed interface makes sense since pretty much everyone will understand it. Another good thing about it is that it helps split up long articles which go beyond the limits of some browsers without making arbitrary divisions such as exist in some pages. For instance, imagine a South Park article where the List of South Park episodes was on a tab rather than a completely separate article. We could use tabs for such things. This could solve multiple long standing problems. Good work, Joopercoopers! - Denimadept (talk) 16:03, 23 August 2008 (UTC)

This is all way beyond the scope of an infobox discussion. (Plus, wasn't this originally about achieving simplicity? This solution is the opposite of simple!) Historical note: There have been many suggestions [at WP:VPR] for splitting references/external links/galleries/etc off to new tabs. IIRC they were all thoroughly rejected (you'd have to search the archives, or ask there again, to find out why). -- Quiddity 18:27, 23 August 2008 (UTC)

Please add comments below this heading: Sswonk (talk) 19:09, 23 August 2008 (UTC)

Start of Village Pump discussion

Discussion at Request for Editorial Assistance

Discussion at Manual of Style (infobox)

This discussion seeks to resolve the problem of visual encroachment by infoboxes and tables upon space that many feel is better suited for text content within the encyclopedia. The links above are provided for your reference to previous forums which have become broad enough to be finally included in the Village Pump. The discussion here may indeed be broad and important enough to warrant its own page. When and if that occurs, please remove this bolded text.

Oh yes, simplicity is good. What I'm wondering now is why previous tabbed interface suggestions have been shot down. - Denimadept (talk) 20:27, 23 August 2008 (UTC)

For reference, Jooperscoopers used the tabs that I use on my user pages (and which have been used on many other user pages, and at least one project page, Wikipedia:WikiProject U.S. Congress, as well). These were never originally designed to be used for project space, much less article space. So they have some stylistic things which probably, if this idea goes forward, should be made more "article like" in formatting, presumably using CSS. But I've already taken one cut at making these tabs a bit easier to use, which is demonstrated in User:Joopercoopers/Supplement (contrast the source of User:Lar/HeaderTabs with the source of User:Lar/HeaderTabParmed to see the difference that using User:Lar/TabSelect can make). If there is interest I can push this to be more parameterised still ++Lar: t/c 20:44, 23 August 2008 (UTC)

Oh, I forgot to say what I think of the idea of tabbing articles, in general. I think it's a great idea that we ought to seriously consider. I think there are a number of articles that have "auxiliary articles" (history of X, for example) or "reference sections" (galleries or maps or timelines) that would benefit from being separate pages tabbed together. This idea, regardless of whether it was rejected before, deserves a close examination. ++Lar: t/c 20:50, 23 August 2008 (UTC)

The hidden infobox looks ugly and will probably have problems printing, in addition to the cruft-accumulation issues raised above that I agree with. Also, it seems to me that if something is important enough to be in the article, it's important enough to be shown by default; the only things that are usefully collapsed are some things that aren't actually article content, such as navboxes. As for the tabs, my first reaction is that they also look awful, and my second reaction is that they are incredibly slow. While the first may be overcome, I doubt the second can be without making article's structure complicated and difficult for average people to edit. Thus, I must strongly oppose both of these proposals. Anomie⚔ 20:55, 23 August 2008 (UTC)

I hadn't considered what it'd be like to edit the things. That would require more effort to figure out. - Denimadept (talk) 21:00, 23 August 2008 (UTC)

Tabbed subpages seem fairly trivial to edit. While you're viewing that subpage, click edit. et voila, you're editing. Tabbed subpages strike me as faster than if all the information were on one page, since you're not rendering everything at once, so I'm lost as to the speed comment. As for importance requiring everything to be on one page, we now have, to pick an example, Michigan, which has a see also for Timeline of Michigan history, List of Governors of Michigan, United States congressional delegations from Michigan, Elections in Michigan, Michigan Highway System, List of cities, villages, and townships in Michigan, and many more, I've just picked a few. ALL of these are already separate pages, and are not on the main Michigan article. A tabbed structure could tie all of them together nicely. We see discussion to carve out sections of big articles all the time. Moving a section to a different tab is no different, conceptually, than moving a section to a different article completely. ++Lar: t/c 23:30, 23 August 2008 (UTC)

I opened up your example, clicked on one of the tabs, and waited several seconds for the new tab's contents to display. Not good, people expect tabs to switch more or less instantly. It's likely that overcoming this would lead to the excessive complexity, and/or lead to something so fragile that normal people will be afraid to edit it because they might break it.

Also, I can't understand why you fail to see the difference between having references to more in-depth articles on a topic and having random information crammed into {{hidden}} within the article. As for your tab proposal to link them together, IMO it's more useful to have the history subarticles linked from the history section, the government articles linked from the government section, and so on rather than having them all jumbled together at the top of the page and/or having multiple layers of tabs to work through to get to the actual content. Anomie⚔ 00:03, 24 August 2008 (UTC)

Oppose per same reasoning as Anomie. Plus, there may well be many pages on Michigan, but who decides which are incorporated in the tab feature and which aren't? Are we to have a notability grading system now? Besides, the tabs are all at different subpages, which would mean a radical rewrite of WP:NAME. Finally, it would be better to focus on improving each individual article, rather than this proposal. Most topics aren't notable enough for many articles like Michigan, so what happens to those that don't fit into the tab system? Would we then have to have different layouts for them compared to the tabbed pages? Not very consistent then. Besides, tabbing was mostly seen as a bad idea on the Main Page, so why should it be better in articles? Deamon138 (talk) 23:44, 23 August 2008 (UTC)

A system of inter-related articles is what a wiki already is. What is being proposed is a way to organize a kind of sub-wiki. Tabs are just one possible way to implement it. Other user interface methods are possible. - Denimadept (talk) 00:03, 24 August 2008 (UTC)

Another thing. As far as I understand it, this is software. Policies like WP:NAME are not written in stone. If there's a compelling reason to change the name space concept under MediaWiki, we can do it. Perhaps with one large main space, we can have subpages, kind of like the way user sandboxes are now. Or could we do that with the existing implementation?

• Michigan
  • /History
  • /List of municipalities
  • /Transportation
    • /Highways
    • /Rivers
    • /Bridges
  • /Politics
    • /Constitution
    • /List of governors
  • /Sites to see
  • /....
• Massachusetts
  • /History

...etcetera

Each subpage shows up as a tab. Or as an element in some other kind of list showing up at the level above. This is just a sketch. - Denimadept (talk) 00:12, 24 August 2008 (UTC)

Support Weak Support with reservations listed below. I like the idea of tabbed pages for the concerns expressed by Wetman, which involved visual encroachment by infoboxes. This issue is not a trivial one. However, the status quo is strongly supported. If votes be tallied, let's begin that process. Sswonk (talk) 00:38, 24 August 2008 (UTC)

Comment I like the idea of the tabbed pages, but I imagine that it would require unfathomable amount of manhours (personhours) to reformat the entire Wikipedia to fit this new format. Unless a bot could do it, but I imagine that programming a bot to properly recognize all the nuances of which articles do and do not belong together, in which order/format, would be heinously difficult if not impossible. I also would like to voice that, while tabbed pages sound great for long and complex articles for which there are lots of sub-topics, charts, tables, graphs, and galleries to show, the vast majority of articles on Wikipedia, I do believe, are quite short, and I think that branching off references, infoboxes, or subtopics, to separate tabs (separate pages) just wouldn't do in these situations. To take the examples we're already working with, I think the experimental offering regarding the Taj Mahal looks beautiful; the suggestions regarding sub-tabs rather than entire sub-articles for "History of..." and the like are also great. But look at the Cellini Salt Cellar. This infobox contains only three items; I think its inclusion (unhidden) adds to the aesthetic appeal of the page, and adds to an appearance of consistency of format across other articles using that infobox (other artifacts).

I understand the argument made by Wetman and others that infoboxes could be distracting, compete with the text, and could be sources of disinformation, but to put it plainly, I disagree with the idea that they should be gotten rid of. As long as we keep them in control, not too numerous, not too long, and factually accurate and not misleading, they can be wonderful for an article, both aesthetically and in terms of providing information. An infobox tells all the key relevant facts at a glance, and if someone wants the more complex or more nuanced version, they can read the full text. If someone doesn't understand why the Ponte Vecchio is listed as being built numerous times, they can read the text and see that it represents rebuildings after the bridge was destroyed on several occasions. And infoboxes provide a degree of unity and consistency across similar topics (for example, Emperor Shōmu, Diocletian, and Donald I of Scotland who were all monarchs, or Ryūkyū Kingdom, Republic of Texas, and Kingdom of Jerusalem which are all former sovereign nations), which helps to ensure that similar topics can be compared; that the same information is provided across monarchs of different countries, former countries of different time and place, etc. There's my two cents. Thank you. LordAmeth (talk) 01:42, 24 August 2008 (UTC)

An unfathomable amount of manhours (personhours) to reformat the entire Wikipedia to fit this new format was actually considered on my part, but is not really necessary. I saw the adoption of Joopercoopers' vision as a standard for pages that can support such a structure, rather than for every page with an infobox. It would not work well with pages that have a simple infobox and no other tables, such as chestnut. But, with pages that do have many tables and images, like Hurricane Katrina, or for pages where the artistic merit of the subject overrides any need for "facts at a glance", like the Taj Mahal, it might prove quite usefull. I ultimately seek to avoid edit wars between persons such as the prinicpals involved here over infoboxes and their encroachment upon text within articles. There is a great amount of consideration to be done, which is why I suspect the issue may need its own page. Sswonk (talk) 03:17, 24 August 2008 (UTC)

If it's not done on every page then it is inconsistent and therefore confusing to newbies. Deamon138 (talk) 18:39, 24 August 2008 (UTC)

Name one other thing that we have that we require to be on every page. Most pages have infoboxes and categories, but I've yet to see a case of a newbie getting confused when a page doesn't have an infobox. Every page is always in some state of expansion. There is no reason that when we introduce something new we have to introduce it everywhere immediately. We aren't on a deadline. Mr.Z-man 18:50, 24 August 2008 (UTC)

I am not talking about infoboxes I am talking about tabs. Tabs would be part of navigation same as "article, discussion, edit this page, history etc" are part of the navigation are part of the navigation of every article. In fact, the proposed tabs stand out MORE than those ones, so their absence on smaller articles would be more confusing. Why should we have two different sets of graphical styles on articles, when we could just have one consistent one like now? Deamon138 (talk) 21:07, 24 August 2008 (UTC)

Oppose for the key reason: these no longer are easily printable. We need the printed version of a page to display everything that should be on that page, infobox contents or content that was delegated to a tabbed page. Presently, there is a problem that we cannot have collapsed tabled auto-expand on the print media CSS, and thus we should be avoiding starting with tables collapsed. I see the tab solution even worse. I have no idea what this does to screen readers/plain text browsers as well. --MASEM 13:21, 24 August 2008 (UTC)

Oppose for reasons above. JohnInDC (talk) 17:17, 24 August 2008 (UTC)

Oppose the hidden infobox setup per the reasons already given. However, the tab idea has some promise. I don't think doing it purely with wikitext is the way to go. I think a MediaWiki extension to make making, editing, and using the tabs easier would be the way to go. Doing it for every article would just be silly, but doing it for large topics and long pages (of which we probably don't have more than a few thousand) would be good for organization and navigation. Mr.Z-man 17:27, 24 August 2008 (UTC)

The tab system (with appropriate MediaWiki support) seems like an interesting option. It works fine in non-Javascript browsers, where hidden sections don't. --Carnildo (talk) 05:16, 25 August 2008 (UTC)

Here's another idea, in case we've got a shortage. Instead of hiding the infobox, hide the rest of the article after the intro. Call the infobox and intro the "executive summary" and have a link for seeing an expansion. Then the main article won't need to include the infobox. - Denimadept (talk) 15:09, 25 August 2008 (UTC)

Oppose per multiple concerns being mentioned previously. If articles are becoming overwhelmed with infoboxes and images and tables and the like, then the problem is one of editorial discretion; the article and its included infoboxes and such should be trimmed/rearranged/otherwise edited for better layout. Hiding the information in "hidden" areas that require readers to hit a "show" button is a bad idea from the get-go. The notion of tabs, while having some promise, is not really a way to go, either. As mentioned above, it creates problems with printing, but more than that is a matter of simplicity in terms of getting information. In a traditional encyclopedia, you do not expect to have to thumb back and forth between the pages when reading up on Michigan, and a reader here should not be expected to have to keep clicking different tabs while reading an article on Michigan. Shereth 15:24, 25 August 2008 (UTC)

True, however since they already do that, cf articles split on fairly arbitrary breaks due to size limitations, we could make the breaks more systematic. - Denimadept (talk) 15:27, 25 August 2008 (UTC)

Oh, I agree that sometimes articles ought to be split due to length, and when subsections get too big they often are (and should be) split off into an independent article. A sort of structured, tabbed system for accessing these sub-articles would be fantastic if it were supported by the software. What I would oppose, though, is an arbitrary sectioning-off of certain types of information such as maps or tables or graphs. These sorts of things often rely on context, with a paragraph in the article pertaining to an image or such that is logically placed above/below that paragraph. Cordoning them off into a separate tab would break the context and make most of them quite useless. Shereth 15:35, 25 August 2008 (UTC)

That's the problem, along with the printing issues that have been mentioned, that has me beginning to wonder about my support for this solution. The concept and functionality of the proposed solution is top notch and I felt it improved the Taj Mahal article. However, it appears there would be a need for a consensus reaching process on a case by case basis that may prove unworkable. The reason this thread has progressed to this level is that a significant number of editors strongly opposed the use of an infobox in the Ponte Vecchio article and came up with the controversial solution of a "drop down" or initially hidden infobox which is still extant as of this writing. I find that solution to be awkward and inadequate, as have many others. That page is also a member page of WP:WikiProject Bridges which is clear in stating that infoboxes are needed for pages. The group opposed to infoboxes appears to dislike them in the context of artistic or architectural subjects, and may continue to alter current pages in the Ponte Vecchio style until a consensus is reached or they are overruled by administrative action. So, I am hoping that this discussion gains the attention of administrators and also MediaWiki contributors who can help guide us to a workable consensus, if any ulitimately exists. Sswonk (talk) 15:58, 25 August 2008 (UTC)

Hmm, the current "solution" at that article is inelegant at best. I believe the use of infoboxes on Wikipedia has widespread support; it is a good way of encapsulating "standard" information for certain types of subjects. Having not read the full discussion I am not certain of what specific concerns editors have over the use of the infobox at Ponte Vecchio, but personally I have no issues with having the infobox there to offer - as the current state calls it - facts at a glance. I don't think hiding it like it is, is a good solution. Shereth 16:46, 25 August 2008 (UTC)

Hiding it is definitely a problem. Aside from printing as mentioned, it is called "Facts at a glance". It's not at a glance if you have click something before you can glance at it. Deamon138 (talk) 17:05, 25 August 2008 (UTC)

@Shereth... disclaimer, I like infoboxes. I find myself in disagreement with some of the folk who don't like infoboxes (heck, I even disagree with my wife about this, which, let me tell you, is dangerous)... but the sitch with Ponte Vecchio is that it's not exactly a normal bridge, so the bridge infobox doesn't work well, and it's not exactly a normal building either, so the building infobox doesn't work well either. If it had an infobox it would probably be best done as a pure custom one that was made up special just for it, that had combinations of parts of other ones... Maybe that clears up why there was some question about Ponte Vecchio? But that sort of raises the question, if Ponte Vecchio is different, what else is? ++Lar: t/c 22:22, 25 August 2008 (UTC)

Well, my take on that matter is that no "global" solution should be taken as an absolute for every individual article. Exceptions to the rule will always pop up, and this seems to be just such a case. It is my preference that when the editors of a specific article come to a conclusion that an infobox that would normally work well on the article does not, that should trump any kind of generic manual of style/guideline dealing with those sorts of articles. In Ponte Vecchio's case, it may well be that a custom infobox (or perhaps none at all) is called for, and I have no doubt that there are numerous situations that mirror it, but again these should be handled on a case-by-case scenario rather than attempting a fix that is going to trickle down to every article. Shereth 22:55, 25 August 2008 (UTC)

Even if an article such as Michigan has various subsections farmed out due to size issues, the Michigan article itself should contain a summary of what is in the subarticle so that a reader need not leave the page to get an overview of the subtopic. Paper encyclopedias do the same sort of thing, except you have to manually open the other volume instead of clicking a hyperlink. There's nothing particularly "systematic" about tabs that can't be done as things are now, tabs just have extra eye candy and try to force you to remain in the one window. As for a "structured system for accessing sub-articles", is there really a need to reinvent the navbox? Anomie⚔ 17:17, 25 August 2008 (UTC)

Re navbox: for those which are non-linear, yes. They're not standardized, they're not easy to parse, and they're at the bottom of the article, which means that a person doesn't even know they exist w/o scrolling down there. IMHO, large navboxes are not optimal. Little ones can be, depending. - Denimadept (talk) 20:22, 25 August 2008 (UTC)

And these tabs would be somehow standardized and easy to parse? As for the tabs being at the top of the article, I suspect many would have the same problem with that they have with infoboxes and such, that they get in the way of actual content. Anomie⚔ 22:14, 25 August 2008 (UTC)

Screens-full of tabs are the answer! They're so much clearer. Not. Okay, how about a pop-up menu? Also, printing such an article could print the whole thing, or provide a selection of sections to print by means of a "print" button perhaps. - Denimadept (talk) 22:18, 25 August 2008 (UTC)

In response to a concern raised above by Masem above, I am linking two screenshots of how the Taj Mahal article looks in a text browser, normal version here and proposed tabbed version here. In operation, Lynx opens each "tab" of the tabbed proposal as a new page in Lynx. It appears that the version which is presented via the status quo is much better suited to text browsers. Sswonk (talk) 23:05, 25 August 2008 (UTC)

I was unaware this discussion had started until now so apologies for not commenting sooner. I had rather hoped to discuss the pros and cons with others before bringing it here, to iron out some of the issues before offering it to the community for consideration. I'll try and present the arguments against above and my detailed responses to them tomorrow. For now I'll say the tabbed layout isn't simply an 'answer' to 'problems' with infoboxes, but rather an expansion of the type and potential depth of articles. I'm also concerned that the discussion above has conflated the 'hide' infobox with tabbed articles. The tabs are not intended to contain sub-articles (eg on Michigan), but rather a means of providing supplemental information. --Joopercoopers (talk) 23:28, 25 August 2008 (UTC)

To further facilitate the discussion of display of tabular information in text browsers, this table is provided to show links to three possible styles.

Lynx text browser examples

Article name	Type of display	Screenshot of Lynx text browser
Origins and architecture of the Taj Mahal	Current article style	Current style screenshot
User:Joopercoopers/Origins and architecture of the Taj Mahal	Proposed tabbed style	Tabbed style screenshot
Taj Mahal	Taj Mahal main page with infobox	Start of article with infobox screenshot

Also thanks to Joopercoopers for his work thus far and for pointing out that the focus of this discussion should remain on display of supplemental information, rather than on tabbing sub-articles. Sswonk (talk) 01:08, 26 August 2008 (UTC)

Being that everyone is contributing to this thread at cross-purposes (and the multiple "opposes" above, in response to the confused-specifics), I'd strongly suggest you archive this thread, and let Joopercoopers start his own thread when his proposal is ready. -- Quiddity 01:19, 26 August 2008 (UTC)

Thanks quiddity - yes I'd rather present my case in a rather less confused way, when I've got the details thrashed out a little better. Archiving.....--Joopercoopers (talk) 12:30, 26 August 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.