Wikipedia talk:Featured list candidates/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Archive 16

→

Archive 20

Nominations Viewer for WP:FAC, WP:FARC, WP:FLC, WP:FLRC, and WP:FPC

Wikipedia:Featured article candidates with Nominations Viewer enabled

Here's a tool I made for myself that others might find useful. You can go to the script's documentation to learn more about it, including how to install it and configure it, but basically what it does is it collapses all nominations by default. You can expand the ones you want to read, and even click on "view nomination" to go directly to the nomination instead of having to click on the "edit" link first. This script will probably not be useful for those who like to just scroll through the nominations pages to find something they like, but personally I like to scroll through the article titles and when I find something interesting, I expand it to read it so that I don't have to first sift through some particularly long nominations.

This was just an idea that I had floating around a while back and finally got around to doing it. Feedback is welcome, but I may move slowly on adding new features if I've done enough coding for that day. One thing in particular that I might add is the {{la}} template, so that there are more links available to click on. It can, of course, be enabled/disabled on a per-user basis. Gary King (talk) 19:06, 6 April 2010 (UTC)

I just installed it and I'm already enamored. Nice work, Gary! KV5 (Talk • Phils) 19:57, 6 April 2010 (UTC)

Cool—Chris!_c/t 20:14, 6 April 2010 (UTC)

• Nice! The edit-click-to-go-to-nomination always bothered me. Installing now. Staxringold _talk^contribs 20:43, 6 April 2010 (UTC)

Good work, but can you make it work for Vector? Dabomb87 (talk) 21:20, 6 April 2010 (UTC)

By the way, I don't mean to sound ungrateful. This is a great tool, and it will definitely save me time when I do closures. Dabomb87 (talk) 21:22, 6 April 2010 (UTC)

It does work with vector. You just need to add it to User:Dabomb87/vector.js. Gary King (talk) 21:26, 6 April 2010 (UTC)

Ah, I keep forgetting to do that. Thanks, Dabomb87 (talk) 21:34, 6 April 2010 (UTC)

Strange. Doesn't work for me on Vector. Dabomb87 (talk) 21:38, 6 April 2010 (UTC)

Did you bypass your cache?—Chris!_c/t 21:41, 6 April 2010 (UTC)

Works for me. Vector, on WP:FLC (on my other account). Gary King (talk) 21:43, 6 April 2010 (UTC)

Not sure what I'm doing wrong. I've bypassed (and purged, for good measure) my cache multiple times, but nothing seems to work. Dabomb87 (talk) 21:52, 6 April 2010 (UTC)

Got the solution. Posted it on your talk page. Gary King (talk) 22:14, 6 April 2010 (UTC)

Thanks. Dabomb87 (talk) 22:25, 6 April 2010 (UTC)

I can't get it to work either. I have removed everything else from my monobook.js file and still nothing.—NMajdan•talk 13:39, 13 April 2010 (UTC)

I tried this version of your monobook.js. All your scripts worked for me, including this one. Gary King (talk) 06:41, 14 April 2010 (UTC)

Odd. Just restored my monobook and still nothing. Oh well.—NMajdan•talk 16:25, 14 April 2010 (UTC)

FLCs and FLRCs will be closed manually for now

Resolved

 – GimmeBot back in business

See here for details. I can take care of the first few closures, but during the week I might need regulars to help out. Dabomb87 (talk) 14:08, 10 April 2010 (UTC)

The closing instructions are at User:Matthewedwards/FL#GimmeBot steps. Dabomb87 (talk) 14:38, 10 April 2010 (UTC)

If anybody needs a model, just see what I did at List of accolades received by Avatar and its corresponding talk page and FLC nomination. Dabomb87 (talk) 14:47, 10 April 2010 (UTC)

What does "help out" mean (wow, I feel like I'm reviewing!)? I'm assuming you're referring to taking care of the technical things (updating the Articlehistory, closing the nomination page, etc.) and not to actually deciding which nominations to promote. If this is correct, how do you see yourself telling the "regulars" what noms need proper closing? Thanks, Mm40 (talk) 22:20, 11 April 2010 (UTC)

I can help. Just send me a list of promoted FLCs and I will do the rest. The instruction looks very clear to me.—Chris!_c/t 22:39, 11 April 2010 (UTC)

To DaBomb: I noticed you removed some steps earlier today. Are they to do with the old way FLC pages were opened and archived to an N subpage?

Also to Dabomb and TRM: because the bot ran only two days of the week, archiving was confined to those two days. Will nominations be archived more frequently throughout the week now?

To everyone else: With regards to Gimmebot, not only did it update article talk pages, it archived WP:GO on a Saturday night, it "tagged" nomination pages as being closed (you know, when they get coloured in and say "Promoted by xxxxxx at xxxxxx"), and it updated WP:FL, WP:FFL, and the logs when articles were moved to new names. This may be one of the hardest things to stay on top of. Matthewedwards :  Chat  02:37, 12 April 2010 (UTC)

Matthew: 1) Yes; 2) Well, some time ago we decided that we needn't wait until Tuesday and Saturday evenings to promote/archive because that was unfair to nominators whose FLCs were clearly ready to be promoted during mid-week. So this doesn't change much, but it makes the whole thing a moot point since it makes more sense to do the whole archiving procedure unless there's no time.

WP:GO – should be archived every Sunday just after 0:00 UTC (midnight in the UK, early to late evening in the US, and early to mid-afternoon in Australia), and the archival instructions are in a hidden HTML comment. Between Sandy, me, and a couple other FA regulars I don't think this should be a problem.

Fixing links is also important, but shouldn't be too troublesome; just run User:Splarka/dabfinder.js once a week or so to find the redirects. Dabomb87 (talk) 03:02, 12 April 2010 (UTC)

Thanks Chris. To Mm: yes, I'm referring only to the technical side of things (adding/updating ArticleHistory, tagging closed discussions, and adding/removing the FL star if necessary). Dabomb87 (talk) 03:02, 12 April 2010 (UTC)

And now, it is no longer an issue, because GimmeBot is working again. Dabomb87 (talk) 03:26, 14 April 2010 (UTC)

FL categorization issue

Please see Wikipedia talk:Featured lists#Awards and prizes issue. Dabomb87 (talk) 03:39, 16 April 2010 (UTC)

Might have broken the FLC page

This discussion was moved from WT:FL.

I posted my nomination for List of Phi Kappa Psi brothers incorrectly, and then correctly, but it looks like the first go has left a ghost entry on the page here: Wikipedia:Featured list candidates#List of Phi Kappa Psi brothers NYCRuss ☎ 01:08, 17 April 2010 (UTC)

No, everything looks fine. Dabomb87 (talk) 13:58, 17 April 2010 (UTC)

Major update for Wikipedia:Nominations Viewer

I released Wikipedia:Nominations Viewer two weeks ago. Today, I added new features to the script in response to suggestions made by some users. The script now shows more information when viewing nominations, including when the nomination was submitted, how many people are involved in the nomination, how much support it has received (keeps/delists if at WP:FAR or WP:FLRC), and how many co-nominators there are. If you hover over each piece of information, it will give you some extra details as well. The information shown can be re-arranged as you please, or removed completely, by using the settings as shown in the documentation. If you already have the script installed, you may need to bypass your cache to get the new features. Gary King (talk) 02:14, 18 April 2010 (UTC)

Nominations Viewer at WP:FAC

Capitalization naming disagreement at Wikipedia:Featured list candidates/List of National Parks of the United States/archive1

Should "National Parks" be capitalized or lowercase in the list's title? Please comment at the FLC. Dabomb87 (talk) 01:34, 1 May 2010 (UTC)

Red linking

This stigma against red linking needs to be dealt with. Red links cannot be listed on disambiguation pages if nothing else points to them. If there are no red links, they cannot be found with the red link tools, so the articles aren't even considered for creation. — Dispenser 06:28, 2 May 2010 (UTC)

Does anything go for a feature list subject?

After watching the FL-proces for some time now, I've come to notice that there's some dislike for lists which combine two categories (X and Y) to create a "List of X which are Y" i.e. "List of Jewish Nobel-Prize winners" here had some criticism on that point, but failed due to other concerns. Recently a list was brought up for FLRC, List_of_family_relations_in_the_NHL, and I opposed because I found the combination of the two categories "family relations" and "NHL" too weird and fanciful.

I therefore propose (don't know if this is the right forum) that if a list is a combination of two or more categories then the combination should be notable, i.e. there should exist several sources discussing family relations in the NHL and Jews among Nobel laureates, before the list can be considered for FL (hereby acknowledging that a list shouldn't be considered for deletion just because it doesn't have a source making the combination notable, or maybe it should I don't know). Sandman888 (talk) 12:53, 15 May 2010 (UTC)

