User:Jarry1250/RFC

This request for comment has been created in order to assess the community's position with regard to automated edits to heading hierarchies. (For some reason, RFC Bot needs this: - Jarry1250 ^{(t, c)} 20:58, 13 June 2009 (UTC).)

Behaviour of User:LivingBot

The bot would run through a list of articles where a heading level is skipped out, e.g. where a jump from a level two headings (with two equals signs before and after it). It would then "fix" this. For example, it might change an outline that went 2-2-4-4-2-2 to go 2-2-3-3-2-2. This would not involve the moving of sections, but the removal or addition of equals signs. Such an edit can be seen here.

The list being used is this one, which lists 16,000 articles. Based on the April 2009 dump, it includes 15 featured articles (though not all may still have a problem, nor had that problem when promoted).

It is worth noting that the MediaWiki software automatically adjusts these when it computes the Table of Contents for an article.

Relevant guidelines

WP:LAYOUT: "Headings are hierarchical: you should start with a second-level heading (two equals signs on each side: ==Heading==). A subsection of a section should have a third-level subheading (===Subheading===), and a subsection of one of these subsections should have a fourth-level subheading (====Subsubheading====). Between sections, there should be only a single blank line; multiple blank lines in the edit window create too much white space in the article."

WP:MOS#Section_headings: "primary headings are then ==H2==, followed by ===H3===, ====H4====, and so on."

WP:ACCESS (part of the MoS): "Headings should be nested sequentially, starting with level 2 (==), then level 3 (===) and so on (level 1 is not used, as this is the auto-generated page title), neither using random heading levels (e.g. selected for emphasis, which is not the purpose of headings), nor skipping parts of the sequence."

Positives

(submitted by User:Jarry1250)

I would say that probably the biggest argument here is one of accessibility. As one of the biggest and universally useful sites on the internet, Wikipedia is viewed by thousands of people using screen readers and other equipment. To provide these disadvantaged users with an improved level of service, the W3C (who are responsible for the happy running of the internet as a whole), advise the use of singularly incremented heading levels.

The next biggest issue is one of consistency. For example, until some edits by LivingBot, [Year] in New Zealand articles (e.g. 1913 in New Zealand) were using a level four heading for "Undated" (To subdivide "Events", a level two heading), but similar articles for the United Kingdom and Canada were using a level three heading. Of course, there is then the question of consistency across Wikipedia. The expectation is that a level two will be followed by a level three.

Nearly three million Wikipedia articles follow the existing guidelines. No consensus has yet been formed behind the idea that level four headings look better under level two headings than level three headings do. Any such shift would result in a change to global style configuration, not only a handful of pages. If it only looks better in circumstances, what are those circumstances?

Individual editors, if they would visually prefer level three headings to look like level four headings, say, can tweak their own monobook.css or similar. This is not a difficult task for a registered editor.

Negatives

• The bot's current method is imperfect. For example, its assumption that human editors get headings right relationally to each other caused the correct editing of one heading, but the incorrect editing of two other headings, here. Before the bot makes any more edits, I am happy to code it so that the bot screen-scrapes uses the API to effectively grab the table of contents before editing to make sure it never disrupts this, but that would limit the number of pages that could be fixed. (raised by User:Jarry1250)
• H3 for "undated" is totally excessive weight. (raised by User:Dramatic)
• The skipping of hierarchical levels in headings is not proscribed and is sometimes suitably crafted to structure and content. (raised by User:Tony1)
• Heading levels are visually irregular, so sometimes it's appropriate to avoid level 3 and use level 4. (raised by User:Kleinzach)
• Making value judgements about the way an article looks is really not what a bot should be doing. (raised by User:Kleinzach)
• Arguments based on semantic markup would carry more weight if HTML were capable of proper semantic markup, which it currently isn't. See an example here. (raised by User:RexxS)

Existing tools to deal with problem

"By eye" detection

Principal method in practice.

User:Proteins/mosheadcheck.js

