Wikipedia talk:Categories, lists, and navigation templates/Archive 10

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5 ← Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 → Archive 15

Template/navbox cages

On my sojourn to templates I've often found one of these cages:

and have long-thought that they do not give templates the respect that other parts of a page receive. Templates often seem to be second-class nephews of third-class citizens, and in terms of collapsed space a boatload of templates take up the same room as Categories, External links, notes, or many other article sections. There are only five templates on the Ireland page (only four added if you take away the "Articles related" cage, which I've done), and, for example, a recent discussion at the Lincoln Memorial page brought a solution of one template showing with three in a box labeled 'Memorials'. I believe that if templates are presented well that many can be shown without having to hide them away. Six or seven templates, easily, can be shown collapsed and not take up very much room, and some pages can use many more. One of my favorites, and I won't mention it for fear of someone caging it, has nine templates in an accidently beautiful design. I've often even found the template of the prime topic of a page hidden in one of those template-black-holes. My question: Can we guideline many of these 'Related article' cages out of existence and allow a good amount of space for collapsed appropriate templates on appropriate pages? Thanks. Randy Kryn 20:12, 28 July 2015 (UTC)

Guidelines are descriptive. ;)

That said, I typically remove these where I see them surrounding 4 or 5 or so, but once past that count you're at the point where the question you should really be asking yourself is whether all of the navboxes on the page in question are appropriate. Bidirectional helps in this case. --Izno (talk) 20:22, 28 July 2015 (UTC)