I think that this is rule already. Although not explicitly in the criteria, it falls under the "meeting the requirements for all Wikipedia content" part—whether the list is notable. If the combination isn't notable then it shouldn't be on wiki in the first place (this has the obvious caveat of where a combination is created to for size purposes (e.g. this). Rambo's Revenge (talk) 14:41, 15 May 2010 (UTC)

Well how about List_of_Nobel_laureates_affiliated_with_Princeton_University, it isn't said in lead that the Princeton - Nobel laureates link is a notable combination. Should it then be proposed for deletion, due to lack of notability? Note that all of the laureates are already listed in the "Nobel Laureates" list Sandman888 (talk) 15:43, 15 May 2010 (UTC)

• I think so. You can break apart any large group into random sub-groups, but if they aren't notable sub-groups why discuss them? The only exception, I'd say, is when lists are broken apart by name for convinience and ease of reading (like the Civil War MoH winners). Staxringold _talk^contribs`

There should not be a rule about this because every list is different and whether it passes FLC or not should be considered case by case.—Chris!_c/t 17:28, 15 May 2010 (UTC)

• • well why should it be considered on a case by case basis? This leaves a lot of discretion to whoever sees the list, so one day a "List of Afro-American nobel laureates" passes but the next week "List of Jewish Nobel Laureates" fails because other editors are reviewing the list, or perhaps the other editors doesn't like the guy who nominated the list. This is of course hugely inconsistent, and the arbitrary nature of a case-by-case basis favors clear and explicit rules. Sandman888 (talk) 18:17, 15 May 2010 (UTC)
    • Again, every list is different. Perhaps the connection between Jewish and Nobel Prize winner is more well-documented, so it is notable to have such list. But this may not be the case in the Afro-American list. We cannot just arbitrarily prohibit them all just because their topic is similar. Besides, there is already rule on this, WP:N, that is quite flexible to fit different cases. I just don't see the need for an extra rule.—Chris!_c/t 18:38, 15 May 2010 (UTC)
      • So you agree that when splitting into a subgroup, then the subgroup should be notable? I.e. given that the link between Princeton and Nobel Prize winners is not notable, then it should be moved to FLRC or even PROD? As it is now, practice is to allow some lists of questionable notability and deny others, and I'm finding that very inconsistent. So I really believe that a guideline should be made saying that when combining two or more categories, then the link should itself be notable. Sandman888 (talk) 09:21, 16 May 2010 (UTC)
      • Well, I agree that when splitting into a subgroup, the subgroup should be notable. But a new guideline is not needed IMO. Wikipedia:Notability already states that every article (or list for that matter) in Wikipedia should be notable. But if people think it is a good idea to have a new guideline, then I will not oppose it.—Chris!_c/t 17:24, 16 May 2010 (UTC)

Wouldn't it be easier to look at the existing criteria, specifically "3(b) In length and/or topic, it meets all of the requirements for stand-alone lists; it is not a content fork, does not largely recreate material from another article, and could not reasonably be included as part of a related article." The argument could be made, for example, that a list of nobel laureates by university fails 3(b) because it could reasonably included as part of a list of alumni / faculty for that university, as well as (obviously) the existing lists of nobel laureates. I wonder whether a new rule is necessary. Bencherlite^Talk 20:58, 18 May 2010 (UTC)

Multiple noms

I understand that one nominator can nominate one FLC at a time. However, if there are co-nominators, can two people co-nominate two at a time?--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 15:43, 12 May 2010 (UTC)

I don't see why not, we can be pretty flexible about this, as long as the concerns on the first list are mainly addressed, especially if the two are similar in nature, a second nomination is fine. The Rambling Man (talk) 15:48, 12 May 2010 (UTC)

Another multiple noms question- my FLC, Hugo Award for Best Novel, hasn't had a comment since May 7 (11 days). I have another list- Hugo Award for Best Novella, which is structurally identical and differs almost exclusively on the titles/authors in the table- in fact, all of the changes from the Novel FLC have been ported over to the novella page. Can I go ahead and nominate the Novella page, or should I hold off until the Novel FLC is closed? --PresN 20:48, 18 May 2010 (UTC)

The Hugo list has several supports, so feel free to nominate the next list too. Of course, it would also be appreciated if you could offer some reviews, too... Dabomb87 (talk) 03:55, 19 May 2010 (UTC)

Will do, thanks! --PresN 13:36, 19 May 2010 (UTC)

Query on sourcing

Hello. I have List of Lincoln City F.C. seasons nearly ready for submission to FLC. However, the major reliable source for the league and some cup stats, Richard Rundle's Football Club History Database (FCHD), became unavailable approaching three weeks ago and hasn't yet reappeared. A previous version of that site, at another host, still exists, but only goes up to 2006. I can add additional sources for the league and major cup stats, to cover the most recent four seasons. The query is, there are a few details on minor cup competitions (explanatory notes rather than actual results) which I may struggle to source elsewhere, and which FCHD only covered in the post-2006 version. Do people think the FCHD source would be accepted good-faith for those details, or should I remove them pending an alternative source or the revival of FCHD? cheers, Struway2 (talk) 08:50, 17 May 2010 (UTC)

• • have you tried internet archive for those you miss? Sandman888 (talk) 11:10, 17 May 2010 (UTC)

Yes, though thanks for suggesting it. Archived down to summary page, but not the individual season pages, which is what I'm after. cheers, Struway2 (talk) 11:28, 17 May 2010 (UTC)

If the source is not operating properly, then the information is not verifiable at the moment. I could understand leaving it if the site was only down a couple of days due to maintenance, but there's a possibility the site is gone for good if it's been a few weeks. The notes in question should probably be cited elsewhere or removed, especially considering the list is getting prepped for FLC. Giants2008 (27 and counting) 16:20, 19 May 2010 (UTC)

Announcing the Reviewer Summary script, used to summarize information on reviewers

This script was originally suggested by User:Mike Christie to be an extension of the Nominations Viewer script. However, this new script requires a different set of functions from Nominations Viewer, so it had to be written from scratch. What the script does is, when used on a Featured Log page such as the one for successful Featured Articles, it shows the Reviewer Summary table, which summarizes all the editors who edited the nominations found on the current page. See the script's documentation as well as the screenshot below for more information. The table's information can be easily copied to be used in discussions, as well (see the first point in the screenshot below). Hopefully the script will come in handy for analyzing nomination reviewers, etc. Gary King (talk) 08:18, 20 May 2010 (UTC)

Reviewer Summary at Wikipedia:Featured article candidates/Featured log/May 2010

• So, if I understand it, this script takes the FL log and breaks down who was posting reviews? Staxringold _talk^contribs 18:04, 26 May 2010 (UTC)

  Yeah Gary King (talk) 18:50, 26 May 2010 (UTC)

New script: Expand Hidden Templates

I figure that since {{hidden}} templates are used very frequently here at WP:FLC, this might be useful for regulars around here. What this script does is it adds a link to the toolbox in the left-hand panel called "Expand templates". When clicked on, it expands all hidden templates, including {{hidden}}, {{hidden archive top}}, and their derivatives. After expanding the templates, the link in the toolbox can then be used to collapse all hidden templates again. (I originally created this script in response to this discussion.) Gary King (talk) 15:51, 26 May 2010 (UTC)

Naming convention for Football lists

An RfC has begun on the WT:FOOTY#Name of football player lists page regarding proper naming. Sandman888 (talk) 19:52, 27 May 2010 (UTC)

Admin help needed

Please move Wikipedia:Featured list candidates/List of Red Hot Chili Peppers band members to Wikipedia:Featured list candidates/List of Red Hot Chili Peppers band members/archive1 and delete the former. Thanks, Dabomb87 (talk) 14:01, 31 May 2010 (UTC)

 Done Rambo's Revenge (talk) 14:21, 31 May 2010 (UTC)

Thank you! Dabomb87 (talk) 14:34, 31 May 2010 (UTC)

Reg. the two FLRCs

On the top of the FLC page it say:

"The following lists were nominated for removal more than 14 days ago:"

And nothing is listed. Perhaps more reviewers wd attend the FLRCs if they where there. Sandman888 (talk) 15:57, 3 June 2010 (UTC)

Done. Feel free to do this yourself in future. The Rambling Man (talk) 16:21, 3 June 2010 (UTC)

Consensus clarified

What's the rule (of thumb) for consensus? Three supports and no opposes / valid concerns? Sandman888 (talk) 10:06, 15 June 2010 (UTC)

I think Dabomb87 & I both operate on the 3–4 supports with no major outstanding concerns. In general. Of course, there are exceptions, particularly for niche/specialist lists which may not receive the attention they deserve (e.g. Wikipedia:Featured list candidates/List of birds of Leicestershire and Rutland/archive1 running right now). Cheers. The Rambling Man (talk) 10:30, 15 June 2010 (UTC)

Agreed. Dabomb87 (talk) 14:43, 15 June 2010 (UTC)

"Reviewer" userright

The "reviewer" userright, allowing you to to review other users' edits on certain flagged pages. Pending changes, also known as flagged protection, will be commencing a a two-month trial at approximately 23:00, 2010 June 15 (UTC).

The Flagged Protection trial is going to be starting very soon, and non-admins who have had access to edit semi-protected articles since roughly Day 4 of their editorship will now have their edits going into a vetting queue unless they are granted autoreviewer and/or edit reviewer permissions by an administrator. This will have a significant impact on editors who have, for years, been working on quality content. More detailed documentation and guidelines can be found here.

If you have not already done so, please request this "right" at WP:PERM/RW or ask any administrator. Cheers, Dabomb87 (talk) 15:18, 15 June 2010 (UTC)

I'm happy to take personal requests for this user right. The Rambling Man (talk) 15:30, 15 June 2010 (UTC)

As would I. — KV5 • Talk • 15:33, 15 June 2010 (UTC)

Me too Matthewedwards :  Chat  16:18, 15 June 2010 (UTC)

Any sorting experts?

Resolved

I'm having a bit of trouble at List of Watford F.C. seasons. Initially, I managed to get it working fine, despite the fact that I was using colspan: [1].

But I'm trying to incorporate the club's early history, and as can be seen from the subsequent edits nothing seems to work. Bizarrely, it still sorts fine from 1898 onwards even with the early history added, and the colspans used to indicate the world wars don't pose any problems. It's just the early history that refuses to sort. Help would be much appreciated. Regards, WFC (talk) 21:28, 9 July 2010 (UTC)

Just wondering why you'd want to sort a seasons list? cheers, Struway2 (talk) 21:32, 9 July 2010 (UTC)

If you can sort a properly formatted seasons list, you have instant access to pretty much any historic statistic you could ever want to know. For instance most goals in a season (as well as which season that was), most wins/draws/losses (and when). Most individual goals in a season. Sorting by performances in the league, FA Cup or League Cup. And with a bit of tweaking with sort keys, I would be able to get it to work for even more obscure facts, such as who has scored the most goals at a given level of English football, or a club's historic results/placings at each level of English football. WFC (talk) 21:44, 9 July 2010 (UTC)

Never mind. I've worked out the problem. Using |colspan= in a sortable table is fine, but it would seem that using different lengths of it is a no-no. Instead I'll split the table into pre-league and league, and early testing suggests that's fine. I will sell the concept more convincingly to you one day Struway, promise! WFC (talk) 23:04, 9 July 2010 (UTC)

Multiple nominations

Just wondering if it was still the case that "Users should not add a second FL nomination until the first has gained support and reviewers' concerns have been substantially addressed"? cheers, Struway2 (talk) 07:39, 7 July 2010 (UTC)

Yes, I think so. In general this is to counteract problems with multiple nominations of similar lists, all of which may have similar issues. More specifically, it was also intended that it would focus the nominator's mind to completely address the concerns on one list before attempting another nomination. The Rambling Man (talk) 08:13, 7 July 2010 (UTC)

I don't think it's being followed by a lot of users. Just being around here for the past several months, I've seen users nominate more then one list, even when their first nomination hasn't received any reviews. It's frustrating to have to wait for weeks to nominate another FLC while some users have multiple FLCs (it's really frustrating when renominating FLCs due to lack of reviews while others have multiple FLCs queued, and promoted that had fewer votes for support). NThomas (talk) 00:08, 10 July 2010 (UTC)

Maybe it needs to be made more prominent? I've been away for a few months, and if it weren't for this thread I would have assumed that we were working under the old system (no formal limit, unless announced on the talk page or closure log). I know there's no excuse for not reading the instructions thoroughly, but it's worth remembering that it will happen regardless. WFC (talk) 00:16, 10 July 2010 (UTC)

Some of the blame rests with me; I've been gone or sidetracked with things during the past few weeks, and haven't been paying too much attention to who's been nominating what. At the same time, I don't want to prematurely close nominations that have been open for some time. I'll try to be more alert about these things in the future. Dabomb87 (talk) 17:25, 10 July 2010 (UTC)

Toolbox messed up

Resolved

Not a huge issue, but the toolboxes on the individual nomination pages (i.e. the pages transcluded onto WP:FLC) are not in boxes. Code appears around the box. The toolbox is transcluded from Wikipedia:Featured list tools, which hasn't been edited since March of last year. Any ideas why this has happened? Mm40 (talk) 13:34, 11 July 2010 (UTC)

There seems to be an issue with Template:Featured article tools. I have asked the admin who may have introduced the glitch to fix it. Dabomb87 (talk) 13:57, 11 July 2010 (UTC)

It has been fixed. You may need to purge your cache. Dabomb87 (talk) 14:04, 11 July 2010 (UTC)

Requesting review of my recent closure

Recently, I closed Wikipedia:Featured list candidates/List of Recopa Sudamericana winners/archive2 as unsuccessful—my rationale is at the closure log. The nominator considers my closure of the nomination improper (please see User talk:Dabomb87#List of Recopa Sudamericana winners). Please review my action to determine if it was proper or improper; please be frank. If you all think it was improper, I will be happy to re-open the nomination and temporarily take a break from closing FLCs, if need be. Thanks, Dabomb87 (talk) 03:55, 12 July 2010 (UTC)

Clearly you couldn't promote without declarations of support. The two opposes, KV's opening comment and the lack of progress in the eyes of those three reviewers made it difficult for you to keep it open for too much longer. It's true that allowing more time or not was within your discretion, and for that reason I understand why you felt the need to start this thread. But frankly, given that multiple people brought up unresolved issues from the previous FLC, I think you were very fair in allowing the FLC to run in the first place. No further action needed. Regards, WFC (talk) 05:07, 12 July 2010 (UTC)

Concur completely. --Courcelles (talk) 05:13, 12 July 2010 (UTC)

Agree entirely as well. Lists simply aren't promoted unless other editors support them, and nobody was supporting this one after two weeks. Bencherlite^Talk 08:58, 12 July 2010 (UTC)

I see no issue with this closure. FLC is not here as a vessel to provide peer reviews of lists, it's here to assess lists for excellence, and that assumes a minimum standard is reached before nomination. Outstanding issues from a previous nomination should certainly be addressed before renominating a list, and nominators are encouraged to work with reviewers, as those reviewers spend a lot of their own valuable time in trying to ensure we promote only the finest work to featured status. The Rambling Man (talk) 09:04, 12 July 2010 (UTC)

Agree with all above comments. No reason to believe this would be considered an improper close. — KV5 • Talk • 11:54, 12 July 2010 (UTC)

No supports = no promotion. Nothing controversial about that. Oldelpaso (talk) 10:05, 13 July 2010 (UTC)

Comments from Multiple editors were not addressed. Two Opposes. No Supports. Looks fine to me. Claims of bias are curious and don't make sense. Against what or whom is there alleged bias, anyways? --GrapedApe (talk) 22:08, 14 July 2010 (UTC)

Everyone above me has it exactly right. In fact, if a list with no supporters and two opposers in two weeks was promoted, I would be the first to complain about it. That would make me think that bias was a factor. This is merely a decision that a director must be willing to make. Giants2008 (27 and counting) 14:10, 16 July 2010 (UTC)

Another naming discussion - "List of X" or "X"?

See Wikipedia:Featured list candidates/List of chapels preserved by the Historic Chapels Trust/archive1 and opine on the best page name, if you would be so kind. Bencherlite^Talk 20:34, 14 July 2010 (UTC)

Now renamed by consensus to Wikipedia:Featured list candidates/Historic Chapels Trust/archive1; thanks to those who joined in. Bencherlite^Talk 11:05, 15 July 2010 (UTC)

Script suggestion

When making an FLC it automatically shows previous FLCs on the top. Why not also expand that to include all previous peer reviews? I guess it shows previous FLCs so reviewers can check any previous concerns, but the same cd be said of peer reviews. Sandman888 (talk) 09:46, 16 July 2010 (UTC)

Gallery

One list currently at FLC, List of sects in the Latter Day Saint movement, has an image gallery, which is generally discouraged per WP:IG. However, this list may well be an exception to the rule. Please comment on the issue at Wikipedia:Featured list candidates/List of sects in the Latter Day Saint movement/archive1 if you have the time. Thanks, Dabomb87 (talk) 03:00, 19 July 2010 (UTC)

Dabomb87 is not the only one who has said this. Images were requested numerous times in both the Peer Review and the FL process, so they were added. However, no one has been able to figure out a good way to put them in. Several of the major editors have attempted to figure out a better way, but failed. They just don't fit into the overall structure of the boxes and the artical. In the past, I even worked up a mockup (on my own sandbox page) of what might have been a better way to do it, only to be convinced I was wrong. The issue of where and how to put the image in has been discuses a number of time. See and see However, putting them in as they are has been the best anyone can come up with. If anyone has a better idea, please by all means let us know. We would be thrilled to implement it--ARTEST4ECHO ^talk 13:13, 19 July 2010 (UTC)

WP:IG states that "The images in the gallery collectively must have encyclopedic value and add to the reader's understanding of the subject. Images in a gallery should be suitably captioned to explain their relevance both to the article subject and to the theme of the gallery, and the gallery should be appropriately titled... Images in a gallery should be carefully selected, avoiding similar or repetitive images". I believe that these three criteria (encyclopedic value, relevance to the article explained, and an appropriate title) are met in this regard. It's also not an indiscriminate collection or "a tool to shoehorn images into an article" in this case. As long as none of the images are fair use, I'd see no reason with permitting the gallery in this case. — KV5 • Talk • 13:41, 19 July 2010 (UTC)

Concur completely with KV. I don't want to set a precident, but this article makes a strong case. WFC (talk) 17:00, 19 July 2010 (UTC)

I know for a fact that none of these artical are "fair use" as this was noted before and all "fair use" images were removed.--ARTEST4ECHO ^talk 20:34, 19 July 2010 (UTC)

Then we should be good. — KV5 • Talk • 01:52, 20 July 2010 (UTC)

(copied from the FLC) I'm not a huge fan of galleries, but given the well-reasoned arguments and the consensus among other editors who have opined on the issue, I will not let this issue prevent this list from receiving its well-deserved FL star. Dabomb87 (talk) 03:11, 20 July 2010 (UTC)

Proposal pointer

Featured List regulars may be interested in an ongoing discussion at WP:VPR regarding the addition of (an) intermediary ranking(s) between List and Featured List. The heading is "Grading Scheme" for those who wish to join the discussion. Disclaimer: I have already supported the proposal, but have tried to make this notice as neutral as possible. Cheers, Nikkimaria (talk) 01:24, 30 July 2010 (UTC)

The relevant section is here. Dabomb87 (talk) 01:46, 30 July 2010 (UTC)

Size?

I was thinking of (eventually) submitting an article for FLC, but, due to the number of references used, the article exceeds the recommended size for articles. Would this be a barrier to FL status? What other long lists have become Featured? I haven't done a FL in years. Firsfron of Ronchester 22:50, 1 August 2010 (UTC)

Off the top of my head, List of cutaneous conditions was promoted a little more than a year ago, and it is one of the longest FLs I have seen. Dabomb87 (talk) 23:06, 1 August 2010 (UTC)

I used User:Dr pda/generatestats.js to generate a list of the longest featured lists, see User:Dabomb87/Misc#Notes. Dabomb87 (talk) 23:11, 1 August 2010 (UTC)

Thanks. So size is not an issue at all then? With FL List of Chinese inventions at 247 kb... If that's the case, I won't worry about chopping this list up. Firsfron of Ronchester 02:09, 2 August 2010 (UTC)

Size is an issue, but lists are given more leeway than normal articles. Take a look at WP:SIZERULE. Goodraise 14:33, 3 August 2010 (UTC)

Tables: new accessibility guideline in MoS

Over at WT:FL?, someone asked if this new change should become part of the criteria. I certainly didn't know about the change so thought I'd see if others did and bring it to a wider audience. Implemented here (talk explanation), it seems to allow voice browsers to read information in tables and state what column and row header is associated to the cell. Rambo's Revenge (talk) 11:30, 3 August 2010 (UTC)

Doesn't "It complies with the Manual of Style and its supplementary pages" make it part of the criteria already? Goodraise 14:29, 3 August 2010 (UTC)

If it does, it's not going to last long, given that it effectively states that we shouldn't use rowspans, colspans, or multi-level table headings. --WFC-- 14:33, 3 August 2010 (UTC)

List title suggestions

I'm planning to create a list based on the biannual publication from the IUCN called "The World's Top 25 Most Endangered Primates." The only catch is that I'm not sure what exactly to name it. Should I just use that name? However, the IUCN has also used the phrases "Top 25 Most Endangered Primates" and "Primates in Peril". Once I figure this out and write the list, it will probably be visiting FLC in the not-to-distant future. I'd rather name is right the first time and create redirects as necessary. – VisionHolder « talk » 15:16, 4 August 2010 (UTC)

It should probably be as clear as possible. To that end, I suggest "IUCN Top 25 Most Endangered Primates". "Primates in Peril" seems more like a marketing term (or, at least, it sounds that way to me). Having the organization name in the title makes it clear that you are referring just to that organization's publication and not to information reported in other outside sources. And "The World's" just seems like it's unnecessary; are there endangered primates on Mars too? — KV5 • Talk • 15:18, 4 August 2010 (UTC)

I agree. However, should it be "IUCN" or "IUCN's"? Just making sure there's no obscure rule about plurals in titles that I've missed somewhere along the line. – VisionHolder « talk » 16:12, 4 August 2010 (UTC)

I think IUCN is sufficient; the fact that it's there shows possession of the list/information by the organization without the "'s". — KV5 • Talk • 16:22, 4 August 2010 (UTC)

In writing the list, I'm learning that although the IUCN started the list in 2000, starting in 2002, it became a joint project with the International Primatological Society (IPS), and Conservation International (CI). Therefore, I'm not sure if the title IUCN Top 25 Most Endangered Primates is entirely appropriate. Any other suggestions? – VisionHolder « talk » 22:46, 5 August 2010 (UTC)

I've never heard of it? I assume it must be referred to by other publications occassionally. What WP:COMMONNAME do they use? Additionally, on the name, are you going to write about the current list or be writing about all the historical lists. I'm not sure this will make a difference to the name, but it might. Rambo's Revenge (talk) 22:59, 5 August 2010 (UTC)

Other publications refer to it, though they usually report that a species is "one of the 25 most endangered primates" according to the IUCN, CI, and IPS. The language varies. Often, people give the formal name of the publication (Primates in Peril: The World's 25 Most Endangered Primates, 2008-2010), then just refer to the "25 most endangered primate species." Here's a list of what I found on a web search, including news reports:

• Primates in Trouble, Says Report on 25 Rarest (National Geographic)
• 25 Most Endangered Primate Species (Primatology.net)
• Primates in Peril - 25 most threatened species of primate
• Experts list 25 most endangered primates (MSNBC)
• Half of all primates threatened with extinction (National Geographic)

Should it just be List of 25 most endangered primates? So far, that seems best to me. – VisionHolder « talk » 23:24, 5 August 2010 (UTC)

Forgot to mention... the list is also including historical information, such as previous lists and lists of previously listed species. – VisionHolder « talk » 23:25, 5 August 2010 (UTC)

Then again... should it be capitalized, if people approve of the name (List of the 25 Most Endangered Primates) because that's the formal name, minus "The World's". Or should we just use the full title: List of The World's 25 Most Endangered Primates? Damn, this is complicated.... – VisionHolder « talk » 00:30, 6 August 2010 (UTC)

I don't think we should have "list of" there, since it suggests this is a list of what Wikipedia considers the 25 most endangered, not an article on an outside list. Ucucha 14:27, 7 August 2010 (UTC)

So maybe use title case, "The World's 25 Most Endangered Primates", just as we would with an article about a published work? Also, would it be italicized? – VisionHolder « talk » 14:37, 7 August 2010 (UTC)

(Edit conflict) Some sources:

• Rekaris & Munds (2010, doi:10.1007/978-1-4419-1560-3_22): Top 25 Most Endangered Primates
• Vargas et al. (2002, Biol. Cons. 108:325–334): 25 most critically endangered primates in the world
• Lemur News 12 (2007): "25 most endangered primates", "World's 25 Most Endangered Primates" (repeatedly)
• Magnuson (2002–2003, African Primates 6:19–26): "25 most endangered primates in the world"
• Shekelle et al. (2008, Primate Conservation 23:55–68): "world’s 25 most endangered primates", "World’s 25 Most Endangered Primates"
• Fellowes et al., (2008, Asian Primates Journal 1:2–9): ""25 most endangered primates"
• Rudran (2007, Primate Conservation 22): "25 most endangered primates in the world"

From that small sample, I think "(The) World's 25 Most Endangered Primates" would be appropriate; it has the added advantage of being in the publication's official name and is used reasonably often in other sources. Ucucha 14:39, 7 August 2010 (UTC)

In that case, I will probably go with the official title, including the article "The" at the front since that's what is in the official publication. Since the citation italicizes the title, I'm assuming I should do the same. (Revert me if I'm wrong.) Is there an infobox I should use for this publication? I can't seem to find anything appropriate for it. Lastly, do any of those publications look like they have material worth including and citing in the article? – VisionHolder « talk » 14:53, 7 August 2010 (UTC)

I agree. with that reasoning. I did create a redirect from that title to your original title, but I assume it would not be an issue to move the article over the redirect. If it is, let me know and I'll delete the redirect. Rlendog (talk) 16:42, 7 August 2010 (UTC)

It's already been moved. Visionholder: Most just said that the species they were dealing with is on the list, but perhaps the piece in Lemur News 12 is interesting for you. Ucucha 16:52, 7 August 2010 (UTC)

Audit an edit of an Olympic FL

Can someone just check that the edits I made to List of 2008 Summer Olympics medal winners are okay. I came across some information while researching for a different article, and this one was never updated. Edits are here. Not sure if the footnote needs expanding or not. Matthewedwards :  Chat  21:27, 8 August 2010 (UTC)

Looks fine to me. Rambo's Revenge (talk) 22:42, 8 August 2010 (UTC)

Yep, looks good from my end. Dabomb87 (talk) 23:04, 8 August 2010 (UTC)

Articles for deletion

A featured list has been nominated for deletion here, on the basis that it may be a content fork. In all probability, three further lists will be nominated imminently. Regards, --WFC-- 16:23, 12 August 2010 (UTC)

Thanks, I've watchlisted the AfD, and will update WP:FL and WP:FFL accordingly if they are deleted. Dabomb87 (talk) 16:30, 12 August 2010 (UTC)

Making size a criterion

Please see Wikipedia talk:Featured list criteria#Should size be a criterion?. Dabomb87 (talk) 00:55, 13 August 2010 (UTC)

Query on Nominating

I accidentally put Glee (season 1) into FA application status without doing a peer review first, and in the process learned that despite the prose included in the article, it's still considered a "list" article instead. So I now have a big "former featured article candidate" tag on the talk page. I've now conducted a peer review. That is completed and concerns addressed there. I'm holding until the peer review is archived (closed moments ago). I'm going to suggest it for FL (co-nominating with Frickative, who found much of the information; we've worked together to get the article ready with the peer review and such).

So...what do I do with the big ArticleHistory thing (generating "former candidate")? Do I delete that template and start over with FL, or do I leave it in with the FL below it? CycloneGU (talk) 02:59, 14 August 2010 (UTC)

Leave it be, and add {{subst:FLC}} to the talk page. After the FLC closes-either way- a bot will handle the article history. Courcelles 03:07, 14 August 2010 (UTC)

Alrighty, thanks. =) CycloneGU (talk) 03:10, 14 August 2010 (UTC)

Renamed FL candidate

Hi. The former candidate of the submissions Archive 1 and Archive 2 has been renamed to List of conventional hydroelectric power stations some time back. Shouldn't the archives be renamed too? The subject of the lists is still the same. Regards. Rehman⁽⁺⁾ 02:45, 17 August 2010 (UTC)

We usually don't move the archives if the page is renamed after the FLCs have concluded. Dabomb87 (talk) 03:42, 17 August 2010 (UTC)

I see. Thanks for the reply. Kind regards. Rehman⁽⁺⁾ 03:45, 17 August 2010 (UTC)

Wikipedia:Village pump (policy)#RFC: Inclusion criteria of "List of X"

FLC regulars may be interested in this ongoing RFC at the policy village pump. Goodraise 09:57, 23 August 2010 (UTC)

Wikipedia:Featured list candidates/Contest

I miss this contest. May be please do a third addition of the contest?! I am willing to be the director of the contest if this goes through. :D --K. Annoyomous (talk) 11:19, 25 August 2010 (UTC)

We already have a contest for all kinds of reviewed content: WP:CUP. Dabomb87 (talk) 12:42, 25 August 2010 (UTC)

But WikiCup is different from the FLC Contest. In the FLC Contest, contestants will attempt to make lists that they are not familiar with into FLs. The user(s) that reach the amount of FLs needed is the winner. More details are on the page. --K. Annoyomous (talk) 20:28, 25 August 2010 (UTC)

I had intended to run "FLCon III: Quest to beat the rest" a year ago, but I never got around to it. It would be great to see a new one held, but I don't know if we'd have enough entrants... -- Scorpion⁰⁴²² 23:36, 29 August 2010 (UTC)

Couldn't we just do what we did last time, where we sent invitations to FL nominators, asking if they would like to participate? --K. Annoyomous (talk) 23:43, 29 August 2010 (UTC)

Sounds as if it could be fun, speaking as someone whose FL's are all in heavily represented topics. Courcelles 23:57, 29 August 2010 (UTC)

I have no problem with it, as long as someone else is doing the coordinating. Dabomb87 (talk) 02:20, 30 August 2010 (UTC)

I can help with coordination. But I probably won't compete this time.—Chris!_c/t 02:34, 30 August 2010 (UTC)

I think we should expand the contest further: have more contestant and require them to write more lists.—Chris!_c/t 02:39, 30 August 2010 (UTC)

We tried to get a variety of users who didn't have a lot of FL experience involved last time, and most of them didn't finish one list. As for the running of it, I don't know if I'll have time, because school returns in 2 weeks, and I'll be rather busy. -- Scorpion⁰⁴²² 03:10, 30 August 2010 (UTC)

• I'd love to see this happen and get going, but the noted point that we would need to get non-FLC regulars involved would be a challenge, one that may make a revival not worth the hassle. Wizardman _{Operation Big Bear} 00:51, 15 September 2010 (UTC)

• I'd certainly join in if this happened. Staxringold _talk^contribs 02:53, 15 September 2010 (UTC)

RfC on FL criterion 3b

Please see Wikipedia talk:Featured list criteria#RfC - 3.b review. Dabomb87 (talk) 15:11, 6 September 2010 (UTC)

I really hope some more regulars become involved, because the main discussion is between three users I've never heard of before, one of whom concluded that a lack of discussion was sufficient consensus to remove a criterion that had been added after a very lengthy discussion and debating process. -- Scorpion⁰⁴²² 23:04, 15 September 2010 (UTC)

To be fair, most of the users commenting there have been quite active at FLC for a while now, and have a good number of FLs among them. I do agree, though, that more discussion should take place before we change the criteria. I'm one of the regulars guilty of not participating in discussion (been busy IRL and with other wiki stuff), and will comment there in the coming days. Dabomb87 (talk) 23:17, 15 September 2010 (UTC)

Per WP:CONSENSUS he was entirely justified in doing that. If no-one retorts for a week then consensus has been established, whether it's between two or more editors. It is an RfC after all, not a secret discussion on a hidden userpage. Sandman888 (talk) 06:30, 16 September 2010 (UTC)

Well, you could have taken the time to notify users involved in the original discussion to give their opinions. I'm not active these days, I barely keep track of FLC anymore (sadly), so the only reason I even noticed the rfc is because I was curious about what was being said about the above contest discussion. -- Scorpion0422 II (Talk) 12:09, 16 September 2010 (UTC)

Bollocks. I was not aware of where and when and if at all, the original discussion took place. Even if I was aware I have no obligation to notify "the Elders". Besides, if you do not frequent the FLC anymore, and thus unaware of how thing works now, why should you be given special treatment? (oh right, because you are, "a FLC regular" who hasnt heard of the lowly editors currently involved in the RfC) Sandman888 (talk) 12:25, 16 September 2010 (UTC)

A civility reminder. Thanks. — KV5 • Talk • 13:00, 16 September 2010 (UTC)

You're right, why should you have to notify anyone who might oppose you? You just want to slip it through as quietly as possible. And for what it's worth, I was the one who proposed 3b. You're certainly not giving yourself any credibility when you revealed that you didn't even bother to look back at prior discussions. -- Scorpion0422 II (Talk) 18:40, 16 September 2010 (UTC)

RfC on inclusion criteria for lists

Wikipedia:Requests for comment/Inclusion criteria for Lists. People may be aware of this already, but I was not and haven't noticed (m)any FLC regulars there. In a quick skim it seems to attempt to address issues such as lists notability etc. such as whether "List of X by Y" should require "X by Y" to be notable and when the "List of" title is appropriate. So many RfCs, so little time.... Rambo's Revenge (talk) 23:55, 17 September 2010 (UTC)

Quick question, did this appear within the FL project at any point? The Rambling Man (talk) 00:00, 18 September 2010 (UTC)

The project was not notified if that's what you mean. I just noticed a link to it in the other RfC on criteria. Rambo's Revenge (talk) 00:04, 18 September 2010 (UTC)

Okay, fascinating fact, the overall project is debating what should be in a list, yet the portion of the project determining the best of such hasn't been included in the debate? Is that a reasonable synopsis? The Rambling Man (talk) 00:07, 18 September 2010 (UTC)

Oh no Rambling Man, why should we have to be notified of list-related rfcs? I mean, it's not like we have experience working on lists or anything. We're just a bunch of "elders" who think we own the process. -- Scorpion⁰⁴²² 00:11, 18 September 2010 (UTC)

(edit conflict) Yes. That's why I thought it was something that the "featured list community" might like brought to their attention. Oh well at least we can participate in a poll on suggestions none of us had a say in. And to think I sometimes have doubts about Wikipedia... Rambo's Revenge (talk) 00:12, 18 September 2010 (UTC)

[2] appears to have been a notification. I will, however, note that this RFC is due to a few users who are trying to enforced stricter requirements than FL or even SAL allows for --MASEM (t) 00:12, 18 September 2010 (UTC)

Apologies for the lack of good faith. I must have been something that passed over on my watchlist by a thread about reviving the FL Contest. Rambo's Revenge (talk) 00:17, 18 September 2010 (UTC)

Hang on, what's going on here? I may have been flippant but since when did we have an RFC about "inclusion criteria for lists" without involving the FLC community? The Rambling Man (talk)

We didn't. It is currently ongoing. I thought we hadn't been notified about it but, as Masem points out, we had. Glad to see I wasn't the only one that hadn't noticed. Rambo's Revenge (talk) 00:22, 18 September 2010 (UTC)

Ok, it looks pretty "advanced", I don't have time to read through it all. Can we somehow note that this is all being done (perhaps) outside our regular process? The Rambling Man (talk) 00:24, 18 September 2010 (UTC)

Let me quickly summarize: The majority/consensus position is that given "List of X", there should be some aspect of X that is a notable topic; that doesn't fully describe when lists are included (there's clearly other factors involved), but the reason the RFC was started it because a few users are trying to insist that "List of X" itself must be a notable topic for a list to be included, a position we think has been rejected by consensus. --MASEM (t) 00:28, 18 September 2010 (UTC)

Wild, that sounds like nothing whatsoever to do with WP:WIAFL. We strive for awesome lists, we're not here to determine if a list is ready to be deleted or not, sorry. The Rambling Man (talk) 00:31, 18 September 2010 (UTC)

Yes, personally, with where the consensus sits right not, WIAFL is untouched; most FL are examples of that consensus at work, so... It's similar to the question if FA/GA should deal with notability issues or not. --MASEM (t) 00:55, 18 September 2010 (UTC)

Maximum length of FL

Is there a maximum allowed number of entries in a featured list? I am currently improving List of National Treasures of Japan (writings) and wonder if I'll have to split this list in parts or if it can stay as it is (which I'd prefer). There are 223 entries and eventually all the tables in the list should look something like this table. bamse (talk) 22:51, 20 September 2010 (UTC)

I would much prefer one list with all relevant information than spreading it thin over multiple pages. The size of this article is not too large. Reywas92^Talk 22:55, 20 September 2010 (UTC)

I'm concerned about this one. It's nowhere near finished, and it is already 133K long, and loads rather slowly. Might be better to consider how to make it into two lists. Courcelles 22:59, 20 September 2010 (UTC)

Agreeing partially with Courcelles, it's really a size issue versus the number of entries. For example, List of members of the Baseball Hall of Fame has 289 entries. However, they don't have images for every entry and there's barely any prose in the tables, just a simple short data set. — KV5 • Talk • 00:36, 21 September 2010 (UTC)

The problem is, that splitting it into two lists would be artificial and I have no idea how to split or what to call the resulting articles. If I have to split, I'd rather spit it in eight lists (following the eight sections in the article). However, I think that there is some value in having all of these writings together in one single list. It does not load particularly slowly on my computer. bamse (talk) 21:55, 21 September 2010 (UTC)

If anything, once the list is done, pick only the longest category and move that to a separate page (either the first or the second) and leave the rest here in the main article (something like this). Nergaal (talk) 05:47, 22 September 2010 (UTC)

Related question

I'm thinking about doing some pretty drastic work on this list, along these lines. The problem is that if I do work along those lines, the list in its entirety could easily hit 400kb. Presumably that would be far too long, which throws up a few questions: 1. Is a revamp along those lines a good idea at all? 2. If so, will I need to break that list into a few smaller ones? 3. If so, would I then need to duplicate the information in the overall tables (by race, by host nation) that many times? Thanks in advance, —WFC— 12:36, 1 October 2010 (UTC)

User talk:The Rambling Man/FLC things to check

As many of you may be aware, I'm an FL director here, and while I promote a few lists each month (my diligent colleague Dabomb87 does the lion's share of that onerous work), I do my best to review every list that passes through here. One thing I find is that there are many common "flaws" that I pick out in many of the FLCs, and I've decided to create a checklist, a guide, a "things to check" page in my userspace. The purpose of this is not to create a way of "walking through" FLC for that easy bronze star in ten days, more to allow reviews to be conducted at a level which improves the quality of the information we're providing and to avoid calls for peer review, rather than taking up valuable review time with the many technical failings of some nominations. My purpose for posting here is just to let the community know that (a) I'm doing this and (b) to encourage editors to contribute to the guide to areas which they're familiar with. Hit the link in the section title and help improve our nominations! Cheers, The Rambling Man (talk) 17:24, 21 September 2010 (UTC)

I'll be happy to contribute; I think this is a great idea. — KV5 • Talk • 17:35, 21 September 2010 (UTC)

I had a similar idea back in the days when I was reviewing more than I am now. I started two pages, User:Goodraise/FLC checklist and User:Goodraise/Referencing web pages, but kinda forgot about them before I could expand them into something usable. Feel free to use any part of them. Goodraise 19:01, 21 September 2010 (UTC)

Sounds good Goodraise, thanks for the info. The Rambling Man (talk) 21:38, 21 September 2010 (UTC)

Heh. You're either admirably polite and/or you have a sense of sarcastic humor that has so far escaped me. Whatever it is. I'll come by eventually to give some actual input, but I can't tell when that'll be because I'll have even less time to edit over the next month or so. :( Anyway. What you've got there already looks quite promising. Keep it up. Goodraise 12:33, 23 September 2010 (UTC)

Actually I think it's going quite well too. I'd appreciate more input and suggestions on topics to discuss, and any feedback on the work in progress would be good too. I'm wondering if I need to explicitly enumerate the "flaws" so I can easily refer to them (e.g. P1 would be a failure to mean Prose point 1...) — any thoughts from anyone? The Rambling Man (talk) 13:18, 23 September 2010 (UTC)

I think that would be a good idea; DYK does that and often I see "A5" or "G7" or whatever being tossed about in hook noms. — KV5 • Talk • 13:27, 23 September 2010 (UTC)

I've actually tried to come up with a numeration scheme for the list I had intended to create, with little success. It's just too much of an effort with the list being fairly long and often changing. My suggestion would be to split the checklist items into two groups: one containing more general advice like "Read WP:LEAD! It needs to adequately summarise the list!" and another containing only crystal clear specifics like "Non-English references should use the language parameter." That way you can say things like "X checklist items failed", but won't have to worry about numerations because the danger of misunderstandings happening is minimal. Goodraise 13:47, 23 September 2010 (UTC)

Yes, I was concerned, particularly at the moment, that keeping the enumerations aligned and consistent would be challenging. I like the idea of general vs specific "failures" mind you. The Rambling Man (talk) 13:56, 23 September 2010 (UTC)

Would it be useful to give a few recent examples of particular FLs in frequent fields e.g. discographies, awards, bibliographies? Every so often someone comes along and says "I've based this FLC on [insert name of FL promoted 15 years ago...] and I think it's as good as that one", when in fact time and standards have moved on. Bencherlite^Talk 15:07, 23 September 2010 (UTC)

Good point, but I'd go even farther: Even lists promoted last month would not necessarily be promoted now, simply because the review process isn't perfect. Especially new nominators need to be made aware that not only standards rise, but also that being "as good as" isn't good enough. Current FLs shouldn't be seen as cookie cutters, but as markers of the level that FLCs should strive to surpass. Goodraise 15:23, 23 September 2010 (UTC)

Entirely agree. It always amuses / infuriates (in a nice way!) me when TRM finds something to nitpick in a list that I've taken from a list of mine that he supported two weeks previously! There was an incident at FLC earlier in the year when a couple of reviewers, including me, thought that the generic leads to a series of FLCs could be improved, and the nominator's response (before withdrawing completely from FLC with the series incomplete) was to say that the leads had been thought good enough in the past, so why were we only making comments now? Well, the reviewers in question hadn't been involved in the earlier reviews, but that doesn't mean that later reviewers are somehow debarred from picking up points that perhaps others have missed. Bencherlite^Talk 15:30, 23 September 2010 (UTC)

I agree as well. Although WP:OTHERSTUFFEXISTS is mainly about arguments to avoid at WP:AFD, the same principle could apply here. The Rambling Man (talk) 16:14, 23 September 2010 (UTC)

That's a really good point, Bencherlite; I can't tell you how many times I had to go back and retroactively make changes in featured lists that had just passed when I was working on the series of Silver Slugger Award lists. — KV5 • Talk • 16:28, 23 September 2010 (UTC)

Agreed. When I do reviews of lists in a series, I remind the nominator to go back and fix the issues raised for the current FLC in previously promoted lists as well. Dabomb87 (talk) 21:35, 23 September 2010 (UTC)

Any way a list of FLs could be made sorted by date of promotion, or even better, in topics by date of promotion? Arsenikk ^(talk) 22:12, 23 September 2010 (UTC)

It's not by topic but Wikipedia:Featured lists promoted in 2010 then Wikipedia:Featured lists promoted in 2009 give reverse chrono. Rambo's Revenge (talk) 22:18, 23 September 2010 (UTC)

Update

Okay folks, thanks to all of you who contributed to my mini-project. I've added a few more points in there. I'd appreciate some reviews, any further missing "essentials" and then we need to work out a nice way of introducing this information to our "clients"! The Rambling Man (talk) 16:18, 27 September 2010 (UTC)

Limiting the time of noms?

I noticed that some of the nominations tend to stay on the bottom of the FLC page for a very long amount of time (i.e. over a week) and also on the Wikipedia:Featured list candidates/backlog/items shortlist; meanwhile, there are some lists that aren't even for 24h on the latter before they get closed. Can we have some rules to keep it fair for all the articles so lists don't get screwed up over some selected ones? For example, at least have a list on the shortlist for a minimum of x days, but not more than y? Nergaal (talk) 19:50, 8 October 2010 (UTC)

This doesn't sound feasible. It is all subjective. If a list is old but is being worked on and progress is being made why restart it or archive it if it looks like it will be passible in a few days. Whereas what is the point of keeping a stale nomination open longer even though it isn't going anywhere and no-one is comments. The fact is, as much as we would all like it to be, not every FLC attracts the same amount of attention. So we have to subjective in what consensus to promote is (things have changed there because I'm fairly sure it used to be 3 supports or more way back). The directors have to decide what is workable, what is actionable and what is going nowhere. These aren't objective things we can make rules about, at least in my eyes. Rambo's Revenge (talk) 20:01, 8 October 2010 (UTC)

No list is obligated an allotted amount of time on the FLC backlog lists (both the box on WP:FLC and in the FLC closure log); I (I won't speak for TRM) update those lists out of courtesy and for the reviewers' convenience. Yes, that means some lists will get "screwed" because they were on the shortlists for less time than others, but that's just how it goes. The backlog shortlists are not the only way to find nominations needing reviews. TRM and I do our best to ensure that every FLC has a chance to receive an adequate number of reviews, but some things are just out of our control (such as the fact that certain lists will receive more attention than others). I don't give any weight to the opinion that an FLC's closure is "invalid" because it was put on the shortlists for less than a certain amount of time, if at all. Dabomb87 (talk) 21:23, 8 October 2010 (UTC)

Hey. From a purely human perspective, both Dabomb87 and I do our best to give every single FLC the time it deserves. That is inherently subjective, and the duration of "patience" we have (and I am speaking for DB7 here, so he may correct me) is directly related with the relative "success" of the FLC. Now, the relative "success" is related, not only to the number of "support" comments, but to the complete and satisfactory resolution of outstanding issues. It also relates to the compliance with the criteria, and the over-riding issue – is the list sufficient to be part of Wikipedia's finest work? DB7 and I work differently but to the same goal. We attempt to complement one another in having the discretion to review and !vote in FLCs. We communicate with each other to ensure that lists don't get lost in the "wilderness". But, to address the original issue, no, I don't believe we need to objectively limit the time of nominations. Each nomination has its own lifecycle. Some will pass before ten days are up (although they'll wait until ten days have passed). Some will need recycling, and some will fail after a month, maybe more. But I don't get the idea of an objective cut-off. It's a solution for a problem that doesn't really exist. When we get to a backlog of 20 FLCs, let me know... The Rambling Man (talk) 23:17, 8 October 2010 (UTC)

3b FLRCs needing more opinions

Resolved

 – The FLRCs have been closed.

Hi all. As you probably know, ongoing discussion over FL criterion 3b continues to inject uncertainty and confusion into several situations concerning lists. Two current FLs that are currently at FLRC have been caught in this sticky situation, and we need as many opinions as possible for TRM or I to gauge consensus on the issue; these FLRCs will probably serve as precedents down the road, as well. When you get the time, please comment at:

• Wikipedia:Featured list removal candidates/List of mergers and acquisitions by Condé Nast/archive1
• Wikipedia:Featured list removal candidates/Jessica Mauboy discography/archive1

Thanks, Dabomb87 (talk) 18:15, 11 October 2010 (UTC)

I've closed both FLRCs now. Thanks to everyone who put in their two cents! Dabomb87 (talk) 16:09, 16 October 2010 (UTC)

Question about sourcing

Hello, I'm currently unfamiliar with the FL criteria and was wondering how far we need to go with sourcing. Currently, I'm attempting to get List of UFC events up to FL status and have a working improvement going at User:Paralympiakos/Sandbox 1, where I've introduced what I believe to be a satisfactory lead section with sourcing. However, as this is a list of events, I'm wondering if each event needs some form of sourcing. I've taken a look at other current FLs and many seem to be missing this style of sourcing, so I'm wondering if the changes at my sandbox are needed and if I should continue with the sourcing in this manner. Thanks. Paralympiakos (talk) 14:35, 19 October 2010 (UTC)

When in doubt, source. In general, if the lead simply repeats a sourced fact from the table, then there is no need to repeat the source but it will often be useful to do so for claims that might be challenged, or for quotations. Oh, and while you're treating this as an informal peer review location (!) (a) don't start "this is a list of ..."; (b) put your tables in chronological order, not reverse chronological order i.e. first to last, not latest to earliest. User:The Rambling Man/FLC things to check is worth a read. Bencherlite^Talk 14:41, 19 October 2010 (UTC)

In my experience and work here, with a list article there's usually a central list (as you have), which then receives a general reference or two at the bottom. Basically saying, "This is where the data for the list came from". And then any piece of data in the list that isn't from those general references gets a specific citation. I think it's incorrect to say that every row needs to be individually cited; at that point it's becoming less of a list, IMO. There's no reference tying it together, basically. For example, if I had a list of governors, and decided just to post references saying "this one served from day 1 to day 5" and another one "served from day 6 to day 10", but I have no reference saying "these were the governors who served from day 1 to day 10" it's kind of not a unified list, it's just individual chunks that have no relation to each other. So, in other words, I say find a general source (or 2 or 3 or however many is needed) and then just cite the bits of information that either fall outside those sources, or are extraordinary enough to need individual citation anyway. --Golbez (talk) 14:42, 19 October 2010 (UTC)

I'm sort of in the middle. I prefer to use a combination of general and specific references. For example, in List of Gold Glove Award winners at first base, the winners of the award are verified by the general reference, but the individual rows contain further information that is verified by each line's inline citation. — KV5 • Talk • 14:54, 19 October 2010 (UTC)

Ok, well at the moment, I think I have a link at the bottom that basically says, as you put it, "this is where the data for the list came from", but that doesn't cover the attendance figures for each event, which is what I've started to source on my sandbox. I'll also point out that I didn't mean for this to become a peer review of sorts, I'm just asking for a quick pointer so that I wasn't wasting my time. In either of your opinions, considering that Golbez' point covers the event, but not the attendance, should I continue to source each event's attendance? Thanks. Paralympiakos (talk) 14:54, 19 October 2010 (UTC)

Or, put another way, can you include unsourced information in a featured list? Put like that, the answer should be obvious: "No". If you want the attendance figures, they've got to be sourced reliably, or it'll be a quick-fail at FLC. Bencherlite^Talk 14:58, 19 October 2010 (UTC)

If the attendance isn't handled by a general ref, then yes it needs to be individually sourced. Bencherlite put it well, though bluntly. :) --Golbez (talk) 15:05, 19 October 2010 (UTC)

Blunt, yes, but I'm glad as it actually helped me to see what a silly question this was. Thanks everyone for the responses. Paralympiakos (talk) 15:09, 19 October 2010 (UTC)

No problem. Ping me if you go to peer review before FLC, and I'll take a look there for you. Blunterlite^Talk 15:23, 19 October 2010 (UTC)

Sorry, I've only just got the chance to read this. I've slightly altered my last message to clarify. Also, thank you very much for the PR offer. I'll keep that in mind. Paralympiakos (talk) 16:20, 19 October 2010 (UTC)

Former FL possible re-promote?

Hey everyone. List of first-class cricket quadruple centuries was nominated for demotion (by me!) about 15 months ago, based mainly on 3b issues. I think, with some considerable polishing, it's eight entries would now no longer fall foul of 3b. Assuming all the MOS/[citation needed]/other bits are fixed, would the community give this former featured list another chance? The Rambling Man (talk) 17:52, 19 October 2010 (UTC)

Eight entries, I count ten. It's still a bit dodgy especially as it kind of overlaps List_of_first-class_cricket_records#Highest_individual_score at that size. Personally I'd prefer a list of the 150+ scores of over 300 as although it'll take some work I think it is do-able. Rambo's Revenge (talk) 18:04, 19 October 2010 (UTC)

Aha, yes, ten, 8 different chaps. I wondered if, given that it's such a significantly high score, it would qualify as standalone. The Rambling Man (talk) 18:28, 19 October 2010 (UTC)

• Do quadruple centuries get hefty individual coverage above and beyond similarly amazing scores (in other words does 400 get significantly more coverage than 399)? I would say that that's the justification for why, for example, 500 home run club exists alongside List of top 500 Major League Baseball home run hitters. Yes it's just a subset of the larger list, but it is notable enough to standalone (as you're asking/implying in this most recent post). Staxringold _talk^contribs 19:59, 19 October 2010 (UTC)

Review request

Hi all. If someone has the time, can they take a look at Wikipedia:Featured list candidates/List of awards and nominations received by Drake/archive2? I've already archived it once because it received insufficient reviews, and I would hate to do it again (it's just demoralizing for the nominator). Thanks, Dabomb87 (talk) 14:21, 19 October 2010 (UTC)

I've been wondering this for a while now. Why are you closing nominations like that at all? What's the harm in leaving them open until they get the amount of reviews necessary? As far as I can remember, I've never found the time to review all active nominations. When I review, I have to choose. Usually, I'll start from the bottom and work my way up, skipping those nominations with sufficient reviews or numerous open issues. I'm doing that because I figure that way the process will get the most out of my rare reviews. My point being, some kinds of nominations just (for reasons that elude me) don't attract enough attention during the time allotted. That won't usually change by forcing them back up to the top of the list. Goodraise 08:23, 20 October 2010 (UTC)

In my experience, it does usually result in more interest. This seems to be a one-off. The main reason for removing stale nominations is to ensure we don't get a backlog. The Rambling Man (talk) 14:19, 20 October 2010 (UTC)

Okay, if moving nominations back up results in more interest, then I can understand why you'd "restart" them. Your reason for removing stale nominations, on the other hand, I find less convincing. Having a backlog is a good thing. Having an empty backlog is better than having a full backlog. Removing nominations for not having received sufficient attention is about the same as striking a task from a to-do list without actually having done it. One might argue, it doesn't shorten the backlog, it just makes some of the items invisible. Goodraise 18:28, 20 October 2010 (UTC)

Well so far so good, with this one exception, which has now attracted considerable review. Thanks to everyone for your interest. The Rambling Man (talk) 11:46, 21 October 2010 (UTC)

Manual of Style Issues

At the request of User:The Rambling Man I have opened this thread to alert all contributors to a recent change in the WP:MOS. Please find my concerns with every single FL candidate on the list below as well as some background information.

Background

For too long many readers, users and developers have criticised Wikipedia for its use of over-complicated HTML and CSS codes. These all came to ahead with internatioanl wikipedia projects who in turn begun to realise that there were many things that needed addressing. En-Wiki is following suit. For too long our obsession with overcomplicated formatting and deviated styles has clouded the judgement of what makes a good article and ultimately we have failed those who are less able than ourselves. By this, I am referring to those hard of sight, with visual impairment or those with no sight at all. An estimated 25% of articles are deeemed accessible (see below).

Three sins

• The current font size we use on wikipedia is deemed too small by HTML developers to be 'accessible' (easy to read for everyone). However wikipedia constantly makes it worse by using <small> </small>
• Our wikitables (tables) are not complient with basic web-based accessibility. i.e. we give preference to columns by making the headers bold and the background darker but not too rows.
• We overuse color. Color is used in many tables to signify information but for those who are colorblind a lot of colors simply show as the the same thing.
• The overiding issue that we're all guilty of is thinking "this looks good to me, it must look good to others too".

So what can we do about it?

Well the answer is simple. Talking a leap into the future by following international wikipedia, we set up WP:ACCESS (a.k.a Project Accessibility) which is the newest part of the Manual of Style. It aims to resolve the three common issues above as well as align the rest of wikipedia to improve quality and accessibility of articles to somewhere above 50% (my personal hope).

Featured Lists

Basically the problem is that these decisions were taken at central level by authority much higher up than regular editors. The result it that then the burden of picking up the pieces was left to regular editors like myself. The problem is that most of the FL candidates do not satisfy the new MOS standards and focus instead on standards set on previous FL candidates. All articles will need to comply with the MOS changes and so I would recommend that all nominations are frozen until we can get a grip on the situation. Essentially the issue is that users are not aware of how tables should be correctly formatted. Now that is probably the fault of those who made the decision to change this but that's the past so people like myself are trying to fix things. WP:Wikitable is the page all about tables and explains how they should be formatted. For discographies there are specific guidlelines at WP:DISCOGSTYLE. Now how we precede is I believe upto the FL directors and nominators of articles. But I seriously believe that NONE of the nominated articles should be able to pass FL status because they are defaulting on such an important part of MoS. -- Lil_℧niquℇ №1 | talk2me 21:31, 19 October 2010 (UTC)

Seems like you have "four sins", not the three advertised. But more importantly, WP:Wikitable is not MOS, it's a help page. Can you point to the section in MOS that these lists are failing? The Rambling Man (talk) 21:34, 19 October 2010 (UTC)

WP:ACCESS#Data tables is the specific part of the MOS I'm referring to. -- Lil_℧niquℇ №1 | talk2me 22:05, 19 October 2010 (UTC)

And perhaps you could also explain why you're requiring adherence to WP:DISCOGSTYLE when it has {{proposal}} at the top of it? (Oh, and I think you mean "proceed", not "precede".) And I really have no idea what "Basically the problem is that these decisions were taken at central level by authority much higher up than regular editors" is meant to mean – who? When? Bencherlite^Talk 21:53, 19 October 2010 (UTC)

To be honest I dont even know who took the decisions to update WP:Wikitable for example I just know it happened. I was pointing out the adherance to WP:DISCOGSTYLE because it is per the talkpage the new agreed format for discographies. It has been updated literally within days and there is opportunity to still influence it interms of things like how to attribute featured perforformers etc. But the general principles are agreed upon.

And please, don't preach to the members of FLC about the general principles of WP:ACCESS, it's clear they understand it. What they don't understand is this recent blanket oppose on something which you've so far failed to explain other than point to a help page, not a part of the MOS. The Rambling Man (talk) 21:55, 19 October 2010 (UTC)

I'm sorry if its come across like that? I'm generally trying to be informative as possible. So many people don't know about the changes being made. WP:ACCESS is in itself a part of the MOS it has specific sections on headings, tables etc explaining how they are made accessible. I am really trying to be as helpful as possible by providing links, examples etc. I was not preaching about the principles of Access but merely pointing out that calling it an 'dreamed idealism' is not an assumption of good faith. It is an implemented part of MOS which I joined after its creation. I am merely trying to facilitate others in understanding what changes should be made and why. -- Lil_℧niquℇ №1 | talk2me 22:05, 19 October 2010 (UTC)

As has been pointed out in various places, WP:DISCOGSTYLE is (1) a proposal, (2) a project guideline and (3) not part of WP:MOS. Cheers. The Rambling Man (talk) 22:07, 19 October 2010 (UTC)

But WP:ACCESS is a part of the Manual of Style and it clearly shows how tables should be formatted. -- Lil_℧niquℇ №1 | talk2me 22:14, 19 October 2010 (UTC)

If you're sure you know what part of WP:MOS these lists all fail (i.e. without referring to WP:Wiktable or WP:DISCOGSTYLE) then please tell each nominator what they've got wrong and exactly how to fix it, since it's become clear that you're the only one around here who seems to know what's amiss. The Rambling Man (talk) 22:16, 19 October 2010 (UTC)

Ok since we're not having much luck I'm retracting my comments from all the lists I've commented on so far. Instead I'll continue discussing here etc. Ok allow me to demonstrate the issues with my sandbox.... User:Lil-unique1/Sandbox/4. Based on one the FLs I commented on it shows from WP:ACCESS#Data tables the changes that should be made and how they should be made. -- Lil_℧niquℇ №1 | talk2me 22:30, 19 October 2010 (UTC)

I've been down this road before, and the initial result wasn't pretty. I think most FL contributors support any and all efforts to make lists more accessible to our readers, but things will go more smoothly if we introduce and integrate the changes slowly, after making editors aware of the changes. Dabomb87 (talk) 22:37, 19 October 2010 (UTC)

I'm sorry perhaps I was trying to introduce the changes too fast. Its just I thought that I could win the support of FL contributors then the changes would be easily be spilt over to the lower classes of articles. I wasnt aware that for example WP:DISCOGSTYLE had not been finalised. Nor was I aware how little people knew of the changes. -- Lil_℧niquℇ №1 | talk2me 22:39, 19 October 2010 (UTC)

What I said here shares a lot of my views but it is particularly worth noting that where headers are "in the first row or column then it is sufficient to simply use the TH elements without scope."[3] (and !scope= is the thing you are mandating). Doesn't the wikitable syntax automatically use TH elements already[4]. Rambo's Revenge (talk) 22:38, 19 October 2010 (UTC)

(edit conflict) Let me be completely transparent. I accept much of the blame for this, and I apologise. I gave Lil' a hard time over Kelly Rowland discography, because some of us happened to do some accessibility improvements on the tables while it was nominated for FL. Having seen the sort of improvements that can be made, Lil' has been one of the most enthusiastic proponents of improving accessibility within the DISCOG project, and I hope you won't be too upset with the attempt to "spread the word" at current FL nominations. Dabomb is of course right; we won't change anything in a rush, and we don't need to make wholescale changes to the MOS and criteria overnight. I'm glad the issue of accessibility is gaining prominence, and it would be nice to think that it won't be too far in the future that most editors will be trying to make every article as accessible as possible. I'd encourage Lil' and all of us to continue to discuss to what extent we can realistically expect tables (for example) in FL nominations to comply with the sort of proposals you can see at WP:WikiProject Discographies/style. I make no claim to be an expert at anything, but I know some of the issues, and I'm always willing to help if needed. Cheers --RexxS (talk) 23:04, 19 October 2010 (UTC)

@Rambo's Revenge: You are right that the '!' wiki-markup always produces a 'TH' in the HTML output. Nevertheless, we can't guarantee that every screen-reader will treat TH as having the appropriate scope and it is considered best practice to unambiguously specify 'SCOPE='. In addition, until HTML5 deprecates the practice, it is still valid HTML to mark up a 'TD' with scope, and it is semantically correct if the cell contains a value which is both a header and data. These two issues are often only a consideration in more complex tables than we tend to use on Wikipedia. But the real issue is trying to get editors into good habits that mimic best practice. For that reason alone, I'd recommend sticking with the use of '!scope="row/col"' for all headers, as it sets an example that can be copied and re-used by most editors. --RexxS (talk) 23:17, 19 October 2010 (UTC)

(edit conflict) Like I said at you talk page: since you are raising an issue about the core if the table accessibility guidelines it'd best to discuss it at Wikipedia talk:Manual of Style (accessibility)/Data tables tutorial. This technical and complex discussion will needlessly confuse editors, so let's discuss it among ourselves first. And I'll ask the accessibility expert for more explanations about the particular issue you are raising.

"But the real issue is trying to get editors into good habits that mimic best practice." Yes, that's exactly the most important point. We can't possibly ask of editors to know when tables are considered complex or simple. Adding '!scope="row/col"' every time is not causing any harm, so we should aim for consistency. That will make it easier for editors. Kind regards, Dodoïste (talk) 23:22, 19 October 2010 (UTC)

If you folks that follow WP:ACCESS want to get a bot written to do this... fine, so be it. But this mass opposing of FLC's with comments that make no sense to most of us is ridiculous. Especially since these changes result in exactly zero change in the output. This is yet another example of the very few folks who actually care about the MOS making decisions, and then demanding the rest of us jump through their ever-changing hoops. Courcelles 23:37, 19 October 2010 (UTC)

Yup, we're considering a bot to change to '!scope="col"'. But it's unfortunately harder for '!scope="row"' since it has an effect on the output. Maybe standardizing the tables with a template-based table would make it easier: the change would only need to be decided once, and would be applied with consistence throughout every tables. Thus, we wouldn't need to disturb most users any longer. It's definitely an option I'm willing to consider. Yours, Dodoïste (talk) 23:53, 19 October 2010 (UTC)

(edit conflict)"We can't possibly ask of editors to know when tables are considered complex or simple"? – I think perhaps at FLC one should assume a little more competence of the users here. It seems double standards to patronise editors yet demand they incorporate a new syntax they are uncommon to. As for "not causing any harm", I think the fact that people have started demanding changes that make no difference to tables access wise and tonight's debacle have shown that not to be the case. Rambo's Revenge (talk) 23:42, 19 October 2010 (UTC)

I insist, let's continue this discussion at Wikipedia talk:Manual of Style (accessibility)/Data tables tutorial. Please remember that this guideline was reviewed by an accessibility expert. Surely you're not claiming to know best only because you read a WCAG 2.0 guideline. While WCAG 2.0 criteria are fairly straightforward, bringing accessibility among everyday editors is completely different and is a really delicate matter. So let's discuss it at the relevant talk page, with patience. Yours, Dodoïste (talk) 23:53, 19 October 2010 (UTC)

The accessibility expert replied to my mail. I'll detail it further this evening, at Wikipedia talk:Manual of Style (accessibility)/Data tables tutorial. As a summary: it turns out, WCAG 2.0 TECHS, H63 is mistaken on this particular detail. Reliance on the "simple table" criteria is creating various problems, including in assistive technologies. And it doesn't comply to other related WCAG 2.0 guidelines. So, just like I said Rambo's Revenge: this matter is slightly more complicated, and we're doing the right thing. ;-)

It's the second time I've seen something similar. I'll report the mistake to the corresponding working group of the WCAG like I did last time, and start a discussion at their mailing list. Dodoïste (talk) 10:19, 21 October 2010 (UTC)

Okay, perhaps MOS needs to get its own ACCESS house in order before mandating changes across the board. Do the MOS guys do "draft proposals" or do they just change things which then become instant Gospel to projects who use MOS as one of their criteria? The Rambling Man (talk) 10:33, 21 October 2010 (UTC)

The "draft proposal" lasted one month. Again, there is nothing wrong with the guideline at WP:ACCESS, just like the accessibility expert told me. Dodoïste (talk) 10:45, 21 October 2010 (UTC)

As it was clearly going to impact directly on the featured list process, did anyone consider inviting the project to get involved? I might have missed it but it would have seemed courteous, helpful and logical to let those who create the majority of such tables know about the discussion so that, at the very least, there was not such a big surprise waiting (i.e. the blanket opposition of numerous FLCs)... The Rambling Man (talk) 11:06, 21 October 2010 (UTC)

Despite insising I take this discussion to their project the user is now rushing back here dubious results. Forgive me for doubting experts but I'm much more comfortable believing the World Wide Web Consortium than taking your (or some other "expert") word for it. Rambo's Revenge (talk) 12:09, 21 October 2010 (UTC)

Rambling Man is quite correct that notifying all affected projects would have been helpful. There's a lesson to learn for similar future proposals at ACCESS, and I hope you'll accept my apologies that it did not happen this time. The problem is that this proposal was not the usual kind, where current common practice was documented. It was (unusually) a proposal to embed into Wikipedia the best practices taken from the outside world, in particular WCAG, because of the perceived need to improve accessibility on the 'pedia. Unlike normal proposals that have a natural constituency (the articles and projects where the practices already occur), this proposal drew principally on outside sources, thus lacked an obvious group of projects to notify. Nevertheless, I believe that the current guidelines in WP:ACCESS demonstrate a way forward for Wikipedia to more fully embrace the essential requirements of web accessibility – although any suggestions for improving them are always welcome. The task before all of us is ensure that the guidelines are adopted as smoothly as possible across Wikipedia, and this will involve a gradual process of raising awareness among the content-generating projects. Until that occurs, I see no point in adopting them as essential for the featured process, although I know all the participants here will want to encourage nominators to improve the accessibility of their candidate articles wherever possible.

As for H63, it applies to HTML4 and XHTML, but much of its advice will be rendered superfluous if the current draft of HTML5 is adopted, as scope will no longer be a valid attribute of TD. In any case, the purpose of scope is to clarify, and as such, the discussion agreed it was simpler to recommend that editors always specify it in conjunction with the '!' wiki-markup, rather than try to give complex advice explaining where it may be safely omitted. My advice, for what it's worth, is not to worry about it – if you feel that it is not needed in a table you create, then leave it out. But please don't revert an editor who later adds scope in good-faith. After all, it never hurts to specify scope, while its omission has the potential to cause unforeseen problems. --RexxS (talk) 18:05, 21 October 2010 (UTC)

I didnt demand changes I merely pointed out that from my understanding MOS required such changes. When others pointed out that MOS didnt demand change I've retracted my comments and instead posted this thread about whether FLCs should not take WP:ACCESS into account seen that FLs should examplify the best work on wikipedia and the best work should be accessible to others. -- Lil_℧niquℇ №1 | talk2me 23:46, 19 October 2010 (UTC)

List of awards and nominations received by Scissor Sisters

If this list and this list are featured (7 awards and 21 nominations, 9 awards and 20 nominations), then is this list eligible for similar status? The Scissor Sisters list contains 8 awards and 23 nominations. It had featured status previously, but was delisted due to 3B (back when the list contained 6 awards and 18 nominations). Thoughts? I don't want to waste time putting the list through the re-nomination procedure without feedback. Thanks! --Another Believer _(Talk) 19:49, 20 October 2010 (UTC)

I think it's a justifiable standalone list so see no reason for it not to be a reasonable candidate for FLC. But that is just my opinion.... The Rambling Man (talk) 08:02, 21 October 2010 (UTC)

Thank you for your feedback. --Another Believer _(Talk) 15:25, 21 October 2010 (UTC)

Philadelphia Phillies all-time roster

Ok, so my recent giant project, expanding and completing the Philadelphia Phillies all-time roster to generally FLC-like quality, is now complete, in that all of the lists have been finished and moved into mainspace. Staxringold suggested that I ask here (specifically for input from the directors) if these sublists need to go through FLC individually, or if there's some kind of specialized mass process we could go through since they are all nearly identical. Cheers. — KV5 • Talk • 16:57, 22 October 2010 (UTC)

"nearly identical" is troublesome. But I'd suggest, as a very minimum listing the "A" list at FLC, and see how we go. As far as I'm aware, we haven't ever done a mass nomination and I'd rather not go that way, as details will be overlooked. But, as ever, that's just my opinion... The Rambling Man (talk) 17:06, 22 October 2010 (UTC)

I would tend to agree with you; I had anticipated doing this as a long project, one at a time. So, as suggested, I'll stick the A up there and we'll get a roll on. I'd like to have it done by the beginning of the 2011 regular season, if possible (March/April 2011). — KV5 • Talk • 17:13, 22 October 2010 (UTC)

(edit conflict) ::Concur mass nomination for me is a massive no-no. Definately list A first for full FLC term without another nom. As for simultaneous noming the others, I'm still unsure. Talking as someone who as brought/is bringing lots of similar-ish number-one lists at the moment I know it is frustrating to wait the full term for each but new issues do arise and putting them all through I can be pretty certain means people will start skimming the latter ones instead of a proper review. We're short of reviewers as it is and precendent for mass noming will only scare them off (i'd run a mile!). Rambo's Revenge (talk) 17:16, 22 October 2010 (UTC)

(edit conflict)Let's send the A list here, and then re-evaluate. We're talking about 21 lists, so sending these through one-at-a-time is going to take half a year. I'd lean towards one-to-a-nomination, but allowing KV5 some leeway in the number of nominations once we get through one or two and have seen any hopefully major problems worked out of all of them. Courcelles 17:40, 22 October 2010 (UTC)

Sounds like a plan, and about what I expected. Thanks guys. First nom is up. — KV5 • Talk • 17:24, 22 October 2010 (UTC)

• BTW, to make clear, I'm not a crazy rebel with the FLC rules, just an idea. :) Staxringold _talk^contribs 01:11, 23 October 2010 (UTC)

If the mass nomination process works out well, for future reference I would also be interested in submitting content. I believe my 12th and 13th Grammy Awards lists are undergoing the review process, and I have more queued up for FL nomination. All of the lists are similar in structure and format (and even share many of the same references), differing only in lead and table content. Of course, there are plenty of additional Grammy categories left, but I have put off upgrading them due to the lag of just getting all of the completed ones through FLC. I completely understand not encouraging mass nominations, as I believe details could potentially be overlooked. One option could be for a group of knowledgeable and dedicated reviewers to agree to take on the challenge and examine each thoroughly (the benefit being that they could knock a bunch out at once). FLC reviewers already have a lot on their plate, though. Anyways, if mass nominations are ever an option, please let me know. Thanks! --Another Believer _(Talk) 22:47, 23 October 2010 (UTC)

• As an aside, do topics need to be split into so many lists? English football clubs have roughly half as many players as the Phillies, but tend to squeeze theirs into 2 or 3 lists, compared to 21 here. Indeed, Formula One lists all of its 800-odd drivers in one go. Admittedly F1 is an extreme case, but 21 seems extreme too. —WFC— 23:49, 23 October 2010 (UTC)
  • Yes I think it is oversplit. Additionally there is much less point in sortability if it is only within the subset of a single surname letter. What about transcluding smaller sublists into one list (that way they are easier to edit etc.) I first saw this idea here and have implemented into one article I made. Worth considering? Rambo's Revenge (talk) 00:11, 24 October 2010 (UTC)
    • I think that's a good solution for certain types of list. For instance, it's a solution I'll definitely use if I ever get around to revamping List of Formula One Grands Prix into this sort of format, because only one of the sub-pages would need to be edited on a regular basis. But I don't think it would work as well for a list that requires regular updating all over, as a player list does. —WFC— 03:45, 24 October 2010 (UTC)
      • Just now read all of this, and I thought long and hard about how to split these lists before actually doing it. I don't believe that they are oversplit, simply looking at the sheer length of some of them. Other editors have pointed me at much longer featured lists, but many of those get to be TLDR length for me. By doing this in this manner, I tried to keep it all accessible for the readers. As to Rambo's concern about sortability, even if combined into less individual pages, the tables themselves would not be combined into single lists (for example, if I made a list that is A through D, there would be four lists under four separate level-two headers, not one list of 400-odd players). So there's no added utility there. Beyond that, you would lose information from each lead in combining, because it's nearly impossible, in the four to five paragraphs of said lead, to discuss all of the elements of the list in such a way to give an adequate summary, since that's what the lead is. In short, I don't think that they ought to be combined. — KV5 • Talk • 19:36, 25 October 2010 (UTC)

Multiple wikilinking of terms in sortable lists

I'm sure there have been discussions about this before but I can't remember where or find them in the archives but I'd appreciate some guidance or pointers to a guideline. In a sortable list, if terms are wikilinked on 1st occurrence should they be linked again so that if a reader resorts the list the 1st occurrence may no longer be wikilinked? The example I'm working on is List of churches preserved by the Churches Conservation Trust in South West England (which I hope will be heading for FLC soon) & a copy editor has started to remove the multiple wikilinks of nave, chancel etc leaving only those in the notes section of the first entry. If the list is sorted by county or listed building grade etc these are no longer in the first entry. Which approach is considered best - multiple wikilinks or links only in the first entry as the list is first displayed? Is there a guideline anywhere as I'm sure other sortable lists must have this problem?— Rod ^talk 19:25, 25 October 2010 (UTC)

Tables are a listed exception to WP:OVERLINK because of this problem. See WP:REPEATLINK. Link each occurrence. — KV5 • Talk • 19:27, 25 October 2010 (UTC)

WP:CUP & 1994 College Baseball All-America Team

Is there any chance that 1994 College Baseball All-America Team can be fully reviewed and closed before the end of the month. I am competing in the WP:CUP and although the race has been well-decided, I am trying to post the best total that I can.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 04:16, 29 October 2010 (UTC)

Criteria RfC

I noticed this the other day. In my opinion the change is fine and I just wanted to check with the directors this was okay. I didn't want to post at FL? as that would just reset the 30 day closing period of an RfC which died a while ago. I think consensus was to leave it and move on. Rambo's Revenge (talk) 13:04, 1 November 2010 (UTC)

Mark issue for discussion

Sometimes during a review of a FLC, I run into a potential issue with the list in question but am not sure how serious the problem is. In these cases I would like to get opinions of other reviewers. Is there an established way for marking this issue on the nomination page as "looking for other opinion"? bamse (talk) 23:40, 2 November 2010 (UTC)

Just leave a note here; many FLC regulars watch this page and are usually happy to lend their 2 cents/pence when asked. Dabomb87 (talk) 01:41, 4 November 2010 (UTC)

OK. Just thought that a prominent mark on the nomination page might also involve reviewers who are not watching this page and at the same time would not bother people watching this page (but only those that are actually having a look at the article). bamse (talk) 02:17, 4 November 2010 (UTC)

Opinion from reviewers

Is List of World Heritage Sites in Cuba too short? Grsz¹¹ 22:44, 3 November 2010 (UTC)

Not too short for my taste. bamse (talk) 23:08, 3 November 2010 (UTC)

It's on the edge. Usually I ballpark it as needing ten items, but the tentative items should put it over so I think it's fine. Nomader ^(Talk) 01:56, 4 November 2010 (UTC)

Accessibility and its changes to tables

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

All, some ongoing discussions have resulted changes to some existing Featured Lists have resulted in style differences. Those lists include Rihanna discography for instance. Please note the following changes:

1. Bold captions above each table explaining what the table following the caption contains.
2. Bolding of Single titles.
3. Moving the year from the first column to not-the-first column.

It may be instructive to see the version before these changes.

While this seems to currently only impact discography FL/FLCs, we need to be aware that this kind of change is expected of us (via MOS/ACCESS) in all lists. I would appreciate input from the FL community on this. The Rambling Man (talk) 18:37, 4 November 2010 (UTC)

From what I can see, aren't the bold captions that lead each table generally redundant to our section headers? Also, why should chronological lists not be listed year-first? Or am I misunderstanding? — KV5 • Talk • 18:59, 4 November 2010 (UTC)

The detailed page about these changes is the accessibility data tables tutorial.

These were explained in the previous discussion, I will provide links to them. This is also a reason why I wanted to do this announcement myself, with some useful explanations. Oh, and the second statement is wrong. Despite several explanations, The Rambling Man does not understand that the bolding itself is useless, it is only a side effect of making row headers using "! scope="row" |". Dodoïste (talk) 19:13, 4 November 2010 (UTC)

(edit conflict) The bolding of single titles is due to ! scope="col". Wouldn't | scope="col" would do the same from an access point of view while formatting it as a normal cell not a heading? Rambo's Revenge (talk) 19:20, 4 November 2010 (UTC)

(edit conflict) Previous discussion that was held without WP:FLC being involved. Oh, and "The Rambling does not understand..." is not constructive. In fact, I don't understand "... the bolding itself is useless, it is only a side effect of making row headers using..." at all. What I've pointed out above is an objective review of changes as a result of these updates from our friends at WP:ACCESS. Thanks. The Rambling Man (talk) 19:21, 4 November 2010 (UTC)

The same concerns you're having here (extra header and the bolding) were discussed on articles like Ursula Andress. Short answer to RR [5]: | makes a "td" element, and html5 makes scope obsolete with td elements. However, it was formerly not uncommon for people to use "td" elements "to avoid the display characteristics associated with th and also do not choose to use CSS to control the display for th" [6] (the same WCAG page linked at the discussion at Wikipedia_talk:Manual_of_Style_(accessibility)/Data_tables_tutorial#Scope_etc.). Gimmetoo (talk) 19:27, 4 November 2010 (UTC)

@Rambo's Revenge: Nope, it would not. And it will be depreciated in HTML 5, so we should not begin to use it now. Or else we will have to do everything from scratch again in a few years.

However, as suggested at MediaWiki talk:Common.css#Bold row headers, we can have row headers made with ! scope="row" | diplayed in normal weight (without bolding). It there is consensus about it.

@The Rambling Man: I can see you tried to remain neutral. That's good. I'm saying your summary is inaccurate. Since you created discussions in at more than five pages in a few hours, please slow down until tomorrow. That would be really helpful. Yours, Dodoïste (talk) 19:33, 4 November 2010 (UTC)

As I said before, it would have been useful for this to have been centralised some time before all this kicked off. For whatever reason, the FL community have been excluded from these discussions, now we have a chance to voice both our opinions and our suggestions. I suggest that's a good thing and you appreciate it rather than criticise me for trying to get to the bottom of this can of worms. And a reply to KV5's questions would be appreciated. The Rambling Man (talk) 19:38, 4 November 2010 (UTC)

(edit conflict)Agreed with TRM. His comments here are nothing short of a shock to me for the simple reason that the FL community has been excluded from these discussions (or, at the very least, was not properly notified to contribute), and everything he's said has been well within the bounds of appropriate dialogue. — KV5 • Talk • 19:40, 4 November 2010 (UTC)

"As I said before, it would have been useful for this to have been centralised some time before all this kicked off." This is such bull. The changes were appropriate and proper and were well discussed. They just have some side effects. Deal with the side effects and stop whining. It's like when new versions of MediaWiki get deployed and people run into VPT screaming: "Why wasn't I told this software function was gonna changes. we should have been notified, we didn't get to vote on it etc". If developers had to discuss every change they made (about 20 a day) with the wider community, then code would not be written and neither would editors have time left to actually write articles. Just because people have never created properly formatted tables that are accessible, does not mean that the existence of such tables exclude any form of active furthering of proper technology changes. Discuss, deal with the problems, don't make demands about how you should have been included. —TheDJ (talk • contribs) 21:21, 4 November 2010 (UTC)

Thanks for your constructive input. We're currently trying to work out the best way forward, not resort to a slanging contest. And yes, clearly we're trying to discuss and deal with the problems. And no, I didn't "demand" that the project should have been included, it just seemed pretty obvious that if anyone should have been included in the content domain, then featured list contributors were the ones. And you're wrong. This isn't just about aesthetics. It now appears there's a move afoot to change the way lists are oriented. That really should have involved the folks who contribute to content, not just those who worry about appearance. Also, it may be worth reading the concerns of the other FL contributors who have finally had a chance to contribute to this discussion, both above and below here. The Rambling Man (talk) 21:25, 4 November 2010 (UTC)

I've notified around a dozen or so of our most prolific contributors, in the hope that they'd contribute to this discussion. The Rambling Man (talk) 20:23, 4 November 2010 (UTC)

Well, I try to stay out of "politics" as much as possible, but I will insist that I much prefer the "old" look for discographies. I think the table headings are unnecessary, that the Year column should be before the Single column, and that the bolding of song titles is also unnecessary. I'd also like to say that, as an active and consistent FL contributor, I find complicated tables and changes to MOS/ACCESS frustrating (especially if I am expected to go back and amend all featured lists I have worked on in the past). I am a content contributor--I enjoy collecting information and presenting it as best as possible, and my preference is to not have to worry about formatting changes, etc. I realize this comes across as stubborn (and I do realize that Wikipedia is always a work in progress and can always be improved), but my point is just to be cautious about making too many requirements or drastic changes. Those are my only thoughts for now--I will try to follow this discussion but as I mentioned I focus on creating content and not getting involved in the more decision-making discussions. --Another Believer _(Talk) 21:04, 4 November 2010 (UTC)

I pretty much agree with everything Another Believer wrote. bamse (talk) 21:28, 4 November 2010 (UTC)

Summary of the situation so far

After several discussions at WP:DISCOG and WP:ACCESS, we carefully tried to implement this new guidelines in articles. Especially discographies list, where a handful of articles were updated. See the last discussion at the DISCOG project: are we ready to apply this updated guideline? In short, this new guidelines is still a proposal, and did not received enough feedback from users in order to be applied in every article. We are slowly trying to move forward.

Thus, this change is not expected in all lists now. We hope it will later on, but we do not want to rush things. You are invited to participate to the debate, at share your opinion about the new guideline at Wikipedia talk:WikiProject Discographies/style. Kind regards, Dodoïste (talk) 19:43, 4 November 2010 (UTC)

Sorry, but we'll keep the discussion here. It's a change to MOS, not a guideline change at DISCOGS. Frankly, we're not interested in guidelines at Wikiprojects, we're interested in ensuring we meet WP:MOS. Insufficient information about the changes rolled out to five existing featured lists was provided to the Featured List community and as a consequence, I'm doing my best to accumulate information here to get a view on how to proceed. All other threads I've been involved in now point here. Thanks. The Rambling Man (talk) 19:46, 4 November 2010 (UTC)

Concentrating on the access side of this, what you said about HTML 5 implies that each table effectively needs a unique key which must also be the first column and has no choice but to bolded and shaded a darker grey. This will work okay in some lists where there truly is a row heading but wouldn't work on others and would adversely effect formatting options. Take List of Premier League hat-tricks (sorry TRM), neither the date or player has to be unique and adding a unique hat-trick # field for access sake seems ridiculus. Rambo's Revenge (talk) 20:04, 4 November 2010 (UTC)

I agree with KV5. I think the bold captions on top of the tables are redundant to the section headers.—Chris!_c/t 20:52, 4 November 2010 (UTC)

Yes, many times the captions will be somewhat or very redundant, with some, possibly high, degree of overlap between the two. I don't think they'd often be exactly the same, though, except in cases where the tables are very simple or where the caption is only a cursory one. I make that assessment, of course, not having seen all the tables that we have, so I remain prepared to change my assessment.

We did talk (during some of the earlier discog-related discussions) about how to deal with this problem. In many such cases, it might be a very cool thing if we could make the table captions show up at (and get linked from) the TOC, and then we could get rid of the (whatever level) heading and just keep the caption. However I don't know how to make that happen, or whether it'd even be a good idea. — JohnFromPinckney (talk) 23:07, 4 November 2010 (UTC)

I've come here trying to keep up with the wandering centralized discussion that keeps popping up fresh in new places today, so I don't know how welcome my comments will be, or how they'll be taken. Especially after I confess that I have been <whisper> working on the discography changes </whisper>. But I would in all sincerity like to get some feedback and input from more people, and hope I can help keep a good discussion of the issues (technical and aesthetic) going. We've been deliberately going slowly to try and get more people involved in the discussion. Now it's happening.

Let's look at the hat-trick table pointed to by Rambo's Revenge above. (We'll ignore the table marked as Key for a moment, although it has problems of its own which might be instructional to discuss.) I see (I wear glasses, but have good corrected eyesight, BTW) that's it's long, has 7 columns, and must have something to do with football and national teams. I know it's football because of the photos in the article, and the national teams are evident because of the flag icons that stand out.

Otherwise, I am hard-pressed to understand what this is a table of. The article is List of Premier League hat-tricks, and possibly I wouldn't otherwise come here if I didn't already know and care about the Premier League, and already have an idea of what a hat-trick is (I thought it was 3 goals in a row in ice hockey, but that can't be it here).

So there's nothing for it but to read the actual text at the top. And sure enough the first sentence tells me what it is, and hey, it's like the hockey thing; there's apparently a hockey version. But still, the table isn't clear yet. What's it showing me? Why are the players listed in that order? I guess Eric Cantona (playing for France) is the best of them all, since he's first. Or maybe he's the worst. It can't be by country, because the flags are all mixed up. There are columns for For and Against, which look like teams, but what are they doing there? We've already got the flags showing the nationality. Oh, it's the nationality of the guy, meaning it's (apparently) merely the kind of passport the guy carries when he travels (and has nothing to do with football or hat-tricks or even hats). Cantona must play for Leeds United. And by finally looking at the last (no, second-last) column, and scanning the first few entries, I deduce, finally, that the list defaults to date order.

What would save me a lot of time and thinking power would be a caption on the table (making it an excellent example and irresistable to comment on here). How about (something like): "League players scoring 3 goals in one game, showing player's citizenship, team, opponent, and final score of game, ordered by date." I don't see why the nationality's there so my inclination is to leave it out, but then, I'm no football fan (obviously).

The player column should be marked up as headings, because they tell us what each row is about. The bolding that would result in your browser by default is useful because it tells you "this is the heading for this row."

The caption is an important part of conveying the table's content to users, not just to ignoramuses like me, but people for whom scanning the first few entries in the sixth column is not so easy and rather unintuitive. And now, I'm still not even sure what's the key thing the table is showing; is it the game, making date, score and teams the main things to show, or is it the player? The article is "List of hat-tricks", so maybe the player shouldn't come first after all. Maybe the game date is what's most important, which is why the table's sorted by that value. Thinking about the caption might help clarify how to improve the table. — JohnFromPinckney (talk) 23:10, 4 November 2010 (UTC)

But most of our tables are sortable by column heading, so how do captions deal with that? Do you have to add "initially" before "ordered"? And why is the caption bold? Surely that contravenes WP:MOS? The Rambling Man (talk) 11:08, 5 November 2010 (UTC)

Yes, of course, it is a waste of space to point out the initial sorting order on a sortable table, so it's best not to do it. But table captions are just like image ALT text in the sense that you have to think about what comes before and after the table caption for it to be useful. It may be that some tables are perfectly accessible without a caption, but it all depends on the context. You are right that bold text in a caption violates WP:MOSBOLD. Since it is your browser that adds the bolding, that would seem to imply that table captions are forbidden on Wikipedia unless we apply |+ style="font-weight:normal" | to every one of them, or get common.css changed. I'll ask the question at WT:Manual of Style (text formatting)#Table captions. --RexxS (talk) 17:08, 5 November 2010 (UTC)

My opinion (I was one of the people that TRM contacted per above): Ugh. I really cannot think of many worse ways for the ACCESS team to go about doing this. This is featured lists- supposed to be the best lists on wikipedia. As such, our tables should be the best on wikipedia, and should conform to the MOS. The ACCESS team seems to think that they know what should be changed in our tables to make them more accessible, as evidenced by the fact that they changed the MOS. And yet I, and apparently everyone else here, has no idea as to what we're supposed to do.

I really don't understand why you guys thought that influencing one wikiproject's guideline and modifying a few lists is the right way to get the word out. To be blunt: I am perfectly willing to change all of my FLs to conform to the new MOS guidelines, if they make sense (as I assume they do). Most likely everyone else here is willing to also do the legwork on the lists that they nominate. So... why don't I know what to do? The only summary I've seen is TRM's above, and your response was "no... that's not it."

Frankly, either you know what changes need to be done to wikitables to make them conform to the new access requirements, or you don't. If you do, then just freaking tell us. If you don't, then take it out of the MOS. It shouldn't be there if it's not done. --PresN 21:00, 4 November 2010 (UTC)

I basically agree with PresN; just maybe a little bit more politely! I'm happy to do anything that will help improve these tables for all users, and if complying to ACCESS guidelines does that, then I'm all for it. However, we need to know in clear terms what those guidelines are, and we need to know that they are solid and agreed upon; if they are going to change every couple of months, or haven't been completely ratified yet, then they probably shouldn't yet be used. Similar in many ways to WP:ALT, which is great; or would be if we could agree on it! Harrias ^talk 21:32, 4 November 2010 (UTC)

I concur with PresN. Somebody needs to explain properly what's supposed to be done because until then, nobody knows if they're coming or going and we don't know what we're discussing. HJ Mitchell | Penny for your thoughts? 21:43, 4 November 2010 (UTC)

Agreed. I find this discussion (in its various locations) to be very confusing. As a content contributor, I will continue to generate FLs in the manner I currently know how until I am told otherwise by official channels (FL criteria, FL directors, etc.) --Another Believer _(Talk) 21:52, 4 November 2010 (UTC)

That's fine. I think what I want to establish is whether WP:MOS has changed (so we need to be aware of the change as its inherently linked to our FL criteria) and if so, clear guidance on what we're expected to do to continue to meet MOS. From some preliminary digging, it would appear we may be forced to revise the ordering of columns, for instance, just for WP:ACCESS. The Rambling Man (talk) 21:57, 4 November 2010 (UTC)

Thank you for staying on top of this, TRM. Feel free to link to the discussion about column changes, as I would be interested to know why changes are preferred/required. (I think the changes are pointless and somewhat arbitrary, unless some editors know something I don't.) --Another Believer _(Talk) 22:08, 4 November 2010 (UTC)

From my understanding the column change is because ACCESS (requires/proposes/suggests) that each row and column has a scope attribute. This effectively makes the cell a heading so a screen reader can read information from a cell. e.g. in a discog it would connect that a chart placing refers to the chart (column heading) and the single (row heading). The headings are set by ! scope="col/row" and are therefore required to be the first column/row, otherwise you'd either get random bolding in the middle of your table or the access attribute wouldn't work or possibly both. Rambo's Revenge (talk) 22:14, 4 November 2010 (UTC)

So, RR, with your understanding, does this mean that the "keyword" (i.e. "most relevant" item) would always need to appear in the first column of any list? The Rambling Man (talk) 22:18, 4 November 2010 (UTC)

It means that keywords in the list should always be row headers (so using ! to open the cell instead of |, so the html generates hr elements instead of td elements. It also means that all header elements get a scope, so that it is known which "direction" the header applies to (row cells or column cells). —TheDJ (talk • contribs) 23:02, 4 November 2010 (UTC)

I have proposed a solution: MediaWiki_talk:Common.css#Solution. —TheDJ (talk • contribs) 23:15, 4 November 2010 (UTC)

Interesting proposal. Would the direction (i.e. row header) and therefore that syntax need to be in the first column cell or could it come from any column with the proposed "wikitable wikilist" syntax? I never bothered to ask this with the existing system as bolding (header class) the middle of a table was obviously undesriable aesthetically. Rambo's Revenge (talk) 23:24, 4 November 2010 (UTC)

For a wikitable it wouldn't matter. Not sure what screenreader and WCAG say of putting header cells in the middle of a row.... —TheDJ (talk • contribs) 23:34, 4 November 2010 (UTC)

Both WCAG and screenreaders (in general) have no problem with row headers being anywhere in a row. --RexxS (talk) 23:52, 4 November 2010 (UTC)

Replying only to User:Dodoïste's first statement in this subsection, you cannot implement a proposed WikProject style guide by going around and changing articles to meet it. Get consensus on the proposal first, then go around slowly updating pages. This is so strange. Matthewedwards :  Chat  02:49, 5 November 2010 (UTC)

There were several discussions. Including one here at FLC talk page two weeks ago: Wikipedia talk:Featured list candidates/Archive 14#Manual of Style Issues. The Rambling Man took part in it, so hhis claim that he wasn't informed and that the LFC community wasn't informed is surprising. This small discussion may not have been enough, though, and maybe that is the point of The Rambling Man.

The thing is, too few users gave a feedback on the proposed changes. So we decided to make the changes slowly, hoping to get more feedback from users. Now it's finally happening after two months or so. :-) Yours, Dodoïste (talk) 14:18, 5 November 2010 (UTC)

Agreed, that, on the face of it, appeared to be a misinformed editor blindly following DISCOG guidance. I'm glad this is being discussed wholesale here, and with the interest of the list community. I still seem to be missing a link to a community-wide consensus to roll these changes into existing featured lists though. The Rambling Man (talk) 14:25, 5 November 2010 (UTC)

Row headers

(edit conflict) Where to start? First of all, I guess, can I ask that we separate the issue of captions from that of row headers, and look at them one at a time? Captions are sometimes important, but the real issue is row headers. I'll re-use some previous comments in the hope that they illustrate the purpose and benefit of row headers – and please excuse me if you already know this:

• Screen readers may be set to announce the column header and row header before the data for any cell, allowing a blind reader to navigate up, down, left, right within the table, while still being clear what the data is related to. This is very important for the visually impaired.
• For a blind reader trying to move around anything other than the smallest table, the lack of header information is very frustrating. For example, in the Fantasia Barrino discography Singles table, hearing "3" doesn't mean much, and hearing "US R&B; 3" isn't much better. But they could hear "Free Yourself; US R&B; 3" if we give them sensible row headers.
• The downside of course is that when we change a cell from table data ('TD' in HTML, or '|' in wikimarkup) to a table row header ('TH scope="row"', or '!scope="row"'), your browser recognises the TH and applies bold and centred by default – just as it does for table column headers ('TH scope="col"', or '!scope="col"'). We are used to the behaviour of browsers in producing those visual effects, because we are used to having column headers and it seems 'natural' for those. On the other hand, most people don't see a difference between row headers and the rest of the data in the table, so they have never used them – which is why we are not accustomed to seeing bold (or centred) in a column that actually should contain row headers.
• I wanted to reduce the impact of that consequent centring and bolding, so if you look at the discussion at MediaWiki talk:Common.css#some wikitable ideas, you can see the struggle we had to get the row headers left-aligned by default for Wikipedia – and that was only possible because nobody could find a situation where centred might be a good default. I admit I quit while I was ahead at that point because I didn't have the strength to push for normal font weight as well, sorry.

So my suggestion now is that we go ahead and encourage editors to make use of row headers, because the benefits to the visually-impaired are very real.

Incidentally, it is not necessary from an accessibility point of view for row headers to be in the first column, it's just that it's easier to get editors to think of the structure of the table if it is the first column.

Unless we get a change to common.css, we will have to recognise that the accessibility improvements have a knock-on effect on the visual appearance of the cells that we make into row headers: by default they will be (1) left-aligned, (2) bold, (3) in a wiktable they will gain a grey background (#F2F2F2).

Any of those effects can be overridden by inline css styles like this: !scope="row" style="text-align:center; font-weight:normal; background-color:transparent;" (or any part of that depending on what effect you want).

Personally, I'd rather not go to this effort as I find the left-align/bold/grey background perfectly good (for the first column anyway). I do however accept that WikiProjects have a "house style", and I would not wish to alienate them, as they are the editors who are going to be implementing the accessibility improvements, as long as we don't put them off. I would add that I don't believe these effects are in violation of MOS, which says in MOSBOLD that headers should be bold – although I accept that it could be argued that whoever wrote it was thinking only of column headers.

If you want an example of where row headers have been added to a complex table, but preserved the original formatting, look at this change to Order of battle of the Battle of Long Island. I would maintain that the inline styles could be removed without any violation of MOS, but obviously I didn't want to dramatically alter the previous appearance of the table.

So what do you want to do as regards FLC? I know you will want to make the improvements for accessibility. Are you willing to accept bold row headers, which is a consequence of that improvement? What about the grey background in wikitables – would that be acceptable, if it were limited to the first column? Or are those essentially decisions for each WikiProject's "house style"? If the answers are affirmative, then the accessibility improvements will require little effort. If not, then we need a guide on how to upgrade accessibility while preserving the previous formatting. I'll be happy to help either way. --RexxS (talk) 23:26, 4 November 2010 (UTC)

Where does the MOS come in?

This seems to be a hot topic, judging from the amount of text that has accumulated here within a day. However, I feel like I'm sitting in the audience of a play, the half of which is performed backstage. What I would like to see is a diff, showing what changes to the MOS are being proposed. I'm also wondering, shouldn't this be discussed at the talk page of the MOS page in question? Goodraise 06:34, 5 November 2010 (UTC)

I have repeatedly asked for links to the discussions and a link to the community consensus to start implementing these changes. And it's no longer a case of what is being proposed to MOS, that already appears to have happened, it's a case of it now being rolled out across existing featured material without any discussion here. The Rambling Man (talk) 07:43, 5 November 2010 (UTC)

Table captions (or table header) at the top of the table have been a core part of WP:ACCESS since 2006, when the page was created. It was still there in January 2008 when the page was already quite similar to its current state. And in 2008, WP:ACCESS was already a part of the MOS. So table captions are not new.

The change concerning column headers !scope="col"| and row headers !scope="row"| at the accessibility MOS was made at Wikipedia talk:Manual of Style (accessibility)/Archive 11#How to make accessible tables, the 27th of July. There wasn't much discussion there, and this change seemed to be consensual.

The discussions at WP:DISCOGSTYLE are:

1. Wikipedia talk:WikiProject Discographies/style/Archive 2#Accessibility issues, in August
2. Between August and September, we decided how to update the discographies, and there was consensus to go ahead at the bottom of Time to update. Wich leads to Lil-unique1's suggestions and the first cautious steps forward.
3. Later on, a discussion occurred about the text size of national charts headers at Size requirement? There was consensus to keep a text size of 90% (and possibly 85% if users prefers that style) instead of the previous 75%.

A. We got significant feedback from users about the centered row headers. Users were reluctant to make row headers because they are centered. We had anticipated this issue, and had requested a change at MediaWiki talk:Common.css#some wikitable ideas back in August. But at the time it didn't get enough attention, so the change wasn't made. With the significant feedback and users involved by the end of September and October, the change was made and wikitable row headers got left aligned.

B. This last days we received significant feedback from users about the bold row headers. Users are reluctant to make row headers because they are boldened. There is a discussion at MediaWiki talk:Common.css#Bold row headers to find an solution for it, but this one is more tricky.

This is all, regarding the list of previous discussions. You appear the think that there is a need for a broader discussion that this one at WT:FLC. Since we were wondering how to get more attention to these changes, we're open to suggestions. It would be best to address the concerns about bold row headers before starting any more discussions though, and propose these changes to the wider community afterward. Kind regards, Dodoïste (talk) 16:28, 5 November 2010 (UTC)

(edit conflict) The relevant section is in the subpage WP:Manual of Style (accessibility)#Data tables. The brief discussion of the section is at WT:Manual of Style (accessibility)#Accessibility table tutorial is coming. The more detailed guidance is at WP:Manual of Style (accessibility)/Data tables tutorial and the discussion on that is at WT:Manual of Style (accessibility)/Data tables tutorial. I hope that makes it clearer what guidelines are being implemented. Nothing is set in stone, and I'm sure that further discussion would be welcome. However, I should point out that these guidelines are derived from WCAG 2.0, rather than documenting practice on Wikipedia, so are unusual in that aspect. --RexxS (talk) 16:36, 5 November 2010 (UTC)

What happened to "My advice is not to worry about it – if you feel that it is not needed in a table you create, then leave it out". The World Wide Web Consortium's advice that "for simple tables [which have] headers in the first row or column then it is sufficient to simply use the TH elements without scope" is still present and I have seen no evidence that this is erroneous. I would vehemently oppose these somewhat complicated changes where they are, seemingly, superflous. Rambo's Revenge (talk) 21:22, 5 November 2010 (UTC)

Yup, I already said this guideline has it wrong, and it's a known fact to accessibility experts. See, there are several application methodology for WCAG 2.0. Section 508 has WebAIM section 508 checklist, for example. And about this particular issue, WebAIM explicitely says that "The scope attribute should be used on simple data tables". The ITAA guideline says the same. And other application methodologies around the world, like Euracert and the French RGAA says the same. They all agree that W3C made a slight mistake here, and this mistake is likely to be fixed in later versions of the WCAG 2.0 guideline. Kind regards, Dodoïste (talk) 21:56, 5 November 2010 (UTC)

(edit conflict) I stand by my advice. We don't stop people writing articles just because they don't know how to produce inline citations yet. As long as something's there, somebody will come along and improve it. The same goes for tables; we should be encouraging editors to produce to the best of their abilities, but we don't need perfection from the start. It is true that most screen readers will correctly guess the scope of a TH element. Placing scope on a TH simply removes the possibility for error – and that makes it an improvement to me, but it's not such a big deal. But what we're really discussing here is changing cells from 'TD' to 'TH scope="row"' to allow screen readers to announce a row header for any cell, and that is a big deal for the visually impaired. The reason it becomes complicated is because your browser then wants to change the formatting of the cell that has now become a TH, and nobody seems willing to accept the browser's default, particularly the bold face. If that didn't cause objections, it would be a trivial exercise to improve the accessibility of tables.

For an example, I just completed converting the main table at List of Denver RTD light rail stations to have row headers. Instead of two minutes' worth of pasting !scope="row" at the start of each of 37 rows, which would have made the table properly accessible but left it with bold station names, I had to spend more like 20 minutes adding or merging in style="font-weight:normal;" since many rows already had inline styles and I had to check against an earlier version because of the increased chance of mistakes. That's why the changes are indeed complicated, and it's the price we pay for insisting on having formatting that isn't the browser default. --RexxS (talk) 22:07, 5 November 2010 (UTC)

Embedding inline styles such as style="font-weight:normal;" is inappropriate per WP:Deviations. The place for setting such font-weights is in a style sheet, not via endless inline styling. Semantically, row-headers are appropriate in a lot of places they are not currently being used. Occasional inline styling will occur, but any mass effort at fighting the site css is inappropriate. If there's a solid case for a style sheet change, it will happen, but the barrier to that, appropriately, is high. If a deviation fails to get consensus for the site style sheets, it is inappropriate to force the issue on an article-by-article basis by the use on hard-coded inlines. And templates are really only about encapsulating a deviation, as any styling in them still results in embedding inline styling for readers. Cheers, Jack Merridew 23:09, 5 November 2010 (UTC)

This is exactly the problem that class="wikitable wikilist" would fix. —TheDJ (talk • contribs) 01:23, 6 November 2010 (UTC)

Oh, I know; it's just that I object to the forking of the styling. I think that the headers should look like headers, which especially means the darker background. I'm fine with exceptions on the bolding, and row-headers should mostly not be centered, they belong on the left. Cheers, Jack Merridew 00:09, 7 November 2010 (UTC)

Oh my god. I just started to apply all these changes to my lists and then suddenly someone say that some of those changes are inappropriate. Come on, you MOS people really need to get this MOS mess sorted out among yourselves before asking editors here to make major changes!—Chris!_c/t 23:23, 5 November 2010 (UTC)

I think the MOS is quite clear. To make a table as accessible as possible, you have both column and row headers. There is nothing inappropriate about that, and I don't believe anyone here has suggested otherwise. --RexxS (talk) 00:16, 6 November 2010 (UTC)

Then what is User:Jack Merridew talking about? He seems to say that some of the changes are inappropriate.—Chris!_c/t 00:42, 6 November 2010 (UTC)

My post was about the evils of mass-overriding the site style sheets with inline-styling. You doing that? If so, who told you to, and why listen to such guidance? Cheers, Jack Merridew 00:51, 6 November 2010 (UTC)

You think I want to mess with all this. I am only doing that to make all the lists satisfy WP:ACCESS, which is what all the MOS experts here are asking FLC regulars to do.—Chris!_c/t 01:33, 6 November 2010 (UTC)

Actually, Jack Merridew is talking about an issue that we are going to address soon at MediaWiki_talk:Common.css#Solution. So there is nothing for you to worry about, you did the right thing in updating articles. :-) Some inline styles were used in a few articles, and that was necessary temporarily. We will fix it ourselves once the change is made at MediaWiki:Common.css. And Jack was intentionally exaggerating the issue, by the way. Yours, Dodoïste (talk) 11:24, 6 November 2010 (UTC)

You know my intentions? Perhaps you're not aware of as many instance of inappropriate inline code as I am. We do agree on somethings, and you'd be better off not backhanding those who might otherwise be your allies. Jack Merridew 00:09, 7 November 2010 (UTC)

I honestly thought I knew. I also encourage the use of CSS instead of inline code. Lighter, easier to code, easier to maintain. But don't make a drama for a few lines of inline code. We could fix these issues if you had agreed to Edokter's proposal at MediaWiki_talk:Common.css#Solution. But now, you're really not helping. We won't go anywhere this way. Dodoïste (talk) 10:37, 7 November 2010 (UTC)

RT Dodoiste. I'm sorry but reading about these supposed "accessibility experts" really pisses me off. If w3.org aren't, then who is? Who is this expert that the people/person at WP:ACCESS has been communicating with? Why haven't they come on to Wikipedia to speak for themselves? What is their name? Their profession? Uni degrees? It all smacks of Essjay and I for one refuse to accept anything your experts say without knowing a whole lot more about them, and refuse to conform to these guidelines until that happens. Matthewedwards :  Chat  04:26, 7 November 2010 (UTC)

Perhaps you would take a look at a tutorial for a common screen reader HTML Tables with JAWS and MAGic and try to get a feel for what it must be like for a blind reader who visits one of our articles with tables in it?

A JAWS user can call up a list of all of the tables on a web page and go directly to the one they are interested in if they choose – except they can't in many of our articles, because that list is generated from the table captions, and most of the time, we don't have any. Are we considering these users when we ban captions from our "finest" articles?

As a JAWS users works through a table, they will get the contents of the current cell read to them, preceded by the column and row headers if marked up as headers. So if they wanted to see how Bryan Adams' studio albums performed in the UK, they could move down the sixth column and hear "UK; —" then "UK; 78" then "UK; 21", and so on. They don't know what albums these are, so each time they would have to go left until they found the album title, and then work their way back to the UK column. Is that a sensible way to present information to a blind user in our "finest" articles?

If you've read the tutorial, you'll know that they can change the default behaviour, so that Jaws will attempt to use the first column as a row header. It's an inconvenience, but possible. But now what happens on the Bryan Adams table? This time they get "UK; 1980; —" then "UK; 1981; 78" then "UK; 1983; 21", and so on. Is that any improvement? Is that a sensible way to present information to a blind user in our "finest" articles?

But if the JAWS user wants the same information on Rihanna's studio albums, they hear "UK; Music of the Sun; 35"" then "UK; A Girl Like Me; 5", and so on. Which article would the blind user think was one of our "finest" articles?

The difference is that the latter article has a sensible choice for row headers (album title) and they are marked up as row headers – the wiki-markup is '! scope="row"'.

I make no claim to be an accessibility expert – or an expert on anything for that matter – but even a dummmy like me can see that marking up row headers (and adding captions) in our tables will make the experience much better for blind readers. So please do Wikipedia and our blind or visually-impaired readers a favour, and start marking up tables with row headers, not because some "expert" is telling you to, but because you can see it makes sense, and improves the article dramatically for many. --RexxS (talk) 05:22, 7 November 2010 (UTC)

@Matthewedwards: We are following W3C's guidelines and approach. The expert is only here to make sure we don't misunderstand W3C guidelines. The only exception so far, where I didn't follow W3c's WCAG 2.0 guideline, concerns a mistake in a particular guideline (see above). This mistake is acknowledged by all WCAG 2.0 applications methodologies, so we are still following trusted sources and no "expert" in particular. Perhaps I should rephrase these part of the table tutorial, to reflect this approach and avoid the Essjay controversy. Yours, Dodoïste (talk) 10:56, 7 November 2010 (UTC)

Bold (or otherwise) table captions

It seems we're making some good progress on the row headers issue, so while we have some momentum, I'd like to gauge the community's opinions on table captions, and also ACCESS's opinions on their use for both sighted and unsighted/visually impaired readers. JohnFromPinckney has talked us through an example above on the list of Premiership hat-tricks list (glad we're using such a comprehensive and useful list as an example by the way!!) and it makes for useful reading, it allows us to have a look at our lists from a completely different perspective. But what I want to know from everyone is whether these captions are being used in the best way possible, if they're correctly formatted and if they have an impact on how we should actually order the data we're presenting. The Rambling Man (talk) 14:19, 7 November 2010 (UTC)

The question was raised at Wikipedia talk:Manual of Style (text formatting)#Table captions. Few people commented, so the question is still open. Dodoïste (talk) 15:23, 7 November 2010 (UTC)

Okay, well RexxS is looking to modify MOSBOLD to allow these captions. I guess then, from our FLC perspective, how to best use/hide these captions as they are often redundant following a section heading and provide, in most circumstances I've seen, no additional help to any sighted reader. The Rambling Man (talk) 16:40, 7 November 2010 (UTC)

I think there are three issues here:

1. Should we have table captions?
2. Does the browser default text-formatting of table captions (bold) violate MOS?
3. Do we want table captions to be bold, from a stylistic/aesthetic point of view?

I'd suggest we try to keep discussion focussed as far as possible, since an negative answer to (1) precludes the others; and a positive answer to (2) precludes (3). --RexxS (talk) 16:44, 7 November 2010 (UTC)

Agreed. But a subtle change to (1) I think should be to discuss if could have table captions that can be made invisible except to screen readers? The Rambling Man (talk) 16:54, 7 November 2010 (UTC)

Well, I was considering the first a matter of principle, rather than contingent on any particular implementation. In other words, should we, as a matter of principle, be providing a means for blind readers to bring up a list of tables and pick the one they were interested in. If so, then there's a fourth issue: "Do we want the ability to show the caption only to screen readers?" I'll investigate an alternative solution by asking User:Graham87 if he can get a list of tables by other means, and we can see what he says. --RexxS (talk) 17:19, 7 November 2010 (UTC)

Fair play. I think there's little doubt that a caption will help blind and visually challenged readers, so I'd rather like to hope the community will, in principle, have no problems with having something to help there. So a fourth issue, as you describe, is definitely worth a debate. The Rambling Man (talk) 17:29, 7 November 2010 (UTC)

Table captions are also useful for users with cognitive disabilities and possibly certain forms of dyslexia, especially when the structure of the table is complex. And as JohnFromPinckney said, table captions can be useul for average users when the table is really complex.

Table captions are semantically associated to tables. Search engines and robots reusing the content can get a header for the table, so they can respectively improve their index or associate the data inside the table with a header. This is not possible with a section header.

Now the uses of table captions at the discographies are not optimal, I would say. Sometimes, the captions is longer that the table width, which looks bad. And the header is not very effective when it is too long, it's not efficient. For example, "List of singles, with selected chart positions and certifications, showing year released and album name" is too long, and could be shortened in "Fantasia Barrino singles and selected chart positions". Yours, Dodoïste (talk) 17:49, 7 November 2010 (UTC)

And your example is pretty much self-evident from the section heading, the overall list subject matter and the column headings. Right? The Rambling Man (talk) 18:17, 7 November 2010 (UTC)

Shades of ALT-text! Yes, editors will try too hard and over-egg the mix. How about if I suggested that an editor makes a mental list of the table captions, and then decides what should be enough in such a list to identify/define each table? "Singles and selected chart positions" would probably be enough, in my humble opinion - unless the table were to be reused elsewhere, in which case "Fantasia Barrino " would need to be added. --RexxS (talk) 18:49, 7 November 2010 (UTC)

Sounds like an ideal candidate for the section heading to me, no need for a caption at all in this case? The Rambling Man (talk) 19:00, 7 November 2010 (UTC)

The Rambling Man has courteously mentioned my somewhat lengthy monologue up above, and I'm getting here a bit late besides, so I'll try to be brief here.

1. Mostly, yes, I'd like us to have table captions, especially if that's the only way for non-sighted/low-vision users to find the non-layout tables. It's hard for me to find examples of tables that wouldn't have some benefit from a caption when the table is in the middle of a texty article section. Captions are harder to defend for simple tables immediately following a section heading, where the redundancy is more easily...redundant.

2. Bold for captions does not violate MOS:BOLD at the moment, nor should it. A bold caption is entirely appropriate on WP (and other Web sites).

3. I like and quite prefer the bold for captions, but would respect a consensus to de-bold them.

4. I'm less enthusiastic about optional display of captions, as I'm of the opinion that good captions help all of us.

I should mention (or somewhere) that I am not emphatic that the captions now at WP:DISCOGSTYLE are the perfect wordings. I know they do seem a bit long, since (1) we're not used to having them at all, and (2) they don't appear to offer much beyond what we see –see– in the table's column headings and (usually) section headings, both so close by. I'd very much welcome some expert advice on those. — JohnFromPinckney (talk) 19:21, 8 November 2010 (UTC)

John, nice to hear from you again! So yes, I think we're making some forward ground on this but we need to understand what benefit a partially sighted reader would get if the table follows either a section heading, or a section heading and some prose to explain what the table contains. As seen here, live at FLC, sortable tables makes the captions which include "sorted by ..." redundant, and perhaps section headings/lead-in prose makes captions redundant. One of the "good examples" at Wikipedia talk:Manual of Style (accessibility)/Data tables tutorial‎ (and, seriously, this page needs a heap of work before it becomes "what to do" as part of MOS) includes a pretty hopeless caption, including a bold link and a flag. Is this what we want to be selling to our audience? I do, however, look forward to hearing more about the "expert" and his advice you might have for us? The Rambling Man (talk) 19:40, 8 November 2010 (UTC)

It's that damned Real Life getting in the way again. Annoying, as I see good things are actually happening here, and it's hard to keep up.

I don't claim the "sorted by" on sortable tables is the best idea, although I am entirely clueless on how assistive technology (AT) users interact with sortables, or what would be useful for them. I know it's goofy for a caption to say "sorted by week" when the user's gone and sorted by hair color. That's one of the things I'd like more specific details on from an expert or more experienced user than I.

You point to the Talk page, but I think you meant WP:Manual of Style (accessibility)/Data tables tutorial‎. I agree that the page could use more work, but I know it's been understood as a work in progress. I think Dodoïste (main contributor) has been careful to give not only instruction but also some indication of priority and riskiness. Going point-for-point, I don't believe a discussion of any one point is wrong, but (1) some things might be more clearly worded (Dodoïste's native language is French, not English) and (2) each example could be more completely developed, so that, e.g., the captions are good on all the examples, not just the one talking specifically about captions.

I know you dinged the "pretty hopeless caption, including a bold link and a flag", but I don't see the problems in that case. The flag is useless to the blind user, but she won't see (or otherwise stumble over) the flag anyway. A link to Belarus is useful for sighted as well as impaired users, so the link shouldn't cause you concern. The boldness of the caption is being discussed here already, but I've said they seem appropriate, others have said likewise (before me, not because I said so), and Wikimedia software makes them that way on (some) purpose. I'd need another clue to understand what you don't like about that caption.

I'm hardly an expert myself, more of an informal student of accessibility and site design. And I wish we had more experts floating around, as I don't have one here with me, unfortunately. I'm as eager as you are to get more feedback on what we're doing well and not so well. — JohnFromPinckney (talk) 21:05, 8 November 2010 (UTC)

Hey John. I think we're all on the same page, beside the fact that I would prefer to see MOS pages/MOS tutorials written, copyedited and "approved" by people that are aware of all of MOS, not just those that affect ACCESS. The captions you're saying are okay there are different from those you recommended on the hat-trick list, and that's the rub. I need to know what we're after. If, after all, a caption can be "Representing (pause) Belarus" (which, frankly, is surely a useful as a chocolate fireguard to a non-visually able reader) is worth putting in a MOS tutorial, then I'll pack this whole thing in now, and freestyle. On the other hand, if we can agree that sensible, useful captions could/should/ought to be visible/around/accessible then so much the better. If the ACCESS team wish to write guidelines, they should do so with all the other guidelines in mind. Otherwise we're in an endlessly self-destructive (is that possible) cycle of preach-and-hate. The Rambling Man (talk) 21:15, 8 November 2010 (UTC)

Table captions are semantically appropriate for most tables. This is not specifically an accessibility issue for the visually impaired but it helps them, too. The caption element is specifically intended to be the primary description of the nature of a data table for all users. A section header (h2) is intended to refer to all of the content of a major section of a page and if the two seem redundant, a few paragraphs of prose about the section between the h2 and the table will alleviate the issue. I believe the default bold is appropriate for most cases and the MOS should reflect that: they're "like" headers, which are bold but, again, they're structurally associated with the table itself. This is about appropriate semantic structure of articles. Googlebot loves table captions ;) Jack Merridew 19:28, 7 November 2010 (UTC)

If blind editors get into the habit of navigating our pages by section headers rather than by a list of tables, then yes the two would perform in the same way. Optionally, you could keep the table caption and remove a redundant sub-sub-header on larger pages. Which is better? --RexxS (talk) 19:35, 7 November 2010 (UTC)

Adequate section headings would solve it all round by the sounds of things. And I'm not too bothered about Googlebot to be fair. Appropriate semantic structure of articles is all very well, but the captions on infoboxes (which are being cited as a reason to keep bold text in captions) are hardly captions are they? For instance, the infobox caption for Fantasia Barrino discography should be something like "Summary of releases by Fantasia Barrino and an image of the artist" rather than "Fantasia Barrino discography", surely? The Rambling Man (talk) 19:55, 7 November 2010 (UTC)

Actually, "and an image of the artist" is absolutely unnecessary. Several choices are available, like "Overview of Fantasia Barrino discography". But a long caption is not necessarily a good caption, like I said above. So the current situation of the infobox is not bad. Yours, Dodoïste (talk) 20:03, 7 November 2010 (UTC)

Um, first, why not "an image of the artist"? Your dyselxic/visually impaired audience may like that information, assuming alt text isn't available. Also, what about infobox captions for other pages, like Ipswich Town F.C.? Why should discog infobox captions be different from this caption? Presumably the caption for this infobox would be "Summary of Ipswich Town F.C.'s principle properties, including year of foundation, stadium name, stadium size, ...., current strip, and a link to the current season's article"? The Rambling Man (talk) 20:08, 7 November 2010 (UTC)

A screen reader will already tell him there is an image here, and since it is a decorative image without important information there is almost no need for alt text. There is a need of a short alt text to compensate a MediaWiki bug, but that's all. Dislexia is about text, I believe images are fine.

Didn't I say those examples were way too long? It's not helping to make a list of the headers inside the table caption, the headers are enough themselves. Like I said, "Ipswich Town F.C. overview" would be really enough. "Overview" could be replaced with something similar, like "most important data" or "data summary" or whatever sounds best. Yours, Dodoïste (talk) 20:54, 7 November 2010 (UTC)

Okay, so "Fantasia Barrino singles overview" would be sufficient? So it repeats the section heading. I think you guys need to sort out what you want to see in a caption because right now we're getting mixed signals, which inevitably leads to rejection. The Rambling Man (talk) 20:55, 7 November 2010 (UTC)

Fantasia Barrino discography probably should be sporting some sort of {{Infobox discography}}, not a knock-off of the box on the bio. Structurally, that is a caption-element (as it should be). nb: some infoboxes are using a colspaning set of table headers for an inside-the-box faux caption, and that's a poor practice. The utility of proper captions is also to any other piece of software that ever scrapes data that originates in our DB. This is really about how we structure information and convey what it is. Any sense of redundancy with section headings really is about a paucity of prose. There's far too much table usage on Wikipedia for non-tabular data; i.e. for layout. This is so 1990s. It is driven by the poor support of MediaWiki for other structures. Wiki-text is getting creaky in its old age. Cheers, Jack Merridew 20:30, 7 November 2010 (UTC)

Okay, this is good, but what all editors are looking for is consistency across the project. If I'm hearing that bold captions on tables are allowed/mandated partly because they're around for infoboxes, have been around forever and are staying around, then I insist on consistency on the content of the caption. So infobox captions get stupidly big, or we find a compromise.

The one thing that does interest me, Jack, is the idea of introducing each table with some prose. This is already something we do with tables we (currently) consider generally unclear to non-expert readers, like List of National Treasures of Japan (ancient documents) with a Usage section. Excusing any other problems, is this a part-way solution to the description issue? We may need further advice on our "key" (usually another table so more problems, but we could convert....) or "usage" sections, but is that a way of helping us move along? 20:36, 7 November 2010 (UTC)

I missed that the page is using {{Infobox artist discography}}, which fixes the caption as: '''{{{Artist}}} discography'''. Mebbe this needs changing.

Captions in general should be fairly concise. Prattle-on and it can stretch the table wider than its natural size. So, guidance should reflect that. The text of captions should speak to the question "What is it? [the table]". They're for everyone; our readers. Prose should introduce a table and possibly follow it, too. That's bedrock; articles should favour text. In many pages, we have a poor ratio of text to markup. A messy infobox, right up-front. Editable-sections that have nothing but a wikitable in them. Or three tables. Making tables accessible is appropriate, but it assumes that the table is appropriate. For many lists, html's list structures are more appropriate, are very accessible, and are a breeze to edit. Maintaining consistency is much easier. MediaWiki's wiki-text syntax was defined before it was fully understood that tables were not the best mechanism to layout pages and build websites. This resulted in wiki-syntax supporting tables well, but 'div's and lists less-well. And editors love 'upgrading' things to tables, and then further cluttering the editbox with stuff about colours.

The best route to 'consistency' is simplicity. Anything that involves heaps of extra code in each page is doomed to inconsistency. This is core to what wikis are. (too many edit conflicts;) Cheers, Jack Merridew 21:48, 7 November 2010 (UTC)

re: List of National Treasures of Japan (ancient documents)

I'm not sure what to make of that. I think it's something that might be seeking to become and embedded database in the page [a future-feature]. The 'usage' is rather too-much and lives a whole section above the one containing the table. That table seems confusing and I'd take that as a hint that some other format or structure might be more appropriate. The other piece of this, it the html-table attribute "summary", which is typically *not* displayed. It's purpose is a more verbose summary and it is useful to screen-readers. Cheers, Jack Merridew 22:12, 7 November 2010 (UTC)

The bold caption is not a default browser behavior (the default is normal text). It is an intentional layout make especially for wikitables, defined by developers at http://bits.wikimedia.org/skins-1.5/common/shared.css?283-5. It is used with consistency across all Wikimedia Projects. We potentially "could" ask developers to change it, but I'm not sure they would agree. One thing is sure though: it feels wrong to change this behavior ourselves, as it would break the consistency with Wikimedia projects. Yours, Dodoïste (talk) 21:02, 7 November 2010 (UTC)

Perhaps you put this answer in the wrong place? What does it relate to for prose before tables? If you mean to reply to bold captions in infoboxes etc, that's the least of my worries with this right now. The Rambling Man (talk) 21:17, 7 November 2010 (UTC)

Yup, we've specified teh bold on captions: (shared.css)

.wikitable caption
{
 font-weight: bold;
}

That's WMF-bedrock, again. Don't think of overriding that. Cheers, Jack Merridew 21:48, 7 November 2010 (UTC)

Anyone listening? I said "bold captions... least of my worries". I'm not arguing with that at the moment. What I really want to know is what the caption should say. And why, if the caption in the infobox is being cited as why table captions should also be bold, why infobox captions aren't much more comprehensive as, say, JohnFromPinckney has suggested above ("League players scoring 3 goals in one game, showing player's citizenship, team, opponent, and final score of game, ordered by date"). The only suggestions so far (e.g. blah overview) seem to be able to be more than covered by section headings, or prose before a table, both of which are far preferable to the captions (in my opinion, of course)... The Rambling Man (talk) 08:25, 8 November 2010 (UTC)

I used the example of infobox captions to illustrate that they are bold, not as an example of the content of a caption. It won't be much use for that because all text in an infobox is constrained by space concerns, and requires different considerations. If a table has a caption – and I'm not suggesting that every table has to have one – then I believe that its text should depend on the context in which the table is placed. If a table is the only thing in a section (but I don't actually think that is good practice), and the section header is essentially the same as a description of the table, then I'd concede that many editors may find the caption sufficiently redundant to omit it. In other words, I think the lack of a caption in those cases is a sufficiently recognisable exception to ACCESS that it would not be a good reason to oppose a FL candidate. That's just my personal opinion, of course, and you folks will be better judges of the standards required.

I find it difficult to give precise guidance on what the text of captions should be. Perhaps I can give a couple of examples of captions as explanation. Oxygen toxicity#Signs and symptoms is a featured article that I was responsible for some time ago, and the table caption there is a poor one because it's not concise. In fact I used the caption from the table in the source (an article in the public domain), but article captions and web page captions serve different purposes. In Nitrogen narcosis#Signs and symptoms (a more recent GA), the caption is much more concise, and although it's the same as [article title]+[section title] and has introductory text, it allows the table to stand alone – you can glance at that page and see what the table is about without having to refer to the rest of the article. In the context of that article, I'd argue that it's a good caption. If the table were the only thing in a section called Signs and symptoms, I'd accept that many readers would find it redundant.

I'd be pleased if the contributors here were able suggest what guidance they felt would be appropriate for the use of captions in tables. I find it a complex issue, and it's hard for me to distil the many factors into a simple guideline. --RexxS (talk) 15:26, 8 November 2010 (UTC)

I think that's a difficult answer to codify, especially in the context of lists. You mention that you believe tables in their own sections are not "good practice", but that is what most FLs and FLCs are: the lead is supposed to provide the necessary context to summarize and introduce the table. In that case, I believe that the tables should be exempted from provision of a caption that's going to unnecessarily duplicate the section header. If, however, multiple tables exist under one section header, then it's pretty obvious that the captions have much more utility, and in that case, they should almost certainly be implemented. In taking a current FLC of mine, is it necessary to input a caption on the table at Philadelphia Phillies all-time roster (A) when the lead has already explained that the purview of the list is Philadelphia Phillies players whose surnames begin with A? I believe that it would be redundant (obviously we're trying to be as concise as possible as this is an encyclopedia), but I can see how others might believe a caption such as "Players whose surnames begin with A" might be valuable. I just disagree on that point. — KV5 • Talk • 15:46, 8 November 2010 (UTC)

That's fair comment, and I don't want to impose my personal preferences. Since you asked though, I followed your link and immediately scrolled to the table. At first glance, it was really not apparent to me what the table was about, and I honestly think I'd have benefited from the caption you suggest! If anybody else wants to simulate what I saw, follow this link: Philadelphia Phillies all-time roster (A)#A. I know that's not a proper test, because that link doesn't exist anywhere else (as far as I know), but I sometimes do browse around articles without reading the lead, and I guess that's my own fault. I respect the fact you would disagree with me, and the short answer to your question is that I don't think a table caption is necessary, but I would prefer one. I do agree though that we ought to recommend captions for multiple tables in a section. --RexxS (talk) 16:51, 8 November 2010 (UTC)

So, RexxS, are infoboxes exempt from "good" captions then? I only ask as I thought they were considered "sort-of" data tables (because of the various read-across bits and bobs - bold caption, bold row headers etc that are now considered important to these data tables). Does that mean infoboxes are not accessible, or are they accessible but in a different way? It would seem odd (from my point of view) to go the trouble of making a table "more" accessible by adding a caption (which in most cases would repeat the section heading) while leaving infoboxes (which exist in a great many featured lists and featured articles) unaccessible, despite being data tables. The Rambling Man (talk) 15:54, 8 November 2010 (UTC)

Well, for various reasons of style, collapsibility, etc. infoboxes may or may not use captions, and {{Infobox}} allows an optional choice. What you see at the top of any particular box may be a caption or a merged header, so from an accessibility point of view, captioning varies. As for the actual data, all the infoboxes I've looked at have properly scoped column and row headers, so I see no problem there. Your point is well-made though: it must seem odd to take the trouble of making a table more accessible by adding a caption, when we don't always do the same for the tables which comprise infoboxes. Still, I'm an optimist and I try not to let OtherShitExists stop me from doing what I can. --RexxS (talk) 17:28, 8 November 2010 (UTC)

Fair enough, I only voiced that particular concern because it was, apparently, so glaringly obvious that, because infoboxes have bold captions, and they're tables, then why shouldn't data tables? So it led me on to wondering about accessibility of infoboxes. Although another digression is the last thing we need, I want to get a clear understanding as to whether infoboxes should be treated the same as the usual data tables, to ensure accessibility, and that may need us to re-appraise the way they're used. The Rambling Man (talk) 17:32, 8 November 2010 (UTC)

In response to RexxS from 16:51, 8 November 2010, and the Philadelphia Phillies all-time roster (A) mentioned above:

It's not that a caption on both tables, the Key and main tables, would be redundant; rather they'd be appropriate and desirable, by users of all kinds. Here's why I say that: both of the section headings in that page are extraneous and ought to be removed. The article is only the "A" section of the team's roster, so a heading of "A" is silly. A section of just "Key" is also odd, especially when it's got the Key table and the actual "A" players (the bulk of the article) in it. My recommendation would go something like:

Title of article as H1
  Intro in prose (how 'bout all dem Philles, eh?)
  Nav thingy with A B C D etc.
  Key table, preceded by its caption (might be just "Key", might be more like "Key to symbols and columns in table of players"
  Main table of "A" players, preceded by its caption ("List of players, showing seasons and positions played")
  "Footnotes" as H2 heading
  "References" as H2 heading

A reason for having the "A" heading is more apparent in Philadelphia Phillies all-time roster (I–J) which has more than one table of lettered players. For them, H2 headings ("I", "J") might be okay (though not necessary, IMO), but the captions would need some disambiguation, like "List of players whose names begin with I, showing seasons and positions played". I don't know how to add linky goodness to such captions for TOC listing, in case that's desired. — JohnFromPinckney (talk) 20:25, 8 November 2010 (UTC)

Wow, that's a big turnabout. Ok. Since this is a current nomination, should I implement these changes as a testcase and proceed from there? — KV5 • Talk • 20:43, 8 November 2010 (UTC)

It's worth a change, and a diff to show us what the change is. We'd like to do our best to accommodate this sort of thing, but (at least I do) we need education as to the results of the changes. Go for it, and report back. Good luck out there. The Rambling Man (talk) 20:45, 8 November 2010 (UTC)

Diff here on the main list, and the related changes to the embedded key. Here is before and after as well. — KV5 • Talk • 20:57, 8 November 2010 (UTC)

I hope you don't mind, but as you're "test casing" the list, I've boldly converted the cells in the first column of the main table to row headers. I split it into three stages, annotated in the edit summaries, so you can see what I did. If it's too much alteration in one go, please feel free to restore the previous version. --RexxS (talk) 01:16, 9 November 2010 (UTC)

I don't mind at all, since the visual formatting still looks identical. I read this before looking at the list and was afraid there was going to be lots of extraneous bold. However, that "plainrowheaders" attribute seems to do the trick. If this sort of formatting is agreeable to all parties, I could use a hand implementing it in the other sublists (I'll take care of the main article since it's different). — KV5 • Talk • 01:50, 9 November 2010 (UTC)

We need an ACCESS person to answer an inquiry at that list's FLC: see Wikipedia:Featured list candidates/Philadelphia Phillies all-time roster (A)/archive1. Tx. — KV5 • Talk • 14:00, 9 November 2010 (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.