A script that checks for MOS:HEAD violations. NB. Section headings have many pathologies beyond those discussed above. See User:Proteins/MoS_Nightmare for a sampling. For example, an H1 heading such as "=Heading=" or beginning with an H3 or H4 heading throws off the Table of Contents drastically. The code in this script may be helpful for the bot. Proteins (talk) 19:27, 19 June 2009 (UTC)

I support the bot's activities

1. As the bot operator. - Jarry1250 ^{(t, c)} 14:39, 30 May 2009 (UTC)
2. Support. There may be a few times where non-standard hierarchies should be used, but I can't think of any and those pages can use {{bots}} or {{nobots}}. That list of errors is massive and almost all of them are actually errors; if a bot can run through it and get, say, 0.5% wrong which then need to be fixed, it's still much faster and more efficient than a human editor needing to do the same thing, especially since AWB and similar tools can't fix this to my knowledge. The bug that Jarry1250 brought up should probably be fixed first, though. –Drilnoth (T • C • L) 15:06, 30 May 2009 (UTC)
3. The headings are supposed to be hierarchical, which is a major positive from both structural and accessibility standpoints. All of the "negatives" (except one bot bug which can easily be fixed) are display concerns (and either personal opinion or uselessly vague), which should be addressed by adjusting the CSS rather than by breaking the hierarchy.
   Note that there's no need to screen scrape the TOC, the API's action=parse&prop=sections will give you the needed information. But even that should not often be necessary: unless section headings are being transcluded from somewhere, just do the same thing MediaWiki does to calculate the TOC in the first place (if you need help figuring out just what that is, feel free to ask on WP:BON or on my talk page). Anomie⚔ 15:35, 30 May 2009 (UTC)
4. Heading levels should be semantic, not aesthetic. If you don't like how it looks, change your css configuration. OrangeDog (talk • edits) 00:27, 31 May 2009 (UTC)
5. Support. Would the bot also be able to convert any =H1= to ==H2== as well? -- WOSlinker (talk) 10:57, 31 May 2009 (UTC)

   Yes, the idea is to fix all heading problems, including where pages start with a level one or a level three. I have already built this functionality in, but I have properly tested it yet. - Jarry1250 ^{(t, c)} 11:01, 31 May 2009 (UTC)

6. Support. On the general principle that repetitive fixing of the same problem is best addressed by a bot. With a caveat that some exceptions may exist and the operator will need to be sensitive to objections for particular pages. I have read nothing to suggest that Jarry1250 will do other than display such sensitivity. --RexxS (talk) 19:52, 31 May 2009 (UTC)

   Indeed... and if there's a page that shouldn't be changed, {{Bots}} or {{Nobots}} can restrict the bot from changing it over and over again. –Drilnoth (T • C • L) 22:47, 31 May 2009 (UTC)

7. Shoemaker's Holiday (talk) 11:33, 1 June 2009 (UTC)
8. Support, for consistency, which makes the WikiGnome in me feel all warm and fuzzy inside. --Cybercobra (talk) 22:19, 3 June 2009 (UTC)
9. Support for consistency. If users do not like the appearance of the headings, that's not an issue at editor level. We are just to make sure they follow the hierarchy. hmwithτ 13:37, 4 June 2009 (UTC)

   FWIW, I'd say "that's an issue for Special:MyPage/monobook.css, MediaWiki talk:Monobook.css, and/or WP:VPR". Anomie⚔ 14:49, 4 June 2009 (UTC)