I agree with Izno. 4-5 templates don't normally need to be "caged", but that navbox wouldn't belong on Ireland anyway because of WP:BIDIRECTIONAL. --Rob Sinden (talk) 07:58, 29 July 2015 (UTC)
Per WP:LTAB, tables should not be used for layout purposes. If {{Navboxes}} is to be kept, it should be rewritten to use proper markup. Alakzi (talk) 09:53, 29 July 2015 (UTC)
Layout in the context of the guideline is in the same context as in the HTML specifications, not in the more general understanding of "layout". For example, using a table to position an image next to some text or another is what is banned. T:Navboxes is fine, unless you have a problem with navboxes (lowercase) as a whole from a semantic point of view (since navboxes would more properly be lists of lists, not a table). --Izno (talk) 16:25, 29 July 2015 (UTC)
{{Navboxes}} is simply a container for {{Navbox}}es. Unlike a navbox, {{Navboxes}} is not a data table. Alakzi (talk) 16:28, 29 July 2015 (UTC)
T:Navbox is really a layout table, not a data table (and just about everyone familiar with HTML specs in the context of Navbox recognizes that). The problem you would face in attempting to see the html structure of T:Navboxes changed would be that there are a good number/chunk of users who use T:Navboxes without encapsulating all of the relevant navboxes on a page inside of it (which is a valid use case). Good luck. --Izno (talk) 16:31, 29 July 2015 (UTC)
I'm not sure why that should matter. Alakzi (talk) 17:23, 29 July 2015 (UTC)
"That" is ambiguous. The use case? You upset the set of users without any particular good reason (you can argue semantic HTML, but 1. navboxes as a whole are offensive on this point and 2. the users in question don't care so long as the reader-facing implementation is the same). So if you can demonstrate that item 2 is satisfied, I don't foresee an issue, but a "this should change" without knowing whether it can be changed is a little off-the-mark. --Izno (talk) 17:43, 29 July 2015 (UTC)
{{Navbox}} can be liberally described as a data table. At the very least, it's got key–value pairs. I'm not sure where I might've suggested that the behaviour of {{Navboxes}} would change. Alakzi (talk) 17:50, 29 July 2015 (UTC)
Conservatively, it can be described as a layout table, since it is (most commonly) a list of lists (which would more properly use list markup).

You nowhere explicitly made that suggestion, but I'm however unsure that you considered the implications of the broad "thou shalt be Semantic" edict. As I suggested, if you think you can duplicate T:Navboxes's behavior (presumably using <div>)s, have a go at making the suggestion; otherwise you're going to get shot down since the template uses a well-established metatemplate. --Izno (talk) 12:51, 30 July 2015 (UTC)

I don't recall having asked for lessons in consensus-building, nor do I hold any edict dear. Collapsible boxes can be built with <div>s, though we'd probably need to make some changes to the navbox class in MediaWiki:Common.css. Alakzi (talk) 12:57, 30 July 2015 (UTC)

Just took away a template cage which held two templates. The main reason I brought this up was to point out that the main purpose of these one-line template-holders, especially if there are six or less collapsed visible templates, is to hide templates/navboxes. Should they be hidden? Of course not, they are a valuable part of the articles, and appropriately used they expand the readers options to learn much more about a subject than a single article, no matter how good the page is, will give them. So it's a bottom-line matter of template respect. For those of us who enjoy and work on templates their beneficial properties are obvious, and making readers aware of this available resource will improve their usefulness. To do so they must be visible, just as every other section of the page is visible. Question, are templates sometimes featured on the main page, either as the daily feature or as an additional item for readers to browse? Thanks. Randy Kryn 11:40, 30 July 2015 (UTC)

To answer your question, no. I see little reason to do so. --Izno (talk) 12:05, 30 July 2015 (UTC)
If one or more became featured articles (I know templates aren't considered 'articles' but does that eliminate them from feature contention?) it would expose more people to them. The fact that many editors enclose templates in the one-line navbox shows that they do not have the respect of the community, and this might be so ingrained that even people who work on templates accept it. But back to the topic, do you have a suggestion for guideline language which would limit the use of the one-line enclosure which we can formally put up for discussion? I'd say something like allowing six collapsed appropriate templates/navboxes before the use of the enclosure, with more allowed if applicable and nondisruptive to the page (some sports pages have a dozen or more templates, which seems excessive). Randy Kryn 12:14, 30 July 2015 (UTC)
I think it depends on the size of the article and relevance of the navboxes. A stub article would have a lower threshold than a large article. And things like awards navboxes should probably always be "caged" unless there are just one or two. --Rob Sinden (talk) 12:21, 30 July 2015 (UTC)

Readers don't see templates (or don't realize they are templates--this is A-OK IMO). The reason you see T:Navboxes used so often is because of writers being somewhat protective of how much information is displayed on the articles of choice they edit.

I would suggest that further discussion about T:Navboxes be at template talk:navboxes for an update of the associated documentation (or possibly at WT:NAV. Placing usage information here would be somewhat out of scope for this page (at present) since it mostly covers the differences and reasoning you would use a particular type of organization rather than guidelines for each specific to each (a fact that depresses me to some extent since there should be guidelines for such). --Izno (talk) 12:51, 30 July 2015 (UTC)

Those protective writers are just the point, that the respect for templates/navboxes is hindered by the overuse of these one-line cages (I know cages is an emotional word, but seems descriptive of what occurs), so a guideline is probably needed. Discussing that guideline here might be a better, or as good of, a place, because this page governs guidelines concerning the templates. Why don't we work on language and then alert both pages, but the point of this request is to see what kind of consensus comes from it. Thanks, and your comments do move the process along. Randy Kryn 13:32, 30 July 2015 (UTC)
Maybe some editors don't like navboxes because a lot of them are bloated with information text, images, external links and other clutter, so that's why they hide them. --Rob Sinden (talk) 13:47, 30 July 2015 (UTC)
That's a reason, disregarding the pointy language 'bloated' and 'clutter' (replace with 'data' and 'wow, look what's available to me! Thanks Wikipedia!'), if the templates were expanded on the page, not collapsed. If there happens to be one expanded template, say the template for the subject of the page, along with three or four collapsed templates, then those other could either be in plain sight or, depending on context and appropriate connection to the subject, within the one-line box. Randy Kryn 14:00, 30 July 2015 (UTC)

Template:Orson Scott Card

Any thoughts on how to improve this further? See Template talk:Orson Scott Card#Massive tidy-up. Also, given our discussion about images, should we include an image? --Rob Sinden (talk) 14:51, 12 August 2015 (UTC)

{{clarify}}

I just removed the {{clarify}} next to WP:NAVBOX 3.

I just wanted to clarify that navboxes should be created and used only if there is added navigational benefit. Otherwise, as editors we should defer to WP:NAVBOX 5 because we can simply create "list of ... articles".Curb Chain (talk) 21:03, 25 August 2015 (UTC)

An example would be List of laser articles.Curb Chain (talk) 05:05, 26 August 2015 (UTC)

Linking to other navboxes from navboxes by transcluding templates with links to navboxes

Comments welcome at Wikipedia:Templates for discussion/Log/2015 October 20#Various regional radio station templates within templates. --Rob Sinden (talk) 16:55, 26 October 2015 (UTC)

WP:BIDIRECTIONAL navbox requirements

STATUS QUO
The two aspects of this RfC can be summarized as follows:
  1. WP:BIDIRECTIONAL is a guideline-level recommendation that like any guideline-level guidance has occasional exceptions.
  2. WP:BOTS are not suitable to enforce this particular guidance on a Wikipedia-wide scale.
--Francis Schonken (talk) 12:44, 19 December 2015 (UTC)

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

In response to a couple of instances where bot requests have been made for mass-removal of navboxes from articles on which they're not bidirectional, I wanted to double check that WP:BIDIRECTIONAL was actually a valid, consensus-backed portion of this guideline and not simply something that creeped in and stuck around—at least, before approving any more bots based on the assumption that there's consensus for it (as each subsequent bot could be affecting thousands of pages). It was added in this edit without objection or support a few years ago, and while silence can be assumed to be consensus (plus it's been a while), it would help to have a definitive answer when dealing with subsequent bot requests (at the very least). Additionally, it appears that a few edit wars have happened over the years in relation to it, possibly grounded in a false assumption of original consensus.

Main questions
1. Does the current text of WP:BIDIRECTIONAL have broad consensus as part of this guideline? ("BIDIRECTIONAL has consensus in this guideline," below)

"Every article that transcludes a given navbox should normally also be included as a link in the navbox so that the navigation is bidirectional."

— WP:BIDIRECTIONAL current text

2. Do navboxes containing a List imply that a member of the List can be treated as if it were linked from the navbox? ("List members are valid exception," below) For example, if {{Cool Stuff Navbox}} contains [[List of frozen things]], which contains [[Ice cubes]], should it be assumed that {{Cool Stuff Navbox}} can be placed on [[Ice cubes]]?

3. Can the Bot Approvals Group (BAG) assume, in the future, that there's community consensus to approve bots that reflect these guidelines without individualized consensus for each case/template? ("BAG can assume there are rarely exceptions," below) An example of such a request (actually, what prompted me to double check) is Wikipedia:Bots/Requests for approval/KoehlBot, which seeks to remove {{Zoos}} from articles not directly listed in the navbox. Note this question is directly dependent on the consensus of #1 and/or #2, so you don't have to re-hash arguments from either of them. It's more a gauge of how strongly the result can be implemented. For example:

  • If #1 has support, AND you support this question, then we'll assume that bot requests that seek to enforce #1 (like the aforementioned example) have support by default (regardless of the navbox).
  • Similarly, if #2 has support AND you support this question, we'll by-default seek to ensure that bot requests take inclusion of a member article in a list into consideration so as to avoid accidental removal of a navbox from that member, too (unless there's consensus to the contrary).
  • Opposing this question will encourage the BAG to make sure any bot request pertaining to BIDIRECTIONAL gains some sort of individual consensus each time (e.g., on a template talk page or wikiproject). That is, we'll assume there are frequent exceptions to the guideline, which necessitates that each request should probably double check with the template's talk page and/or associated Wikiproject(s) to ensure mass removal is what's appropriate for that instance.

Thanks for your help, guys, and cheers =) --slakr\ talk / 04:09, 19 November 2015 (UTC)

Some discussions
Some essays


1. BIDIRECTIONAL has consensus in this guideline

Support 1

  1. Yup, number me among the bidirectional crew. It aids the UX by providing a common location to browse from/to all of the related pages. --Izno (talk) 04:35, 19 November 2015 (UTC)
  2. Support, as this should be the purpose of having a naxbox. —⁠烏⁠Γ (kaw) │ 05:18, 19 November 2015 (UTC)
  3. Support produces a consistent and predictable navigational experience. The purpose of a navbox is to aid navigation between closely related articles and this is easier if the templates are bidirectional. The bolded self link in bidirectional navboxes also provides an important visual clue as to the most closely related articles to the one one that is presently being viewed. Finally bidirectionally reduces the tendency for template creep. Boghog (talk) 06:33, 19 November 2015 (UTC)
  4. Support If the article isn't in the navbox, then don't place the navbox on that article. Why someone would spam hundreds of pages with the zoo navbox is beyond me. Lugnuts Dick Laurent is dead 14:08, 19 November 2015 (UTC)
  5. Support the words "should normally" just makes this a suggestion and not a hard fast rule. This is how it should be.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:58, 19 November 2015 (UTC)
  6. Support. The purpose of a navbox is to provide a common set of links to a series of related pages. It just makes sense that those pages would have the navbox, and that the navbox would contain links to those pages.oknazevad (talk) 19:05, 19 November 2015 (UTC)
  7. Support Not convinced there is a general problem is. The opposers all seems to say there are exceptions, but there is always WP:IAR.—Bagumba (talk) 06:56, 20 November 2015 (UTC)
  8. Support. If we don't follow the bi-directional rule, then the navbox is not performing its navigational function properly. Guideline states that Navigation templates are a grouping of links used in multiple related articles to facilitate navigation between those articles within English Wikipedia (emphasis mine). If we start adding navboxes to articles that are not included then we are not using navboxes for their specified purpose. --Rob Sinden (talk) 08:59, 20 November 2015 (UTC)
  9. Support. A well-designed navigation system should conform. Following a navbox link that does not support a breadcrumb back home is more confusing than leaving some information two clicks away. — Cheers, Steelpillow (Talk) 11:32, 22 November 2015 (UTC)
  10. Support, navigational templates are for navigation, not a substitute for list articles or prose. Frietjes (talk) 23:38, 23 November 2015 (UTC)
  11. Support - Possible "normally" should be changed to make it clear that there can be exceptions without reaching back to the page about guidelines, but I don't have any objection to this wording (i.e. "normally" does allow for exceptions). — Rhododendrites talk \\ 06:05, 27 November 2015 (UTC)
  12. Support. Since it is a guideline, and since no proposal to remove it has been supported by a consensus, it is obvious that this is a consensus-based guideline. We don't need to check periodically whether there is still consensus. Consensus is there until we explicitly reach another consensus. Vanjagenije (talk) 20:42, 29 November 2015 (UTC)
  13. Support. This just makes sense. Without the guideline, we would get even more linkcruft on obscure unnecessary templates. --Tt(talk/contribs) 03:21, 8 December 2015 (UTC)

Oppose 1

  1. There should be exceptions, topics such as {{Zoos}} where there are close to a thousand articles which are very closely related to the subject template but are not placed on it individually. Bi-direction, taken literally by editors who can use this guideline to delete information, will result in the removal of knowledge from Wikipedia's topic-collection, and can lead to the closing-off of useful data pathways. Bi-direction might be fine if items in lists are included in the template pool, but I see that this multi-question survey is also trying to make a rule on including or not including templates on items in related-lists, and if that "fails" then we are either stuck with adding every item on a list to the template or leaving our readers with a truncated Wikipedia experience. Randy Kryn 9:45, 19 November 2015 (UTC)

    You present a false dichotomy at we are either stuck with adding every item on a list to the template or leaving our readers with a truncated Wikipedia experience. A third answer (there may be others) could resolve in creation of any number of a constellation of navboxes which include more discrete-topic linkage. --Izno (talk) 14:16, 20 November 2015 (UTC)

  2. There are always going to be exceptions, and there are a number of "macro" navboxes that could meaningfully inform readers of smaller subtopics, but not reasonably include a link to every article its on (for instance, the United States Military navbox is massive, and could reasonably include too many more links). Sadads (talk) 15:09, 19 November 2015 (UTC)
  3. Oppose: Bidirectionality is a guideline with LOCALCONSENSUS within the people who work on the template and generally contains good advice for how to usually do a navbox, but there are a number of exceptions to this rule, particularly where bidirectionality is accomplished via a link to a list article (which then may contain hundreds of entries). To have a bot going around and screwing up a lot of templates that have been stable for years is a very bad idea. Montanabw(talk) 16:54, 19 November 2015 (UTC)
  4. Oppose: Many many many cases where just parent articles have nav templates to sub articles to help with navigation. Thus far this part of the guide has caused problem after problem with deletion of valid navigational aids because on non-compliances. Now there is a bot? crazy disruption will issue. As for the the idea its self...a guidelines should never override our underlying principle that editors may use their discretion to help our readers navigate topics . Simply a dumb rule to aid those in deletion talks....not a rule to help our readers/editors aid in navigating topics. Saying something must be used all over when there may be no need is simply not the type of thing we should be saying. Leave it to editors sense over bureaucratic creeping. No need for a rule that promotes template spam as seen at Michael Jordan#External links -- Moxy (talk) 18:01, 19 November 2015 (UTC)
    How can a guideline whose practical effect is to limit navbox transclusions increase navbox spam? In fact, application of this guideline has just the opposite effect, to reduce navbox spam. Also it is important to keep in mind this is a guideline, not a rule that includes the phrase "normally". Boghog (talk) 05:57, 20 November 2015 (UTC)
    Its very easy as seen linked above... hundreds and hundreds of links over 50 templates all because hes names in them? (majority not leading to info about him)....we should be saying something like "just because a template has a link to an article care should be taken in its placement in said article" not the other way around - as is implied by the current wording. We end up with template spam on a mass scale sometimes as seen above over care to make sure the template has merit to be all over the place. -- Moxy (talk) 07:09, 20 November 2015 (UTC)
    Michael Jordan is a problem, but his article is also an extreme exception. Is it possible the guideline is generally fine, but more guidance is needed on handling common exceptions?—Bagumba (talk) 07:42, 20 November 2015 (UTC)
    Agreed. The guideline contains the qualifier "normally" and clearly this is not a normal case. As with any guideline, common sense applies. Most of these navboxes were added to the Michael Jordan article before the guideline was created and other than hypothetical speculation, no one has actually invoked BIDIRECTIONAL as justification for retaining all of these navboxes. Quite to the contrary, the application of bidirectional with common sense raises the following question. Do we really need all of these navboxes to begin with? The problem has more to do with the excessive number of navboxes, not with the guideline per se. Boghog (talk) 11:20, 20 November 2015 (UTC)
    As has been seen at that talk page ...yes the fact hes name is in the 50 plus templates is a reason why they are there....no mention merit to our readers...just templates with his name leading to articles that dont metion him in anyway. -- Moxy (talk) 17:19, 20 November 2015 (UTC)
    Some projects use navboxes in lieu of succession boxes. Some would argue to use succession boxes, but that wouldn't solve the general issue of clutter for exceptional cases like Jordan. There needs to be more restraint on which navs/successions boxes should be created/included.—Bagumba (talk) 18:49, 20 November 2015 (UTC)
    Agree 100% with "There needs to be more restraint on which navs/successions boxes should be created/included." ...simply no need for a bidirectionality rule ...instead we "should" mention discretion on there creation and placement.-- Moxy (talk) 21:23, 20 November 2015 (UTC)
    Actually, the current wording is Every article that transcludes a given navbox should normally also be included as a link in the navbox. It doesn't say that every navbox should be transcluded on each article, although that is normally how it works in practice. --Rob Sinden (talk) 12:00, 20 November 2015 (UTC)
    As you have stated and that we can all see it says "should"....no mention of merit for inclusion. Its clear here that consensus is not what it appears to be. The wording needs to be fixed/changed from "should normally" (Used to express obligation or duty) to "generally are" (Used to express ordinary usage without commitment). The other type of problem we have is with edits like this ...removal of links because someone does not like the template placed in the actors articles... rule is being invoked to remove templates from said articles despite our guideline on the matter about the links WP:ADVICEPAGE. Best to leave the links and simply remove from the articles in-question if template spam is the problem....no need to go out of your way to unlink valid content because of BIDIRECTIONAL. Its a rule used for those to imposes there POV over the normal operational spirit of Wikipedia. -- Moxy (talk) 17:19, 20 November 2015 (UTC)
    I'm pretty sure a large number of editors interpret BIDIRECTIONAL to mean that every page that is linked in a navbox must also tranclude the navbox. If there is consensus that this should not necessarily happen in extreme cases like Meryl Streep, perhaps explicit verbiage should be added to avoid the misconception.—Bagumba (talk) 21:49, 20 November 2015 (UTC)
    Meryl Streep is a good example of wrong placement just because her name is there... all are at List of awards and nominations received by Meryl Streep were they should be if at all. The Meryl Streep article is not about awards or those that have received the same honour...again BIDIRECTIONAL being used for template spam over helping our readers navigate...having thousands of links to unrelated names does not help.... but infacts impends those looking for related links. -- Moxy (talk) 22:11, 20 November 2015 (UTC)
    Navboxes with annual award winners are typically used in lieu of succession boxes, which leaves a footprint in either case. The biggest question would be whether a navigation to other winners of an award (whether it be navboxes or succession boxes) is essential to readers, and what is the threshold of inclusion?—Bagumba (talk) 22:40, 20 November 2015 (UTC)
    In the specific case of Template:Walking Tall, I don't think the navbox should included topics whose notability is not defined by Walking Tall. We need better guidance on how to avoid navboxes becoming a dumping ground for inclusion of any and all tangential topics.—Bagumba (talk) 21:56, 20 November 2015 (UTC)
  5. Oppose as stated there are lots of examples where a navbox would benefit an article, but where if every article was linked in the navbox it'd be very unweildy. --Tom (LT) (talk) 23:55, 19 November 2015 (UTC)
  6. Bidirectional navboxes is a good thing that -quote- "should" often be done. And I'm seeing reasonable arguments to only use them that way. However there clearly do exist nav boxes that don't follow that as a rule (like zoos), people are giving good arguments for them, and I'm leaning towards agreeing with use cases that don't follow that rule. But primarily I'm opposing the idea that this has broad consensus as a hard rule. Offhand, I have no idea what a compliant-solution would look like for zoos. Discussions could be started on some of the major non-complaint navboxes. That would provide more clarity on whether they should be brought into compliance, and if so, to figure out how those cases would be resolved. If some major "offender" navboxes get consensus for "fixing", then it could make sense to try to apply this as a firm general rule. Alsee (talk) 15:33, 20 November 2015 (UTC)
    Again, please keep in mind that this is only a guideline and not a hard and fast rule. It is easy to imagine how a compliant navbox would look like. In fact {{Zoos}} is currently compliant since it was removed from pages that were not included as a link. An alternative would be to add links to each of the pages that the template was included. However this would a have produced a navbox with over a thousand links which most would agree would be excessive. Most of these previous transclusions were on individual zoos articles (e.g., Augsburg Zoo). An alternative to placing {{Zoos}} on each of these pages is to have a set of navboxes, one for each country or state, for example {{Zoos of Germany}} or {{Zoos of California}}. Please note that the more specialized Zoos navboxes also contain a link to Zoo on the left hand side of the template so that one can easily navigate up one level in the template hierarchy. Technically, this link is an exception to the guideline, but a reasonable one. In fact, we probably should explicitly mention that the guideline does not apply to links to the more general subject in template headers and footers . Boghog (talk) 15:18, 22 November 2015 (UTC)
    We already do this, and I agree that it should be an explicit exception. However, it is currently being challenged, which just shows how contentious this particular guideline has been, and still is. Don Lammers (talk) 15:16, 25 November 2015 (UTC)
  7. Oppose Per LT910001. BMK (talk) 06:04, 22 November 2015 (UTC)
  8. Oppose because "support" here (despite the actual wording containing "normally") seems to imply that there should be no exceptions. Although I think bidirectionality is good in general, I don't think it's likely that there will be no exceptions. Also, after reading the other discussions that have taken place around this issue, there doesn't really seem to be global consensus to change the wording and make it stricter. Several years ago we moved away from the Zoos navbox in all zoo articles (and unfortunately I failed to update the directions in the Zoo project) in favor of just a few links in the "footer" of the "Zoos of <jurisdiction>" templates. This was intended to replace the need for those items in the See Also section, ease maintenance, and make sure the links were in all individual zoo topics. The very local discussion at that time can be seen at Wikipedia talk:WikiProject Zoo/Archive 3#Zoos template. The footer is currently being challenged as well (in that it doesn't contain specific enough links). My personal opinion (and it is just that) is that at least some of these links should be in the individual zoo articles for better access to the general topics (rather than going up to "Zoos" and back down). The only practical way to do this and keep the lists consistent over 1000 or so articles (that I know of) is to have some sort of template, and after reading the various guidelines, I'm wondering if it might be more appropriate to replace this "footer" with a template that we can put in the See Also section instead. Don Lammers (talk) 18:39, 23 November 2015 (UTC)
    @Donlammers: "'support' here ... seems to imply that there should be no exceptions": WP:GUIDELINE already says: "Use common sense when interpreting and applying policies and guidelines; there will be occasional exceptions to these rules", which includes a link to the WP:IAR policy. Policy trumps a guideline, so exceptions alone are not a reason to not have a guideline. I'd imagine we usually don't put caveats about exceptions in guidelines because IAR is always implicit. "there doesn't really seem to be global consensus to change the wording and make it stricter": As this part of the poll is merely to reaffirm the existing BIDIRECTIONAL, this doesn't appear as if it should be a factor in deciding to oppose.—Bagumba (talk) 00:02, 24 November 2015 (UTC)
    You are correct as to the nature of this question. However, after looking at the various discussions (and this one), I will keep my vote here because I don't think there has been consensus on even this small part of the navbox guidelines. It has been a contentious issue for a long time, and there has not been consensus to either change or not change the wording. Boghog emphasizes above that this is just a guideline, and that therefore exceptions are implicit even if not stated. He suggests that the links in the left column of more specific navboxes could cover our needs of "up and over" navigation. Unfortunately even this suggestion (which we implemented a few years back) is currently being challenged as not being in compliance with this rule. Don Lammers (talk) 15:16, 25 November 2015 (UTC)
    @Donlammers: I was the first to suggest the bidirectional guideline and I certainly had no intention of suggesting section headers should also be bidirectional. These headers provide links to definitions and higher level articles and and in these cases, bidirectional links usually are not appropriate. I think it would be much clearer if the guideline was modified to state that bidirectionality only applies to the body of the {{navbox}} (i.e., the links contained in the |list= parameters) and not to headers (i.e., links stored in |section= or |group= parameters). Boghog (talk) 16:04, 25 November 2015 (UTC)
    I do think these should also be bidirectional, actually, as applying BIDIRECTIONAL to such links seems in accordance with WP:OLINK (namely, the first two bullets therein). Example: Links to North America from a template which does not apply to the broad topic of continents or countries really doesn't need to link to North America. Most other times I've seen these linked the links are to topical content (such as a header called "Video games" linking to List of Naruto video games on {{Naruto}}). --Izno (talk) 16:58, 25 November 2015 (UTC)
  9. Oppose Per Donlammers. and what I interpret as present consensus within the Wikipedia:WikiProject Zoo. Dan Koehl (talk) 16:50, 24 November 2015 (UTC)
  10. Oppose My view of BIDIRECTIONAL is that, as written, it is self-inconsistent and the consequences of the muddled guideline have been generally undesirable. However, that is not what I am being asked. Is there consensus for it? I do not think there ever was (also as demonstrated here) but neither has there been consensus for any specific change. Thincat (talk) 08:57, 25 November 2015 (UTC)
  11. Oppose Seems too creepy as a general rule. Each case should be judged on its merits. Andrew D. (talk) 13:04, 28 November 2015 (UTC)
  12. Oppose per WP:CREEP --In actu (Guerillero) | My Talk 13:50, 2 December 2015 (UTC)
  13. Oppose as too rigid. I've never been particularly happy with this guideline and was unaware that so many others were too. Let's take a hypothetical example, different from those above and below. Project "Y" (fictional) has four main areas of interest, which I will call Interest A, B, C, and D. Interest A has 75 sub-topics, Interest B has 50, Interest C has 80, and Interest D has 45 more. If my math is correct, there are a total of 250 articles on sub-topics, plus four main articles. It makes sense for there to be an Interest A nav template that links to the main article and to each of the sub-topics. And it makes sense for that nav template to be fully bi-directional, in that it gets placed on every article about every sub-topic within Interest A. Likewise for Interest B, C, and D. But it might also make sense for the sub-topics within Interest A to have a nav template that lists just the four main articles -- after all, they are somewhat related being within the scope of a single project. So if I am reading the article about sub-topic 27 of interest B, I can see the other Interest B articles and I can also see at a glance the main articles for Interest A, C, and D. Requiring those main articles to include the templates for all 254 articles, however, would be problematic and, just as a wall of text can overwhelm a talk page, a wall of nav boxes can overwhelm an article. There are numerous examples of actual articles like this. Etamni | ✉ | ✓  12:59, 6 December 2015 (UTC)
  14. Support generally (unless there is some cogent reason not to), but Oppose as an absolute universality, as there are cases where it may be inappropriate. The reason not to, however, must be supported by consensus, and must be very cogent. It should not be a whim, or a few editors ganging up on another editor. Again, support broadly and generally but reserve the right to oppose in specific unique instances. A foolish consistency is the hobgoblin of small minds. Softlavender (talk) 06:01, 15 December 2015 (UTC)