10. Support. It Is Me Here ^{t / c} 11:58, 6 June 2009 (UTC)
11. Support. This is the sort of standardization that allows editors (and readers) to do other things than puzzle out why/when headings are non-standard. -- John Broughton (♫♫) 17:43, 6 June 2009 (UTC)
12. Support for consistency and following discussion. ~ Amory (talk) 21:25, 7 June 2009 (UTC)
13. Support Consistent display of the material is the hallmark of careful work. We may not be professionals in the narrow sense, but the quality of the encyclopedia should be as near professional as we can get. Incidentally, I very much agree with the comment in the opposition about the over-prominence of H3's, & we should see how it can be adjusted. Skipping it isn't the way, though. (BTW, I assume the bot is intended for article space only--people should be able to arrange user space as they please)DGG (talk) 22:22, 7 June 2009 (UTC)

    Yes, article space only. - Jarry1250 ^{(t, c)} 10:10, 8 June 2009 (UTC)

14. Drilnoth hit the head of the nail on this one. Making such massive changes will inevitably result in a few errors, BUT the gains of professionalism far outweigh any minor inconveniences. For the sake of making such changes as peaceful as possible, I recommend adding a note in the edit summary stating how to bypass this change next time with {{Bots}} or {{Nobots}}. Of course, any bugs should be fixed, but Jarry seems to have both the intelligence and integrity to fix those. — BQZip01 — ^talk 23:25, 7 June 2009 (UTC)
15. Support This is a great idea! It really bugs me when anything header-related is out of line. This makes things cleaner and standardized. Can you also have the bot make sure articles' first headers are H2? That's really annoying when it goes 3-2-2... Reywas92^Talk 03:03, 10 June 2009 (UTC)

    Yes, as it stands it would also do that (and for those starting with level 1, as well). - Jarry1250 ^{(t, c)} 10:16, 10 June 2009 (UTC)

16. Sounds good to me. OhanaUnited^{Talk page} 01:24, 16 June 2009 (UTC)
17. Support—this kind of edit does not strike me as controversial, and non-controversial edits should be done by bots, if possible. —Ynhockey ^(Talk) 21:19, 16 June 2009 (UTC)
18. Support per DGG and John Broughton. -- Quiddity (talk) 23:10, 16 June 2009 (UTC)
19. Support, ideally with some kind of white list potential for if the odd exception does pop up. I find that articles differing from the norm are usually due to an individual user's personal idea of what looks better rather than even a local consensus, given the inherent triviality of the issue and the benefits of consistency, I think the bot should be allowed to operate in the way described above. Guest9999 (talk) 12:26, 19 June 2009 (UTC)

    If the issue is of "inherent triviality", why does it need fixing? Surely, that argument works both ways. And nobody has so far explained the benefits of "consistency".

    One other thing: is this a vote or a presentation of reasoned arguments? See nos. 5, 7, 8, 10, 16. -- Michael Bednarek (talk) 12:50, 19 June 2009 (UTC)

    Sorry if I was not clear. The triviality I was referring to was the trivial (and likely subjective) aesthetic improvement that occurs from deviating from the accepted norm, how we arrange content and present it in articles is not trivial. A consistent presentation gives a more professional appearance and makes the encyclopaedia more cohesive and easier for readers going from one page to the next. It is also advantageous for new editors who do not have to learn different conventions every time they wish to improve an article. Guest9999 (talk) 13:12, 19 June 2009 (UTC)

20. Support, provided that the bot is first tested thoroughly on designed "problem pages" such as User:Proteins/MoS_Nightmare and also has a "dry run" on a small set of typical articles that can be cross-checked by humans. It should be established rigorously that the bot catches the relevant problems and fixes them correctly. Proteins (talk) 19:31, 19 June 2009 (UTC)
21. Support; this class of meta-information is part of the value of structured text. Fixing it where broken is a Good Thing. — Coren ^(talk) 10:22, 22 June 2009 (UTC)
22. Support, though I have a question. If one of the reasons why this is brought up is for accessibility issues, is there a reason that the bot will be limited to articles? Surely Talk pages and WP pages should also be user-friendly? In fact, wouldn't it be prudent to test the bot on non-reader facing pages first? Still, I support use of this bot any and everywhere except User and User talk. ▫ JohnnyMrNinja 06:39, 25 June 2009 (UTC)

    Has the issue of accessability been explained? I understand why headings are important, but not how non-sequential headings are a barrier. To the contrary, I suspect that when editors replace out-of-sequence headers by other stylistic methods, like leading semicolons, to achieve their design aims, it might work against improving accessability. -- Michael Bednarek (talk) 12:16, 25 June 2009 (UTC)

23. Support except for cases where {{Bots}} or {{Nobots}} is appropriate, this should be useful.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTM) 04:44, 29 June 2009 (UTC)

I do not support the bot's activities

1. The main arguments in favour of fixing non-sequential heading levels seem to be 1) accessibility; 2) consistency. I would place very little weight on consistency if it impedes the desired page appearance; aesthetics trump semantics. Pointing to a CSS is not helpful to the vast majority of Wikipedia readers, a point that has been satisfactorily clarified during various discussions on the auto-linking of dates. Also, Tony1's point above is rather cryptically presented; if I remember correctly Tony pointed out that skipping header levels is a useful way of uncluttering the TOC when used with he template {{TOClimit}}. As for accessibility: could someone explain how a screen reader is hampered by non-sequential heading levels? (This is not a rhetorical question.) -- Michael Bednarek (talk) 06:03, 31 May 2009 (UTC)

   I have requested a full explanation from the accessibility WikiProject. In the meantime, this is an excellent primer. I'll let you draw your own conclusions. - Jarry1250 ^{(t, c)} 11:00, 31 May 2009 (UTC)

   That video can be summarised as "use headings not <p class="heading">" - which is not an issue on Wikipedia. It does not even mention hierarchy. However, on the ars technica site it showed a potential flaw: That site would have been more accessible if all the sidebar content had had a single h2 "Departments" with h3 for the regular features rather than making the user step through all of them to get to the main page content. A good example of Undue weight. Note that accessibility tools are not just for users with disabilities. I use the (manually re-enabled) E and D keys in Opera to quickly skip around pages, especially wikipedia talk pages with loooooong discussions. dramatic (talk) 20:18, 31 May 2009 (UTC)

   Okay, a couple more quick things. Tony's point was not drawn from the VPM discussion but is an actual quotation from a user talk page. Secondly, a little more on the accessibility side of things, it's a debated topic, I'll acknowledge that, so we'll wait to see if we get any compelling arguments for or against. - Jarry1250 ^{(t, c)} 11:26, 31 May 2009 (UTC)

   I mentioned {{TOClimit}} on VPM. I think you should assume that if a page has this template, editors have made choices. Whatever else may be decided, these pages should be excluded. This is about ~1250 articles currently. Gimmetrow 16:32, 31 May 2009 (UTC)

   I am happy to do that. - Jarry1250 ^{(t, c)} 16:35, 31 May 2009 (UTC)

   How exactly do non-sequential headings help hide anything using {{TOClimit}}? When I try it, it doesn't seem to do anything of the sort. Anomie⚔ 02:00, 1 June 2009 (UTC)

   (not answering the question; just adding a comment): I think that the TOC interprets technically incorrect section headers in a way that tries to correct them for the purpose of the TOC... in Anomie's example, then, the TOC treats the second level 4 header as level 3 since an actual level 3 header is missing. –Drilnoth (T • C • L) 02:02, 1 June 2009 (UTC)

   It does; if you speak PHP, details are at User talk:Anomie#Table of Contents, etc, etc.. Someone above claimed {{TOClimit}} as an excuse for non-sequential headings, but unless I'm missing something that's clearly ineffective. Anomie⚔ 03:03, 1 June 2009 (UTC)

   I stand corrected, although one might suggest that this exposes a flaw in the Wikimedia software when it places an item clearly marked with <h4> into the TOC against the instruction in {{TOClimit|3}}. After viewing the above mentioned video (which did not address or criticise non-sequential headings), it occurred to me that a common alternative to skipping a level is to use the Wiki markup ; (leading semicolon) to bold an entry. In the light of that video, that's clearly not a helpful alternative. (I also apologise to Gimmetrow for my misattribution.) -- Michael Bednarek (talk) 03:42, 1 June 2009 (UTC)

   Interesting find. I'm sure I'm not the only one who was under the impression {{TOClimit|3}} excluded any level4 header. Perhaps it worked that way once. The actual behaviour shown in Anomie's link is, I think, non-intuitive, since the behaviour isn't a simple "local" dependence, but depends on interactions among headers. Notice for instance that removing the second level2 header (going from 2-3-4-2-4 to 2-3-4-4) makes the second 4 disappear. Gimmetrow 13:28, 20 June 2009 (UTC)