Neutral 1

Im not really sure about my opinion, although it seems my activities for WikiProject Zoo is at least partly the source for this poll and discussion. First, I followed the guidelines for Wikiproject Zoo, and added the template Zoo to all pages, I felt was relevant. After 4 of my edits was reverted by an upset user, with the motivation that such navigation templates should only be added to the pages linked in the nav box, I removed the template from all pages which was not linked from the navbox. After this another user became upset, and asked me to put back the navbox. Im following the discussions, and feel somewhat confused as to wether there is a consensus or not, a rule or not, and what is correct. I hope the outcome of this discussion will clear this confusion, and I will follow the outcome in any case, wether the navbox should be replaced on the files were I removed it, or wether it should only be placed on pages linked from the navbox. In both cases I will of course do the actual work, since previous edits initiated this discuss.Dan Koehl (talk) 14:37, 21 November 2015 (UTC)
Exactly the reason we dont need a rule to cause conflict...let projects and editors at the article level decide what is best. Lets give an example of a well organized project that does not follow the rule because its to simple ...{{Canada topics}} from Canada links to History of Canada were people will find {{Canadian history}}...this will then lead you to Military history of Canada were again we have a sub navbox {{Canadian military history}} no need to have the first one all over even though its linked in the template. Well organized projects dont follow this rule....they do what is best to navigate topics. Template editors may fell different but a project devoted to a topic is best suited to make this call. -- Moxy (talk) 16:33, 21 November 2015 (UTC)
  1. Also neutral. Nav boxes should be concise and easy to approach. I think mandating bidirectional forces link creep on the nav box as less important topics get placed there simply so they can get the nav box placed on their page. Users reading about a little known philosophy topic may be interested in other philosophy topics, but there may be almost no interested going the other way through nav box to discovery of the little known philosophy topic. Though, much of this is achieved through normal blue links. I lean against bidirectional, but mostly I think just getting project wide consensus is the important part. I don't think nav box use should be project based. Dkriegls (talk to me!) 05:55, 23 November 2015 (UTC)
  2. I'm not exactly neutral, but this is a misleading question. Yes: Support for the guideline as worded. No: Oppose pretending that "normally" means "always". There are thousands of exceptions. The zoo-related example is a good one: An article about a local zoo might well benefit from links to articles about zoos in general, rather than (or in addition to) links to articles about other local zoos. WhatamIdoing (talk) 02:08, 27 November 2015 (UTC)
    I'm puzzled that anyone supports the guideline as actually worded because it proclaims bidirectionality while describing unidirectionality. Historically people on both sides of the argument have disapproved of the wording. What it says is "Every article that transcludes a given navbox should normally also be included as a link in the navbox so that the navigation is bidirectional." What would be logical would be "Every article that transcludes a given navbox should normally also be included as a link in the navbox and every article included as a link should normally transclude the navbox so that the navigation is bidirectional." Some editors enforce both aspects with a rod of iron. Thincat (talk) 08:38, 27 November 2015 (UTC)
  3. Neutral leaning oppose. While I agree that most navboxes should be bidirectional, I think there are too many exceptions to elevate the principal to a guideline. Guidelines are generally applicable rules, they can have case by case exceptions based on consensus, but here practice is too varied to reach that level. Monty845 15:58, 18 December 2015 (UTC)