2. Heading levels are indeed semantic, and should be arranged so that subdivisions of similar importance in different sections of a page have the same heading levels and that relatively unimportant subdivisions are not elevated simply because the section they are in has no level 3 subdivisions. There are definitely headings which contribute nothing but bloat toe the TOC. As for the "Undated" headings in almanac pages, the corresponding heading "Dated" doesn't even exist in most instances. dramatic (talk) 08:50, 31 May 2009 (UTC)
3. (Placeholder for Kleinzach, who does not wish to comment here but has asserted his opposition at WP:VPM and elsewhere.) - Jarry1250 ^{(t, c)} 10:12, 1 June 2009 (UTC)
4. Default wikipedia skin, for some unknown reason, presents L3 headings fatter and bolder than L2. As long as this inconsistency is in place, avoid using L3. Fix this fundamental eyesore first. Yes, I know, registered user can tweak the skin anyway they want it, but think of unregistered readers. NVO (talk) 18:10, 3 June 2009 (UTC)

   Maybe that's your computer; I don't really see that. Anyway, I'd think that that is really an issue for the developers to deal with, and consensus is certainly not for never using L3 headers. –Drilnoth (T • C • L) 15:45, 4 June 2009 (UTC)

   Maybe the headings will change when Wikipedia gets a redesign; for the moment, though, wouldn't it be best to repair the walls before worrying about the paint job? - Jarry1250 ^{(t, c)} 15:56, 4 June 2009 (UTC)

5. This sort of bot activity is going to irritate some editors and doesn't achieve anything terribly worthwhile (I skimmed the reference given to support the accessibility issue, and it did not seem much of a recommendation to me). I did not read all of WP:ACCESS, but it seemed to rule out obvious stupidity (no heading, h3, h2, h4); I did not see where it rules out consistently using h4 instead of h3. I have never wanted to skip h3, but there are bound to be editors who have done that, and who care – why irritate them? If the bot supporters want this, please get it unambiguosly written into a policy first. Johnuniq (talk) 08:49, 7 June 2009 (UTC)

   To be fair, I don't think the policy route is advisable (WT:ACCESS has some on this, IIRC). The existing guidelines seem pretty explicit though. Given the constant crippling internal conflicts with the W3C, it's surprising that they manage to decide anything at all, and strong, explicit statements are invariably out-of-bounds for them (think League of Nations during the 1930s). Out of interest, would you be annoyed if the bot edited an article you hard worked on? What if there had been an RFC, demonstrating consensus for the change? Would that lessen the irritation? - Jarry1250 ^{(t, c)} 10:14, 7 June 2009 (UTC)

   I'd sooner see a bot make a list of articles with these conflicts, and leave it to humans to fix. It's not hard or even that tedious, but is definitely something (as the examples you provide show) that a human eye will, for the time being, be better equipped at fixing (or not fixing, as the case may be). ~ Amory (talk) 18:16, 7 June 2009 (UTC)

   If you scroll up there's a link to the list of pages with this scenario. The present figure is between 15,000 and 20,000 IIRC. But what decision making process would the human follow? - Jarry1250 ^{(t, c)} 18:20, 7 June 2009 (UTC)

   Yes, and that's a pretty crappy list: it's a large burden to load, is offsite on toolserver, and has no wikilinks. For people to be interested, it has to be manageable and easy to navigate. It's not an issue of what decision-making process a human uses, it's an issue of the decision-making process the bot uses. The issues raised are, to me, an indication of the obstacles to cross - it's clear that there isn't a clear-cut methodology to apply across the board. I'd be happier if the bot were extremely conservative in its edits (any chance of confusion and no change). ~ Amory (talk) 19:17, 7 June 2009 (UTC)

   Agreed that it's not a very good list from an editor's point-of-view, but however small the manageable chunks you group it into (not per se a bad idea), 16,000 pages is an awful lot to expect volunteers to sift through manually. The bit about decision making process sort of came across wrong, I'll put a bit about it on the talk page. I think what I can guarantee is that the bot (based on the concerns raised above) would be pretty conservative - what with checking the ToC before and after and all. - Jarry1250 ^{(t, c)} 19:23, 7 June 2009 (UTC)

   Presuming that, I'm removing my oppose. ~ Amory (talk) 21:23, 7 June 2009 (UTC)

6. I'm too concerned that this bot will unintentionally break many episode articles in which headers may be deliberately set "off" a bit for transclusion purposes. Would need to see more evidence that it will not do this, and that it can correctly ascertain what the proper levels should be (i.e. level 1s fixed to level 2s then so forth?) -- Collectonian (talk · contribs) 13:47, 16 June 2009 (UTC)

   Do you have an example of these episode articles you're concerned about? As for the other, I believe Jarry plans to have it query or calculate the TOC as displayed by MediaWiki, and then adjust the heading levels to match. Anomie⚔ 13:59, 16 June 2009 (UTC)

   Indeed. I'm not sure whether it's using the most up-to-date of my code (and it's definitely not checking the ToC yet), but I do have a "simulator" - http://toolserver.org/~jarry/headliner.php?page=sausage - the output of that is "fixed" code. Incidentally, you're welcome to CTRL-F the toolserver list to try to find examples, and I'd be happy to work them in. Exclusion for pages containing <includeonly,(t, c) 17:11, 16 June 2009 (UTC)

   List of Dragon Ball episodes is one. Its sublists, such as List of Dragon Ball Z episodes go from header 2 (episode listing) to header 4 for the arc names, so that the headers also stay at a proper level in the main episode list. -- Collectonian (talk · contribs) 01:51, 17 June 2009 (UTC)

   My first thought on that example is "Why is an article being transcluded?" They really shouldn't be... if most of the content should be in another article, just merge them. However, I know that this is used sometimes... maybe having an exception to exclude pages with the <includeonly>, <onlyinclude>, or <noinclude> would fix this. –Drilnoth (T • C • L) 01:56, 17 June 2009 (UTC)

   Transclusions are used with almost all episode lists that have been split into individual season/series/arc type lists. This avoids having to maintain the title/airdate lists in two places. Quite common really, for these type lists, and a perfectly acceptable and allowed use of transclusions. Merging is not really an option as that isn't how the content is used. -- Collectonian (talk · contribs) 02:00, 17 June 2009 (UTC)

   That is an odd case. It would be nice if some solution could be found that didn't require skipping levels, but if not I would have to support the exception for these lists. Anomie⚔ 02:39, 17 June 2009 (UTC)

7. I use H2 followed by H4 all the time, for a wide variety of reasons. I don't want a robot telling me I'm wrong to do so, based on a pedantic interpretation of HTML no-one follows in the first place. Maury Markowitz (talk) 13:51, 16 June 2009 (UTC)

   And these reasons are...? Anomie⚔ 14:00, 16 June 2009 (UTC)

   What Anomie said. Personally, as a coder, my brain hurts when they don't go h2-h3-h4. Plenty of people follow it. –Drilnoth (T • C • L) 19:00, 16 June 2009 (UTC)

8. Do not support. Let individual pages decide readability. There's no compelling reason to do this. JoshuaZ (talk) 15:29, 16 June 2009 (UTC)

   More of a side point really, but doesn't Wikipedia have pages and pages of guidelines specifically so it feels like a consistent encyclopaedia and not a collection of "individual pages"? Would you extend the whatever's best for readability argument to all style guidelines? - Jarry1250 ^{(t, c)} 15:50, 16 June 2009 (UTC)

9. Do not support. The bot is trampling choices that may have been made for aesthetic reasons. I'd add that zero Wikipedia users are being confused or annoyed by this "problem", causing me to label this proposal a solution in search of a problem. Tempshill (talk) 20:30, 16 June 2009 (UTC)

   (The bot is not currently operational, for the record.) In response to "zero Wikipedia users are being confused or annoyed by this 'problem'", would you have evidence to support that viewpoint? There are currently 16 supports above which is at least > 0 people. As for people using screen readers, I would think it would hard to gauge what they would think, given that we're not them; the best idea would be to look at the consensus-based MoS and the much further reaching W3C, no? That's my reply, anyhow. - Jarry1250 ^{(t, c)} 20:36, 16 June 2009 (UTC)

   As Jarry1250 said, there's a number of users who have already supported this... more than 0. As to what the problem is: Accessibility, standardization per both WP and W3C standards, and maybe some less confusion for newbies. This would seem to be the most appropriate solution, although doing it all by hand can be tried, too. (although see the talk page for my reasons as to why I feel that that would be unfeasible). –Drilnoth (T • C • L) 21:01, 16 June 2009 (UTC)

10. Do not support - the benefits seem slim, and bots can be so intrusive. It would be nice to see a list of candidate edits, to see how many "false positives" there are. One obvious concern is that if you have a sequence like H1-H2-H3-H3-...H2-H3-... and for some reason the first H2 gets deleted, then suddenly all the following H3s get promoted. Which is wrong, because semantically they're H3s, and they're at the same level as all other H3s in the document. The error in that case is not "headings at wrong level", it's "missing H2". So to "fix" the error by promoting the H3s is wrong. But again, need stats on false positives. On the whole when something has gone wrong, it should look wrong, not be fixed the wrong way. Stevage 12:08, 26 June 2009 (UTC)

Ok, the first article in the list provided is KOFY-TV. I see the "error" but I don't know if I would fix it. A big section of the article goes H2-h3-h4-h4...-h3-h4... Then a smaller section goes H2-H4-H4... The H4 sections in that section aren't as semantically big as the H3's in the previous section, so it certainly seems arguable to leave them that way. Maybe the argument would be lost, but I don't see this as an open and shut case for every article. Stevage 12:12, 26 June 2009 (UTC)

Objection

IMO, this Rfc shouldn't have been set up in the obscurity of a user page, where it is under the control of the user and can be deleted. Moreover the subject of debate was never announced at Requests for comment/Policies (where of course no other userpages are listed). It would have been better to continue the discussion set up by User:Jarry1250 at the Wikipedia:Village_pump_(miscellaneous)#Headline_hierarchies — or announce a fully centralized debate to elicit a range of opinions. Thank you. --Kleinzach 10:18, 4 June 2009 (UTC)

It is on WP:CENT... –Drilnoth (T • C • L) 15:43, 4 June 2009 (UTC)

(edit conflict) Personally, I don't think "obscurity" equates to having a link on WP:CENT; also, you'll notice this page is in fact listed at the RFC/Policies page and has been for four days. Regrettably, a decent description of the RfC was wiped later the same day by the bot, because of a change in operation (or a malfunction, I suppose). Also, I'd like to see how this page is in my control; last time I check I wasn't an admin, and admins are only human and unlikely to delete RFCs just like that. Anyhow, I'm happy to assure you that this pages is not going to get deleted any time soon. And, by the way, there have been many previous instances of RFCs in userspace - one request for input is going on in Mikaey's userspace right now in fact IIRC. Hope that answers your queries, the debate's now that away ^. - Jarry1250 ^{(t, c)} 15:53, 4 June 2009 (UTC)