2. List members are valid exception

Support 2

  1. A good list will cover items which could easily be included on the template itself, a map to the subject which informs readers of other pages which contain information about their searched-for interest. Adding each item on a list to the template may overload it, so a list serves its purpose and the reader well. Adding templates to those related items - such as the {{Zoos}} template placed on individual zoo pages - is the very essence of bi-directional, where a related topic which could, but for the list, be placed on the template to provide the reader with a look at the entire topic-map. Randy Kryn 9:27, 19 November 2015 (UTC)
  2. Per Randy, Sadads (talk) 15:10, 19 November 2015 (UTC)
  3. Absolutely! Such navboxes are, in fact, crucial to navigate back to a main subject from a "child" article that utilizes the navbox or between "child" articles (Somewhere out there is a "two click" guideline also, though perhaps that was removed; it's a good guideline). A list can be incorporated by reference into a good navbox, particularly where the list contains hundreds of items. I was involved in some of the discussions referenced by Izno, below, and my perception of one problem was that there will always be some editors who insist on strict bidirectionality to the point that the purpose of navboxes is defeated. Take, for example, something like List of BLM Herd Management Areas, which, when completed, will contain 270 items. At present, most of the HMAs don't have stand-alone articles, but for the purposes of discussion, this is an example we can play with (precisely because there is, so far, no navbox for the items on this list, nor for the BLM in general). We could create a BLM navbox, that lists all the areas the BLM covers, but it would be impractical to list all of the areas the BLM manages (270 HMAs, 23 National Monuments, 221 Wilderness areas, etc.) but with a link to the HMA list and to, for example, List of National Monuments of the United States, a theoretical BLM navbox would be bidirectional for anyone seeking to surf the entire realm of areas the BLM handles. Montanabw(talk) 17:07, 19 November 2015 (UTC)
  4. Yes, and anything else is also a valid exception if there is consensus for that. Thincat (talk) 08:59, 25 November 2015 (UTC)
  5. List members are a (NB: not "the sole") valid 'exception'. However, there is no requirement to omit things on the list. You must use WP:Common sense and make the determination individually, case-by-case, using your best editorial judgment for each navbox. WhatamIdoing (talk) 02:11, 27 November 2015 (UTC)
  6. Support this is good thinking. All the best: Rich Farmbrough, 14:25, 16 December 2015 (UTC).

Oppose 2

  1. Nope. C.f. previous discussion on the various navboxes, {{aviation lists}} among them and probably the predominant discussion. A navbox of lists can ostensibly navigate between the list articles, but it is not so useful to navigate from "child" articles. A navbox dedicated to that list seems appropriate in this situation, though off-the-cuff I'm not sure what utility that provides above the list itself (there may be a particular sorting on the list article which is not conducive to navbox-ing, and vice-versa, I suppose). --04:35, 19 November 2015 (UTC) — Preceding unsigned comment added by Izno (talk • contribs)
  2. This rule is a suggestion. So why are we discussing a hard fast exception as if it is a rule.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:02, 19 November 2015 (UTC)
  3. Per WP:PROPOSAL: "Most commonly, a new policy or guideline simply documents existing practices, rather than proposing a change to them." I don't fully understand this proposal without more explicit examples, and can also think of some alternatives, which leads me to believe this is anyways not a widespread existing practice in need of an explicit guideline.—Bagumba (talk) 07:00, 20 November 2015 (UTC)
  4. Oppose. Per the recent {{Aviation lists}} discussion. Templates with lists should only be transcluded on the list articles themselves, not on every article that is part of that topic. Otherwise this fails the points at WP:NAVBOX. --Rob Sinden (talk) 09:02, 20 November 2015 (UTC)
  5. Oppose. Defeats the purpose of a simple, self contained navigational aid. An important design principle is provide context or lose the reader. The navbox should give continual feedback as to where the reader is located within a collection of related articles. The bolded self link in bidirectional navboxes provides that context and that context is lost if the links are not bidirectional. Boghog (talk) 13:15, 20 November 2015 (UTC)
    Hi Boghog. Wondering how the very simple and very functional zoo template, added to a zoo page, will "lose the reader"? Zoos are listed on a list which is a member of the template, would you rather the template contain every zoo article on Wikipedia? These type of comments should be looked at closely by the closer of this question, and he or she may realize that a limited view of what templates can accomplish may very well be harming the Zoo project in particular and Wikipedia in general. So, if you would, please, explain how adding the Zoo template to the articles on individual Zoos has lost readers. Thanks. Randy Kryn 18:23, 20 November 2015 (UTC)
    p.s. Just wanted to let people know that, while this discussion was/is ongoing, editors have removed the zoo template from maybe 1,000 pages which are included in the lists presented on the template. What a loss. So yes, there are real-Wikipedia-world ramifications of this discussion, even as it's ongoing. Randy Kryn 18:50, 20 November 2015 (UTC)
    Hi Randy Kryn. Think of a fixed directory map in a shopping mall with a sticker that immediately indicates where you are and helps direct you to where you want to go. The bolded self-link in a navbox that is a result of bidirectionally serves the same function. Without bidirectionally, you lose that context. The following taken from an navbox essay is sound advice: Ask yourself, does this help the reader in reading up on related topics? Take any two articles in the template. Would a reader really want to go from A to B? First of all, one cannot not even go from A to B and take the return trip from B to A if both articles are not contained as links within the template. A round trip is an essential aspect of navigation. Second, the links in the navbox should link the most closely related articles of the same level of importance. There should be a hierarchy of navboxes from general subjects to the more specific. Returning to the {{Zoos}} example, if one is reading Augsburg Zoo, how likely is it that one would want to link to Extinction? Probably one is more interested in other {{Zoos of Germany}}. Why should Augsburg Zoo contain both {{Zoos}} and {{Zoos of Germany}}? This is redundant. Boghog (talk) 21:11, 20 November 2015 (UTC)
    I've removed 'Extinction' from the template, good catch. Are there any other items on the {{Zoos}} template that a visitor to the Augsburg Zoo page might not have an interest in as they read about and search Wikipedia for zoos? There are dozens of zoo topics on the template that aren't on the {{Zoos of Germany}} template, topics which readers might find interesting (I sure do) or ignore totally and not even open up as they look at the Zoos of Germany template. So, my question about how the zoo template on a zoo page will "lose readers". I don't look at templates as you described, I look at them as giving a map of a subject to the reader, a map which includes all the large continents, cities, and oceans, saying in essence "Here, if you like this subject just glance over the other pages Wikipedia contains" - and remember, we are only talking of items which are already on lists. The lists are already on the templates. The topics on the list are directly related to the template, they are just offered in a list. The connections are direct. That said, one thing all of us here have in common is our interest and enjoyment of templates, and we know their value to both the project and the informed reader. Randy Kryn 21:30, 20 November 2015 (UTC)
  6. Oppose. "See also List of stuff" is the more appropriate navigation mechanism - with the list page including an instance of the navbox, naturally. — Cheers, Steelpillow (Talk) 11:35, 22 November 2015 (UTC)
    No, the problem is that using "see also" and "list of stuff" basically mandates inserting links into hundreds, if not thousands of related articles, depending on the length of the list. Lists are specific, navboxes are more general to subject area. Montanabw(talk) 21:23, 22 November 2015 (UTC)
    Not always. {{Mucinoses}} is a very specific navbox, and List of cutaneous conditions is general. WhatamIdoing (talk) 02:17, 27 November 2015 (UTC)
  7. Oppose - There are almost certainly examples where this is an appropriate approach, but I don't think it makes sense to codify this as a blanket exception. — Rhododendrites talk \\ 06:08, 27 November 2015 (UTC)
    Hi Rhododendrites. The problem exists because there are deletionist editors who will use a "vote" on this as policy, and point to it during wholescale removal of templates from pages where others see a certain legitimate use. Again, the Zoos template, which was removed from 1,000 pages by pointing to this "policy", and which is now a major point of this discussion. There is room for disgression when using templates on the articles of items on a list, but that would be removed from consideration if this issue is taken as consensus. At the moment this discussion seems far from a consensus, and changing the guideline to omit lists items which, on a good list or popular culture list (see Cultural depictions of John F. Kennedy), are directly related to the topic of the template, seems to me to harm the concept of adequate template placement. Randy Kryn 13:22, 28 November 2015 (UTC)
    If people interpret a guideline which clearly allows for exceptions as not allowing for exceptions, the issue is that user rather than the guideline. If there's a way to frame it more clearly in the guideline, I'm all for that, but this proposal doesn't clarify that there's room for exceptions, it creates a class that is exempted. It's not that I don't think it's necessary -- it's that I think it gets it wrong (i.e. sometimes it may be appropriate, but most of the time it isn't). I also object to the use of "deletionists" as a bogeyman gloss on actual arguments. — Rhododendrites talk \\ 05:41, 29 November 2015 (UTC)

Neutral 2

  1. I think this is a good idea, but per Izno I feel it needs to be determined case-by-case, with utility being demonstrated specific to that list. —⁠烏⁠Γ (kaw) │ 05:18, 19 November 2015 (UTC)
    You might have misinterpreted my comment to suggest that I am agreeable to navboxes of lists. Let me clarify, in any case: I am only agreeable to them where they are being used as a navigation element between lists. I am not agreeable to using navboxes of lists to navigate between children of those lists (as was the predominant usage of {{aviation lists}} and apparently others). The inclusion of lists-in-general in navboxes specific to a topic not dominated by lists I however support (e.g. in {{Star Trek: The Original Series}}) since this is not only common but good practice. --Izno (talk) 13:59, 20 November 2015 (UTC)
    I did mean to refer to the latter case; the former would definitely get easily cluttered and become a hindrance to navigation rather than an aid. I do agree with your application of caution, but I think that it can be overcome to turn into a benefit for the project if an implementation is written and applied well enough. Navigation between elements of different lists should only be aided where there is a meaningful connection independent of or relevant to the umbrella topic they may share. —⁠烏⁠Γ (kaw) │ 23:41, 20 November 2015 (UTC)
  2. I I also think this should be determined case-by-case by editors familiar with the topic at hand over flyby template editors. -- Moxy (talk) 18:31, 19 November 2015 (UTC)
  3. I support the concept that they should be allowed as exceptions when determined as appropriate by the "local" editors, but do not think that it should necessarily be written into the guidelines, which I think would specifically encourage the practice. Don Lammers (talk) 18:50, 23 November 2015 (UTC)

3. BAG can assume there are rarely exceptions

Support 3

  1. Support as long as there are safeguards allowing for quick, simplified reversion in case the given situation becomes contentious. —⁠烏⁠Γ (kaw) │ 05:18, 19 November 2015 (UTC)
    I think I'm agreeable to this comment, as per my comment below to Bagumba; editors local to a page should be able to override a particular (as in, 1 removal) and have the bot respect that decision. However, this could lead to abuse where an editor disagrees with the removal wholesale and reverts on multiple pages. Behavior which could be WP:ANIable, given the outcome of this RFC? --Izno (talk) 14:09, 20 November 2015 (UTC)
  2. Support when we're talking about the wholesale transclusion onto articles which are only linked by a broad topic (in cases recently like {{Ballet}} (where the navbox was transcluded onto every ballet dancer with an article) and {{Aviation lists}}). I can't think of a valid exception in these cases. And I think this is the only time there would be a bot request, as the odd individual exception would be handled by normal editing. --Rob Sinden (talk) 09:09, 20 November 2015 (UTC)
    I would tend toward agreement with these comments. --Izno (talk) 14:09, 20 November 2015 (UTC)
    Navboxes are precisely best for the example of ballet, above; a reader comes across a ballet biography and wants to learn more; no category would do the job of encompassing the broad topic, but the navbox guides the reader to articles about the general topic. This whole thing with bidirectionality is screwing up the original idea of navboxes, which is to HELP readers find other articles of interest. Bidirectionality is a guide, but should not be a hard and fast rule. Montanabw(talk) 01:38, 22 November 2015 (UTC)
    To navigate among related topics (see the entire rest of the guideline), not to find other articles of interest. Broad articles of interest I would expect to find linked prominently in the text (such as Action-adventure game is linked on every action-adventure game), but does not make sense to link in the navbox for those action-adventure games (say, on {{The Legend of Zelda}}). But that aside, I think this is offtopic to this question. --Izno (talk) 17:19, 24 November 2015 (UTC)
  3. Support, I can't think of any good exceptions. an exception is typically a misunderstanding of the purpose of categories. Frietjes (talk) 23:39, 23 November 2015 (UTC)
  4. Support. A necessary step to combat template creep. --Tt(talk/contribs) 03:25, 8 December 2015 (UTC)

Oppose 3

  1. Again, zoos. An editor who-will-not-be-named (waves) placed the {{Zoos}} template on each zoo and aquarium page, which turned out to be close to 800 pages. This is a perfect use of the zoo template. A bot could remove those if given this coding guideline, which would cut-off our overall site map to those people who, looking at a page for an individual or local zoo, may then find an entire world of knowledge has been given them. Randy Kryn 9:58, 19 November 2015 (UTC)
  2. The merit for removal needs to be discussed for each group of articles, and preferably notify relevant active WikiProjects which curate a topic area. There may be a good reason that nav-box scopes need to be split, like Zoos per Randy's example, or to not further isolate a topic from Wikipedia's power in hyperlinking. Sadads (talk)
    I agree with this point in that sometimes these navboxes can be transformed in such a way (per consensus model) to be more useful to more pages, but I'm not sure in the general case that these templates, where used widely (as with {{aviation lists}}) could possibly be transformed to fit the use for the majority of their invocations. --Izno (talk) 14:06, 20 November 2015 (UTC)
  3. We must consider the possibility of long-undetected vandalism of adding, or removing, several entries into a navbox/list. עוד מישהו Od Mishehu 15:42, 19 November 2015 (UTC)
    This seems unlikely. Are you sure you understood this question? --Izno (talk) 14:06, 20 November 2015 (UTC)
  4. As I noted above "should normally" only makes this a suggestion. There is no reason for a bot to be running around handling the guideline like it is a rule.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:00, 19 November 2015 (UTC)
  5. No, the Zoos navbox is the tip of the iceberg; there are many navboxes similarly situated. Splitting navboxes that have no need to be split so long as links to list articles are included is not going to help the reader and will, instead, lead to yet more navbox clutter where a reader must navigate multiple navboxes to find what they need. Montanabw(talk) 17:09, 19 November 2015 (UTC)
  6. Not a good idea....editors that work with the topics would know best....thus should be the ones that make changes. Not the type of thing for a bot...the bot has no common scene to apply this. -- Moxy (talk) 18:34, 19 November 2015 (UTC)
  7. Leaves little room for legitimate applications of WP:IAR.—Bagumba (talk) 07:01, 20 November 2015 (UTC)
    I'm unsure that this is a legitimate point in this context. Where a bot "unilaterally" (as in, WP:BAG approves a bot with community agreement or knowledge thereof) removes these templates, WP:IAR suggests that an editor should freely revert the bot's edit. However, should WP:BIDIRECTIONAL be in general supported by the community, I'm not sure that editor should be so-free... a discussion to be held on the relevant talk page if others disagree local to that page, I suppose. --Izno (talk) 14:06, 20 November 2015 (UTC)
    BAG approval should take place on a per case basis as is the norm. There should not be carte blanche to apply BIDIRECTIONAL. Bear in mind that even IAR ultimately needs consensus that an exception is warranted, but that discussion should take place during BOT approval, not after 1000s of articles have already been edited by a bot.—Bagumba (talk) 18:41, 20 November 2015 (UTC)
    I'm not sure we're talking carte blanche to apply BIDIRECTIONAL in all cases of templates, but carte blanche for removal of obvious mass-offenses (as with {{aviation lists}} and others). --Izno (talk) 18:01, 24 November 2015 (UTC)
    Disagree. It must not have been so "obvious" if an RfC was needed in the first place. Per-case approval is sufficient. Thanks.—Bagumba (talk) 20:11, 24 November 2015 (UTC)
    That an RFC was held to remove {{aviation lists}} does not imply that it was not also an obvious offender. --Izno (talk) 20:50, 24 November 2015 (UTC)
    Not familiar with that specific case. If it really was "obvious", then WP:NOTBUREAUCRACY would have been relevant there. At any rate, as I see you !voted oppose here as well, maybe we actually have the same rationale, as I agree with your below comment of: "my inclination is that I would want the bot operator to be careful in the absence of a discussion". Perhaps we can take this offline if you would like to continue.—Bagumba (talk) 21:15, 24 November 2015 (UTC)
  8. The most clear thing here is the lack of clarity. I'm seeing a variety of good arguments on different sides, and a variety of complicated cases. I appreciate the desire to bot-improve the organization and consistency of Wikipedia, but there's going to have to be a case by case discussion. Bots can only operate where things are clear, or specific cases that have been clarified. Alsee (talk) 14:52, 20 November 2015 (UTC)
  9. Oppose - It's gotta be case-by-case. BMK (talk) 06:06, 22 November 2015 (UTC)
  10. Oppose because I don't think a bot can be programmed to deal with the concept of "normally" (I'm always willing to be proven wrong on this). I believe that the particular navboxes pertinent to this particular bot request have already been removed. I don't think that BAG can "assume" anything. Don Lammers (talk) 17:55, 23 November 2015 (UTC)
  11. I'll move to oppose this one. While I struggle to think of a exceptional case, and I don't necessarily think a broadly-published RFC or other community discussion should be required, my inclination is that I would want the bot operator to be careful in the absence of a discussion, and I don't know that we have a guideline or existing consensus (beyond the general bot guideline) to do so in this context. --Izno (talk) 17:12, 24 November 2015 (UTC)
  12. Oppose. I don't think BAG should be assuming any such thing. In any particular case BIDIRECTIONAL does not tell us whether a navbox should be removed from articles or articles added to the navbox. Thincat (talk) 09:06, 25 November 2015 (UTC)
  13. BAG can safely assume that there are thousands of exceptions, and that navbox placement requires human judgment. WhatamIdoing (talk) 02:32, 27 November 2015 (UTC)
  14. Oppose Too complex and circumstantial for simple assumptions. Andrew D. (talk) 13:09, 28 November 2015 (UTC)
  15. I oppose any bot treating this guideline as a hard and fast rule and removing content (templates) based on such a rule. I'm fine with bots that simply crawl the site or a particular project area documenting instances where it appears bi-directionality has been overlooked, but the specific solution should be left up to a human editor. Add article to template, remove template from article, or treat as valid exception, are choices that I don't think a bot is equipped to handle. Etamni | ✉ | ✓  13:20, 6 December 2015 (UTC)
  16. Reluctant oppose I am not even sure that we should have navboxes, certainly they contribute to bloat in some cases. But if we should then hard-and-fast rules on bi-directionality may not be a good idea. Possibly we should adopt a different approach, tagging non-bidirectional navboxen as such. All the best: Rich Farmbrough, 14:30, 16 December 2015 (UTC).

Neutral 3

I'll consider this question. Gut says yes, there are rarely exceptions. --Izno (talk) 04:35, 19 November 2015 (UTC)

@Izno: I've placed you into neutral for this based on your first sentence; feel free to correct me if you change or refine your position. —⁠烏⁠Γ (kaw) │ 05:18, 19 November 2015 (UTC)

General discussion

I've left notification of this discussion at the following projects I am involved in that use navboxes: Wikipedia talk:WikiProject National Football League, Wikipedia talk:WikiProject College Basketball, Wikipedia talk:WikiProject College football, Wikipedia talk:WikiProject Baseball, and Wikipedia talk:WikiProject National Basketball Association.—Bagumba (talk) 07:14, 20 November 2015 (UTC)

This seems to be a rather narrow set of projects - we should probably widen the field a bit. --Rob Sinden (talk) 16:05, 20 November 2015 (UTC)
I think its a good idea to invite those groups that make hundreds of templates then paste then all over here ...thus they can see the concerns raised. We should also invite some groups that maintain a small amount of templates. -- Moxy (talk) 17:27, 20 November 2015 (UTC)
@Rob Sinden: I erred on the side of disclosure here, even though I notified projects as opposed to specific individuals, which is usually the concern with WP:CANVASS. Others are invited to broaden the the invites as they see fit. Cheers.—Bagumba (talk) 18:36, 20 November 2015 (UTC)
I don't see why discussions about major changes in template policy can't be listed on every project page. Randy Kryn 18:42, 20 November 2015 (UTC)
I agree more the merrier ...I did notify the main projects...like Wikipedia talk:WikiProject Navigation templates - Wikipedia talk:WikiProject Lists and Wikipedia talk:WikiProject Templates...did not do Wikipedia talk:WikiProject Templates as the project has been dead for years. -- Moxy (talk) 18:53, 20 November 2015 (UTC)
Not personally very conscious of the projects and groups here, but some of the projects which will be greatly affected by this might be films, politics, U.S. Presidents (well, actually all of history and politics), literature, authors, all of the world's religions, and any other project which would include some of their best groupings in lists. They have begun to be asked to remove them - the head of the Zoo Project here was very recently asked, just beore this discussion began, to remove the template "Zoos" from all of its pages except those listed on the template itself, which he or she did - sending the message to the projects that lists don't count. So yes, almost every Wikipedia project would likely be affected by this (greatly affected in terms of their template collections), and arguably should be notified. This seems like one of those fight-the-good-fight topics, not many of those but there are a few when it comes to the templates. Randy Kryn 20:02, 20 November 2015 (UTC)
@Randy Kryn: There shouldn't be a problem, it's just a matter of effort. I merely volunteered to notify the ones I was involved in.—Bagumba (talk) 20:27, 20 November 2015 (UTC)
I don't know the Wikipedia project-world, so can someone help with this? Thanks for the link to the volunteer article, a good read. So I'll get to the notifications later if nobody else does. Since I last posted I've thought of all the templates which have "In popular culture" items, which usually all receive the parent-template. There are probably hundreds of "So-and-so in popular culture" pages here, and this would affect all of the pages included in those listings. Randy Kryn 20:42, 20 November 2015 (UTC)
Most WP:IPC items shouldn't even be in an article, let alone a navbox. For those that are significant enough for an article, I can't imaging it being notable enough to bloat a navbox.—Bagumba (talk) 21:07, 20 November 2015 (UTC)
All geography, art, film, music, sports and animal projects should be notified, at least the primary ones - all of these projects have multiple navboxes, this could impact millions of articles and thousands of navboxes. Montanabw(talk) 23:01, 20 November 2015 (UTC) Follow up: I've posted messages at several of these, WP geography, film, television, music, football (soccer), dogs, aviation. If folks have others, we can post further. Montanabw(talk) 01:55, 22 November 2015 (UTC)

What BAG can assume

Firstly, if BIDIRECTIONAL is dropped then this issue becomes empty. So the following must assume it is upheld. BAG assuming anything about exceptions is dangerous, as a navbox may be flawed for many arbitrary reasons and we don't want them deleted willy-nilly. For example there might be the odd coding flaw, custom code or red link floating around. On the other hand, there must be thousands of rogue instances out there and some kind of basic assumption is the whole point of letting a bot loose. One rather complicated approach might be:

  1. Agree some very basic and specific criteria for deleting what are obviously non-compliant "rogue" instances of a navbox. A bot can implement these without question.
  2. For other detected anomalies, tag the suspect instances with say a templated message on the article talk page.
  3. Over time, use experience gained to hone the basic assumption set.

That's a quite prescriptive environment to code in, so I'd like to see some further discussion before polling on the best approach to this issue. — Cheers, Steelpillow (Talk) 11:50, 22 November 2015 (UTC)

The real problem is basically due to one ill-advertised debate about removing a bunch of navboxes from list articles involving aviation; where the navbox crowd ganged up on one or two active aviation editors and forced through a local consensus that only makes sense inside of the walled garden that is the navbox area. The impact is on, apparently, something like a thousand articles. But create a bot that will plow through every navbox in wikipedia to "fix" the problem and I just cringe to watch the drama that will erupt. The wider community that doesn't spend time at the drama boards has a general understand that navboxes aid navigation, and the idea that they should be balkanized with no link back "home" so to speak, is a problem. Montanabw(talk) 21:21, 22 November 2015 (UTC)

Awful RfC

What does "BAG can assume there are rarely exceptions" mean? If we oppose it, does that mean that BAG can assume there are no exceptions, or that exceptions are common? Any action based on this vague question will be open to challenge. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 25 November 2015 (UTC)

Likely the core reason it's been strongly opposed, even if we are split on the other 2.—Bagumba (talk) 23:37, 25 November 2015 (UTC)
Did you folks read the explanation by slakr under "Main questions"? — Earwig talk 23:42, 25 November 2015 (UTC)
Such blurb - including the clarification below - carries no weight with the kind of wikilawyer who will seek to implement the outcome of this RfC in line with their own wishes. The matter is irrecoverable; this RfC should be abandoned and, if necessary, a better one started,. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 26 November 2015 (UTC)
Sorry Andy, but I can't make heads or tails of this. So far, there is clear consensus against letting BAG assume there are no exceptions—leaving aside the unclear consensus for the guideline itself. In short: if the RfC does not change direction wildly before it is closed, we will require all navbox removal tasks to have their own individual consensus apart from any broader BIDIRECTIONAL guideline. I think that's quite reasonable; it doesn't surprise me that the community opposes the proposal. I don't see any room for wikilawyering. — Earwig talk 17:35, 26 November 2015 (UTC)
No. There is no consensus, clear or otherwise, pro or con, on the issue of whether BAG may "assume there are no exceptions" (emphasis added), because that is not what is asked. The consensus is only against "BAG can assume there are rarely exceptions" (emphasis again added), which is ambiguous, because it does not say what the alternative is: to assume there are no exceptions, or to assume that exceptions are common. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:36, 26 November 2015 (UTC)
So the explanation on #3 might not have been clear enough for some:
  • TLDR: If you're looking for the option that favors status-quo use of navboxes as they currently are, you'll want to oppose #3, as opposing means you're saying to us that that any bot request that comes to us will be required to pass a heightened level of scrutiny and obtain clear consensus before bulk operations are approved. A discussion on the wikiproject and/or on its template talk page will be expected before any sort of mass-removal, addition, or other form of mass-synchronization of navboxes is considered for approval at WP:BRFA; it's not just enough to say "per this guideline."
  • Extra: #3 is a strength-of-desire-for-uniformity indicator, basically. If #1 and/or #2 have consensus in support, people would be basically saying, "Yeah, I think (that option) is a good, general idea for a guideline," but opposing #3 is where you're also then saying, "...but there are a lot of exceptions, so bulk operations truly still need case-by-case consensus." Usually this is the default position for BRFAs anyway; we expect consensus on a case-by-case basis unless a task is trivial or obviously non-contentious, hence the reason why I label opposing #3 the "status-quo" option in the TLDR above. The reason #3 is even here, though, is that navboxes are a huge portion of the interface, so it made sense to at least allow the option for the community—if it felt it urgent or appropriate—to support #3 and thus say, "Let's allow bots to make it the same everywhere!" Neither #1 nor #2 (currently) seem to show clear consensus, so while #3 is trending toward oppose, it may very well be a moot point anyway, as the lack of consensus for #1/#2 would mean there's nothing with consensus to base an assumption on. :P
--slakr\ talk / 01:04, 26 November 2015 (UTC)
See above, Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 26 November 2015 (UTC)
While I understand your concern—you don't feel the question is, from a "legal" standpoint, solid to the letter—it's not intended to be, hence the reason it's not concrete. Few things are like that on Wikipedia, and this being a guideline (as opposed to a flat-out policy) in the first place inherently implies there are likely going to be exceptions to the rule and room for subjective interpretation. I've made it very clear what my intent is, what the question is, and what un-disclaimed input reflects at this point. The reason for this is that regardless of outcome, this isn't going to be codified anywhere or written in stone as far as I'm concerned (in fact, I don't even think there's a good location to place it even if that were the intent). It's solely going to be used by the bot approvals group as one piece of community input in this area when deciding whether to even approve or deny bot trials (and the bot as a whole) when a task involves justification based on this guideline. And, as it stands, yes, the current input does mean that I would interpret this as consensus against granting a trial/full approval to a bot seeking to perform mass operations on navboxes if they don't provide additional input from the communities and talk pages associated with that navbox, regardless of the outcome of #1 and #2. While I can't speak for the rest of BAG, I have a strange feeling they'd agree with this interpretation. --slakr\ talk / 04:04, 29 November 2015 (UTC)

I'm going to add to this and protest question #2. As Andy Mabbett says about question #3, the result of the answer is unclear. It asks whether a specific type of link is a valid exception. But if we codify this in the text (which I think is implied in the question), then people will point and say "that's the only exception allowed". And, if we oppose, are we saying that this is a specifically disallowed exception (I'm pretty sure the aforementioned wikilawyers will take it as such when reading this RfC)? I am opposed to this being disallowed as a local exception, but I am also opposed to it being codified as the only "sanctioned" exception. Don Lammers (talk) 17:45, 27 November 2015 (UTC)

This is a guideline, not a policy. The baseline assumption with guidelines is that there are exceptions, so it should not be assumed that anything's the "only" exception allowed (to begin with). Moreover, the question isn't intended to explicitly disallow anything, however the result of the RFC is really more up to the closer's reading of the input on it. However, my assumption was that those supporting #2 would be saying they support it being an exception, while those opposing #2 would be saying they don't support it being an exception. The support and oppose sections are more for organization anyway; the closer should be reading the comments to determine what someone's actually meaning. That said, I can see how there could be ambiguity in what opposes might mean, so if you're concerned about the wording of the guideline after the conclusion of this RFC, or if a dispute arises with how to interpret it, just file another RFC to hammer it out. RFCs can be a gradual, step-wise process, and as long as you don't wear people out—that is, as long as the intention is to make a good-faith clarification—they're usually appropriate. --slakr\ talk / 04:04, 29 November 2015 (UTC)
The real issue is if a bot could be created to remove all non-bidirectional navboxes from articles that don't have a navbox link. That would be a terrible idea because it would not make exceptions; this whole thing was due to the outcome of a single debate about an aviation navbox that contained links to lists. The debate was a couple of aviation editors against the whole navbox bidirectional crew and was blatently unfair on its face. Its outcome affected, apparently, thousands of aviation articles that use the navbox and someone wanted to get a bot to do it. Given that this "consensus" was false in the first place, this whole debate is a waste of time, other than to make it clear that those who seek rigid bidirectionality in the face of common sense are not going to find a consensus outside of their walled garden. Montanabw(talk) 11:43, 29 November 2015 (UTC)
I agree. I observed the early part of that debate (and maybe commented) and it seemed that there was the type of problem Montanabw described. This is not unusual, it is the type of problem that plagues WP decision making - there is not the quality control on decision making in the periphery that there is on content. I mean that in the sense that WIkiProject Birds looks after bird content, and will deal with, for example, someone who thinks that bird calls should be described in Morse code, whereas if we have a systemic problem at XfD or AN/I there is no real oversight. All the best: Rich Farmbrough, 14:42, 16 December 2015 (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.

Question

Not sure this is the conclusion most would see...but that its own problem... I am writing here to ask the closer there POV on point number 2...points 1 and 3 are addressed in the close but point number 2 is not....I believe its clear the outcome of point #2 ..but I would also say this for the other points...but its not I guess,- Moxy (talk) 16:34, 19 December 2015 (UTC)
Better to ask such questions on my talk page, as the discussion here is closed. Whether I should reply here or not, here's my answer to the quesion: for point two the RfC appears totally inconclusive – I chose for a compact closing without redundant information that is apparent to all. --Francis Schonken (talk) 16:58, 19 December 2015 (UTC)
Sorry ...I was going to post to your talk page but saw this removal of a question about this...thus was thinking you were not up to talking about it on your tlak page. -- Moxy (talk) 18:28, 19 December 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Categories,_lists,_and_navigation_templates/Archive_10&oldid=1137404645"