Jump to content

Wikipedia:Categories for discussion/Log/2021 April 16

Add links
From Wikipedia, the free encyclopedia
< April 15 April 17 >

April 16

[edit]

Category:Ancient Egyptian concepts

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:46, 27 April 2021 (UTC)[reply]
Nominator's rationale: delete, most articles are about ancient Egyptian deities (for which we already have a category tree) and otherwise the category is a hodgepodge of unrelated articles. Marcocapelle (talk) 20:51, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:CS1 maint: discouraged parameter

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: Delete - Ok, to start with, before closing this, I waded into the page history at the VP to find the initial close (and it's subsequent edits) which was noted as being the original rationale for the creation of this category. While there, I also found the link to AN, and had to go into the archives to read all of that. And that showed that the initial close was reverted and the RFC was re-closed. In the process of reverting, as noted by User:RandomCanadian there [1], not everything from the previous close was reverted.
However, this is WP:CFD, and probably not the place to determine how and where to clean up all of whatever may or may not have been left from an RFC (and its closing and re-closing).
But to address (at least) just the category at hand - Those who suggest that this could be kept, mostly also agreed that it needed to be renamed/repurposed in light of the reverted RFC closure. Which, in category terms, essentially involves removal of the existing category, and re-creation under the new name. As such, there is consensus that this category, as it currently stands should not exist. Probably not surprising, as this is, as noted, a category apparently created due to a reverted close, after all. And in the discussion below, there is no consensus for it to be (re-)created/renamed.
From here, I would suggest starting a discussion as to whether a tracking category for the parameter(s) in question should be created, and if so, what the name of it should be. As this has been controversial, I think most would agree, things are past the "Be Bold" stage.
I'll leave a note on the nominator's talk page about this close so they can look into having the coding which populates this category, adjusted. - jc37 17:30, 9 May 2021 (UTC)[reply]
Nominator's rationale: The RfC this was based on (WP:VPPR#RFC: Citation Style 1 parameter naming convention has been closed again, and there are no "discouraged parameters" in CS1, and no maintenance is needed on them. Code that populates this should be reversed, and the category then deleted. Fram (talk) 17:14, 16 April 2021 (UTC)[reply]
Notified: Wikipedia:Village pump (proposals)#RFC: Citation Style 1 parameter naming convention, Help talk:Citation Style 1/Archive 76#RFC on hyphenated citation template parameters closed – how to proceed?. * Pppery * it has begun... 19:42, 16 April 2021 (UTC)[reply]
  • Delete per Pppery. The RFC has decided that this is a non-issue. --BrownHairedGirl (talk) • (contribs) 20:14, 16 April 2021 (UTC)[reply]
  • Speedy close as rename or keep. A nomination at this point in time clearly shows the nominator's determination to not collaborate with the editors and developers who actually take care of citation templates and who spend a great deal of their precious time to maintain and further improve them. I consider the nominator's exhibited behaviour as very far outside of any proper social communication and collaboration standards among well-meaning people. It is rude and disruptive.
The template developers regularly deal with refinements of the citation category system and can cope with technically no longer used maintenance and error categories themselves without requiring the overhead of CfDs for this. It is wasting resources and wearing out those who actually contribute to our citation system - risking that our citation templates will become less maintained and the development of new advanced features delayed or abandoned.
The proper place to discuss CS1/CS2 citation template related issues is Help talk:Citation Style 1, where we are already discussing what to best do with this category since yesterday ([2]). The nominator is well aware of this but chosed not to voice his opinion there. Instead, he deliberately chosed to undermine the process by starting this parallel discussion and to neither make the participants of the discussion there aware of his nomination here nor to point the readers of this CfD to the already ongoing discussion. This could be a simple oversight by a new and unexperienced editor, but the nominator is not by any means, therefore it is impossible to assume good faith in such a behaviour; there are very clearly tactics at work, not the wish to collaborate and to seek the best possible solution.
For those interested in the background, the original closure of the RfC can be found here ([3]) and the category in question was created following this discussion ([4]) as a result of the RfC's closure. The nominator did not agree with the outcome and started an AN thread to overthrow the closure ([5]) - also without mentioning this in the relevant forum where we were busy to address the requirements imposed by the original closure. It is obvious why he chosed not to inform the participants of this forum - if he had, he would have faced significant opposition which could have lead to a different result.
The category should not be deleted but renamed (or simply kept) because it is useful to give insight into the usage of non-hyphenated parameters. This continues to be interesting information for those who care about the further development of the citation templates.
--Matthiaspaul (talk) 20:19, 16 April 2021 (UTC)[reply]
  • Move/Rename (or whatever the appropriate term of art is) to Category:CS1 properties: unhyphenated multiword parameter or similar, as is currently being discussed at Help Talk:CS1. This discussion is moot; there is no disagreement at HT:CS1 that the current tracking category name needs to change. Tracking categories are used all the time to measure and track the use of parameters in templates (e.g. Category:Album chart usages for BillboardComedy, or Category:Infobox road instances in Egypt). This category is no different, except that it was forced to have its current suboptimal name by the wording of the initial RFC closure. – Jonesey95 (talk) 20:49, 16 April 2021 (UTC)[reply]
  • Bad Faith Nom. Whatever you think of the close itself, discussion is and has been proceeding on the relevant talk page as to how the module system should deal with the second close. Hidden categories need not go anywhere Today much less Tomorrow, so the "fix it now, fix it now" attitude is entirely uncalled for, even if there were consensus on the subject.

    Moving on from the meta matters, I do not see that the second close of the RFC demonstrates that this category cannot continue to exist. Were we to remove the relevant parameters from the documentation and continue to put little green messages that these are discouraged and a category to go with the latter, that in no way would actually be contrary to the close from the RFC (which I'm |this close| to challenging itself given that the headcount at AN was almost all "I'm a C person and I don't like the close"). But even if you can argue that there shouldn't be little green messages and a category that says "discouraged", you still haven't demonstrated that these can't be tracked in some way. Whether for maintenance or otherwise. We have multiple such categories already in the CS1/2 system, so you can't even approach it from a "this would be inconsistent" (or you could nominate the rest I guess, but good luck with that consensus). So, straight Keep, second option rename/move. --Izno (talk) 21:13, 16 April 2021 (UTC)[reply]

  • Delete. Per the close of the RFC, these parameters are not discouraged, so this category is misleading and threatens to undermine to consensus of the RFC. —David Eppstein (talk) 21:14, 16 April 2021 (UTC)[reply]
  • Delete per Pppery et al. No need for this category. No need to track hyphenated and unhyphenated parameters (and there are other ways of doing so, mentioned at CS1 talk page). Levivich harass/hound 22:33, 16 April 2021 (UTC)[reply]
  • Rename I don't see any issues with tracking parameters themselves. -- WOSlinker (talk) 07:46, 17 April 2021 (UTC)[reply]
  • Delete per Pppery, Levivich, et al. If there is a genuine need to track the different parameters (about which I'm sceptical) and doing so requires a category (the linked discussions seems to indicate it might not be) then a new category can easily be created when consensus for having one emerges. Until that point, the existence of this category encourages an appearance of bad faith towards the community's view as expressed in the RFC. Thryduulf (talk) 10:53, 17 April 2021 (UTC)[reply]
    Is this a suggestion that an RfC will be needed in order to create a category? A software writer may have legitimate technical reasons to create/delete categories as needed and as a way to gauge end-user usage. I am not fond of categories that produce visible errors, but I have no problem with tracking categories especially since there are very few diagnostics/survey tools available to those who produce the software that this CfD nomination nitpicks. 65.204.10.232 (talk) 13:15, 17 April 2021 (UTC)[reply]
    I'm not suggesting an RfC would be needed (although I'm not going to stop you if you want one) just a simple talk page consensus that the non-zero overheads of adding thousands of pages to a category will bring some actual benefits to the project that are greater than those overheads. As it stands I'm struggling to understand what these benefits are, and it appears I'm not the only one (including some people who know far more about templates than I do). It is also clear that some people very clearly believe they exist, and indeed the failure to successfully communicate what they are does not mean they do not exist, but it does strongly suggest that at the very least more discussion is required before the existence of the category can be said to be a net benefit to Wikipedia. Thryduulf (talk) 00:30, 18 April 2021 (UTC)[reply]
    To repeat, there is no obligation whatsoever - in policy, guidelines, or common practice - for an editor to submit a maintenance/tracking category for approval to the wider community. Especially a technical one such as the one now discussed. The place for such discussion is at the appropriate page (the talk page for the module). And categorization is being discussed there, often in a somewhat technical manner because this is a technical subject. If you have followed these discussions, you would have seen that it is not unheard of for categorization to be introduced speculatively. That is, without a goal per se, but in order to discern how the software is used, or because of a hunch that established practice is inefficient and data is required to make informed design decisions. Or for any other reason that may or may not impact, now or in the future, continuing maintenance. Apart from that. The question of overhead is not entirely relevant. Under such assumptions, any categorization is suspect. Overhead is an objective quantity measured in page load time, server overload and all kinds of other tangible things. What you call "actual benefits" is a subjective evaluation. Using one to justify the other is a false comparison. When you mix the two, the result is also an evaluation, because opinions always contaminate facts. So what are we doing here? Wasting time, a familiar practice in these "discussions". In the meantime, the reasoning for deleting the category becomes more & more convoluted, with tinges of paranoia. As if the continuing existence of this category is a nefarious conspiracy that soils the purity of the precious RfC outcome. This may be becoming more enjoyable by the minute. 98.0.246.242 (talk) 03:33, 18 April 2021 (UTC)[reply]
    There are only two sorts of actions on Wikipedia: Those that are uncontroversial and those that need consensus before being implemented. While making a tracking category might normally be uncontroversial this one clearly isn't, therefore it needs consensus. Thryduulf (talk) 11:25, 20 April 2021 (UTC)[reply]
    And what is the nature of the "controversy"? Apart from the fact that the nom thinks that these parameters don't need maintenance because they were linked to an RfC. That's over and done, and the result is being complied with. Time to move on and stop obsessing about this. 24.103.101.218 (talk) 12:47, 20 April 2021 (UTC)[reply]
    Are you seriously claiming that a discussion that has approximately equal numbers of editors in favor of deletion and retention is not controversial? The nature of the controversy is shown by this very discussion's existence. (And it's not just the nom who has the opinion that these parameters don't need maintenance because they were linked to an RfC; I do as well, as do (I presume) the many editors who explicitly cited my comment as a reason for deletion) * Pppery * it has begun... 13:06, 20 April 2021 (UTC)[reply]
    Sure, anything can be whipped up into a frenzy. Especially when you start with foregone conclusions, like "maintenance is not needed". Which is as interesting or relevant as any other opinion. Here's another one: centering your argument on your "personal interpretation" of what you think is the gist of the RfC close Here is the fact: the RfC decided that certain parameters should not be deprecated, and that they should not presented as "discouraged" or anything else. The "controversy" may just be this nomination, which expands the RfC close to cover the mundane workings of module maintenance. Because of what? bad faith assumptions and conspiracy theories? 66.65.114.61 (talk) 15:21, 20 April 2021 (UTC)[reply]
  • Rename, Do Not Delete there is no harm done by tracking usage of any parameter. There are valid technical reasons to employ tracking categories. The argument that this will be used to somehow bypass the RfC outcome shows bad faith (and unhealthy obsession - but again this is Wikipedia...). An opposing bad-faith argument can be put forth: the nomination for deletion is an attempt to perpetuate the status quo by obscuring the real-world choice of the relevant parameters' format by editors at large. 65.204.10.232 (talk) 13:31, 17 April 2021 (UTC)[reply]
  • Comment. As the original flawed RFC closer, I explained to Trappist the monk that my original thought would be for the category to be named something like Category:CS1 maint: nonhyphenated parameter. My apologies for inadvertently leading to this mess because the reason this category was originally created was because of my initial close. –MJL ‐Talk‐☖ 16:17, 17 April 2021 (UTC)[reply]
  • Rename to something like Category:CS1 maint: nonhyphenated parameter. The current name might be a bit misleading but the category itself has a set maintainance purpose and should be kept. Remagoxer (talk) 18:27, 17 April 2021 (UTC)[reply]
    The category itself has no maintenance purpose whatsoever, since the citations it flags do not need changing as per the RfC. Nikkimaria (talk) 18:35, 17 April 2021 (UTC)[reply]
    (edit conflict) None of these "this has a set maintainance purpose" comments are explaining what that maintenance purpose is or why, in the post-RfC world, people are caring whether parameters use hyphens or not at all. * Pppery * it has begun... 18:39, 17 April 2021 (UTC)[reply]
    There is no obligation for module maintainers to explain the reasoning behind a housekeeping task such as the existence of a tracking/maintenance category. At least I have not seen any policy, guidance or even widespread practice that mandates submission of such tasks for approval by the wider community. Feel free to enlighten me and anybody else who wonders what the fuss is all about. The pathology regarding this non-issue is somewhat amusing. 98.0.246.242 (talk) 22:11, 17 April 2021 (UTC)[reply]
    There is a general obligation for all Wikipedia editors to explain the reasoning behind any decision they make when asked to do so in good faith. Just because something is usually uncontroversial does not mean it always will be or remove the obligation to gain and follow consensus when it is. Indeed complaining about being asked to explain and justify rather than explaining and justifying when asked does not encourage others to view your arguments in good faith. Thryduulf (talk) 11:20, 20 April 2021 (UTC)[reply]
    And you do not think that explanations were provided in this discussion? Even when there is a case to be made that this was not a good faith nomination? Just because there was an RfC of very narrow scope and purpose that was decided solely by counting hands does not mean these or any parameters are placed in a "special" category. They can, and should be, tracked like any other parameter. 24.103.101.218 (talk) 12:47, 20 April 2021 (UTC)[reply]
    Indeed, I do not think that any explanation was actually provided, despite repeated requests from me and from many other editors. I've seen only the unsubstantiated assertions of usefulness or lack of harm, attempts to set up for future relitigation of the RfC, and the tautology The cat is useful to determine the extent of non-hyphenated CS1 param usage (from Tom.Redding's comment), which immediately brings up the question of what the purpose of determin[ing] the extent of non-hyphenated CS1 param usage is. * Pppery * it has begun... 13:06, 20 April 2021 (UTC)[reply]
    Can you tell us what makes tracking these parameters different from any tracking category? I mean apart from forever linking its existence to a personal interpretation of the RfC's close. At least try to provide some evidence of underhand practice or conspiracy before you assign motivation. Or should any tracking category be suspect? They could be used to undermine all sorts of things. Or one could AGF and wait for a crime before rushing to arrest. 66.65.114.61 (talk) 15:21, 20 April 2021 (UTC)[reply]
  • Rename - Wikipedia:Maintenance doesn't forbid tracking categories, nor did the RfC forbid tracking these pages. This category page (discouraged parameter) clearly states this is a tracking category - It is used to build and maintain lists of pages—primarily for the sake of the lists themselves and their use in article and category maintenance. The page also clearly states - There is no need to take any action based on the presence of this tracking category. Yes, it has the wrong name, so what, change the name and move on. I would support Category:CS1 maint: nonhyphenated parameter as well. There are hundreds of pages listed in tracking categories that don't require any action be taken just because they are listed in a tracking category: 5 times per year journals, 20th-century Italian legislators, A Song of Ice and Fire redirects, album chart usages for Australia, articles containing slang terms, archive boxes with unusual parameters – my talk page is listed in this category, and I won't be taking any action just because it's listed there. Isaidnoway (talk) 00:04, 18 April 2021 (UTC)[reply]
    WP:OTHERSTUFFEXISTS is not a persuasive argument. I would personally support deletion of several of the categories you provided as examples. Besides, I (and I presume the many editors who say "per Pppery et al.") don't support deletion solely because the category tracks things for which no action needs to be taken, but because (in my interpretation) the gist of Option C of the big RfC is that editors should not care whether citation parameters are specified as |access-date= or |accessdate= and this category constitutes caring about that difference. By contrast, no consensus says that editors should not care about whether articles use slang, whether archive boxes use the |box-width= parameter, the publication frequency stated in {{infobox journal}}, etc. * Pppery * it has begun... 00:55, 18 April 2021 (UTC)[reply]
    That RfC is not a persuasive argument. It had nothing to do with tracking categories. And no tracking category that I know of has ever been created based on the premise of editors should not care or editors should care about the pages that populate that cat. As noted above, template:tracking category has a specific meaning/definition. Isaidnoway (talk) 09:26, 19 April 2021 (UTC)[reply]
  • Rename and keep. This is a useful tracking category. The RFC close did not mandate that no one "should care about" these parameters - it merely said the templates should support them and a bot should not remove them. Nothing more. MB 01:40, 18 April 2021 (UTC)[reply]
  • Delete. Obviously the name is incorrect as per the new RfC close, and of course if this is kept the name needs changing. However, renaming is not sufficient to address the issues presented by this category.
    1. The category is implemented as a maintenance category. As per the new RfC close, what it's flagging is not something that requires maintenance. This implementation is actively causing issues, such as cluttering up reference popups. If a tracking category is needed at all (see #3 below), this category is not that, no matter what the wording says.
    2. The category was created solely as a function of the initial RfC close, which has now been reversed. Thus it follows that it is appropriate for the categorization also to be reversed. It was not created because anyone independently thought it was a good idea, and the post-hoc justifications do not change that.
    3. When fully populated, the category can be anticipated to have millions of entries. Something that huge should have a comparatively strong rationale behind it; none has been presented. Rationales so far have suggested it's "useful" but have not specified for what purpose, or why a less invasive solution such as searching is inadequate for whatever those needs may be. The fact that other tracking categories exist is not a rationale to make more of them (possibly others may warrant deletion, but this isn't the place to address that).
    4. Also per Thryduulf. Nikkimaria (talk) 02:12, 18 April 2021 (UTC)[reply]
    If you look at the proper place to discuss this (that is Help_talk:Citation_Style_1#RFC_reclosed, not here), you will see that the category will likely be renamed to a more neutral name (although the second closure of the RfC does in no way mandant this) and changed to a mere tracking category, so it won't cause any visual clutter, but is still there for those to inspect who care about it. This is nothing new, we are doing this for all kinds of other properties as well - and for years, and we do not need RfCs or CfDs for this. And if the OP wouldn't have decided to undermine the normal good-faith process by starting a totally unnecessary parallel discussion here instead of participating there, we would likely be further already in adjusting stuff according to the outcome of the RfC.
    However, if there is one thing that the RfC has shown, it is that there are two very large community groups of people with opposing views who do care about the topic. The fact, that the RfC could be closed in vastly different ways within just a couple of days also demonstrates that there is no true underlying consensus in the community in regard to the topic. A good RfC closure can still indicate some path how to proceed, but it cannot keep people from having opinions just because someone says so. Among well-meaning people it should be possible to find a workable solution and, if the arguments are good, to even convince one another in peace rather than attempt to force people to act in undesired ways.
    Either way, it is clear that this is, unfortunately, a topic that will continue to interest people of both sides for years to come and the second closure has further enlarged this interest. So, even if this particular category is new, it is clear, that it is needed now even more than it was before the RfC. One of the fundamental ideas of Wikipedia in general, and for citations specifically, is to present knowledge based on provable facts and in a neutral way. This tracking category helps to get insight. People who are trying to suppress facts-based information gathering are not in line with our principles, they are agenda-driven trouble-makers harming the project.
    --Matthiaspaul (talk) 09:31, 18 April 2021 (UTC)[reply]
    I have not only looked but have participated in the discussions at CS1 (Help_talk:Citation_Style_1#RFC_reclosed and Help_talk:Citation_Style_1#Protected_edit_request_on_16_April_2021); they have convinced me to post here. Simply renaming (never mind keeping as-is, as suggested above) is not a viable solution given the RfC, and name-calling is not a viable means of working towards a collaborative solution. Nikkimaria (talk) 00:51, 19 April 2021 (UTC)[reply]
    There is nothing in the (second) closing that prohibits a tracking category for non-hyphenated parameters. The RfC option chosen, among other things, removes "discouraged" as a description for such parameters. As long as a category name adheres to that nomenclature, what is the problem? The RfC decided a very specific issue. Other than that narrow scope, there is nothing to say. The RfC close certainly did not dictate what editors should be interested in or not, never mind the "personal interpretation" of the "gist" of the RfC by Pppery. So why is such a category not "viable"? 98.0.246.242 (talk) 02:05, 19 April 2021 (UTC)[reply]
    The category was implemented only as a result of the first closure; since that's been undone, so too should the changes resulting from it. Nikkimaria (talk) 01:16, 20 April 2021 (UTC)[reply]
    Not necessarily. The category should be renamed to comply with the RfC, and that is about it. It was created because of the superseded close, but that does not mean that it is useless otherwise. Parameter usage is regularly tracked in CS1/2 for a variety of reasons or no reason, for purely informational purposes. The fact that similar information can be found with a properly structured search is neither here nor there. Such logic invalidates the existence of any tracking/maintenance category, not just the one under discussion. 98.0.246.242 (talk) 04:44, 20 April 2021 (UTC)[reply]
    Yes necessarily. Looking at the bigger picture: no one thought a tracking category would be useful in the events leading up to the RfC, or during the RfC itself. This maintenance category was implemented solely because of an RfC close that has since been undone. Post-hoc justifications are now being made to try to maintain elements of that undone close and undermine the intentions of the new close. In that context, this is not a typical tracking category, not something solely informational (see the suggestion below that it could be used for mass edits), and not something uncontroversial. Nikkimaria (talk) 12:49, 20 April 2021 (UTC)[reply]
    It may come as a surprise that maintenance categories often result, or are used to determine the need for mass edits. This category is no different, with one exception: per the RfC, it cannot be used to deprecate, remove, or "discourage" the usage, of the parameters it covers. Just like any other RfC, this applies until another RfC decides differently. This could be next week or never. And there we are. There are no post-hoc justifications, because nobody needs to justify such use. Actually, following the extraordinary RfC process, it would not be surprising to ask that such a category be created, if it hadn't existed already. Just to give an easily accessible ongoing picture of the related usage. The controversy here could be that some consider this a controversy. 66.65.114.61 (talk) 15:21, 20 April 2021 (UTC)[reply]
    It's not a surprise at all, and that's my point. If another RfC reaches a different conclusion in future, then a maintenance category to facilitate mass editing may be appropriate, and such a category could easily be implemented at that point. But that's not where we are today. Nikkimaria (talk) 01:51, 21 April 2021 (UTC)[reply]
    First, the existence of a tracking category does not mean any mass edits will happen. Secondly this category does no harm. And as long as it complies with the RfC, there is no issue. Any tracking category can be implemented at any time. Who decides when? I trust the editors of the related project to propose when they should be created. Whatever the related project is, the existence of such maintenance categories should be discussed at the project's talk page. Not as a part of a prejudicial nomination at CfD. 71.167.45.141 (talk) 13:06, 21 April 2021 (UTC)[reply]
    This implementation is actively causing issues, such as cluttering up reference popups. Where?
    For this category, this is the markup emitted by cs1|2 templates:
    <span class="cs1-maint citation-comment">CS1 maint: discouraged parameter ([[:Category:CS1 maint: discouraged parameter|link]])</span>[[Category:CS1 maint: discouraged parameter]]
    which MediaWiki modifies to this:
    <span class="cs1-maint citation-comment">CS1 maint: discouraged parameter (<a href="/wiki/Category:CS1_maint:_discouraged_parameter" title="Category:CS1 maint: discouraged parameter">link</a>)</span> – the category link from the template is listed elsewhere in the html source with all of the other categories attached to the article
    The css class, cs1-maint, is defined at Module:Citation/CS1/styles.css at line 92 which, as you can see, hides the messaging by setting display to none. The css class, citation-comment, is not defined by cs1|2 but is a legacy form that remains available to editors for use as they see fit.
    To see the maintenance messaging, editors need to use some sort of css in their custom .css pages. This is described at Help:CS1 errors § Controlling error message display. None of your .css pages have this css (or its citation-comment legacy form). It is possible that a script in one of your .js pages is applying the css for you. If it isn't a script, perhaps your chosen skin is ignoring the markup. If not your chosen skin then perhaps you have custom css in your browser.
    When I open an incognito browser and, without logging in, look at any article in Category:CS1 maint: discouraged parameter (how easy that is...) I don't see any maintenance messages in the references that popup when I hover over a reference superscript. That suggests to me that the issue is not with cs1|2 but with something custom to your browser, to your scripts, to your skin. When you discover the cause, let us know so that we can document it at Help:CS1 errors.
    —Trappist the monk (talk) 16:29, 18 April 2021 (UTC)[reply]
    WP:POPUPS. Nikkimaria (talk) 00:51, 19 April 2021 (UTC)[reply]
    Looks like that tool is pretty oddly crippled. Examples:
    • text rendered by templates, in this case {{lang-fr}}, is omitted; see Canadian Confederation – empty parentheses following bolded article title in the lede
    • the tool ignores css in some cases but applies it in others
      • redlinks aren't displayed as redlinks; see Peter Turk#Prizes where both links are redlinks (Permalink). Redlinks are styled by class="new" – don't know where new is defined
      • cite errors (created by cite.php) are styled in the popup; click this link and hover over the reference 32 superscript to see a styled error message; that styling is applied by class="error mw-ext-cite-error" – don't know where error and mw-ext-cite-error are defined
      • cite errors (created by Module:Citation/CS1) are styled in the popup, even those that are hidden; click this link and hover over the reference 1 superscript to see a styled error message; that styling is provided by class="cs1-hidden-error error citation-comment" – cs1-hidden-error is defined at Module:Citation/CS1/styles.css at line 83, citation-comment is not defined as described above, don't know where error is defined
    These limitations are not the fault of cs1|2, so these issues should be taken up elsewhere; see Wikipedia:Tools/Navigation popups § Feedback.
    —Trappist the monk (talk) 14:02, 19 April 2021 (UTC)[reply]
    Using a gadget last seriously developed c. 2010 (and only maintained in elementary ways since) will break in ways similar to Ttm's listing. If you are seeing crud in it, it is decidedly the fault of that gadget. Izno (talk) 15:15, 19 April 2021 (UTC)[reply]
  • Delete because of sheer size, nobody is going to inspect a category with as much as 630,000 entries, regardless whether it is for content or for maintenance purposes. Marcocapelle (talk) 10:46, 18 April 2021 (UTC)[reply]
    Is this a new rule? I did not know that categories are to be deleted when they reach a certain size. And what size might that be? 98.0.246.242 (talk) 18:56, 18 April 2021 (UTC)[reply]
    • The "rule" is not about size but about purpose. Categories are created for the purpose of easy navigation between similar articles, or for the purpose of maintenance. Neither easy navigation nor maintenance can realistically be achieved with a size like this. Marcocapelle (talk) 19:48, 18 April 2021 (UTC)[reply]
      I am glad that size has nothing to do with this rule. Is there a category that includes categories that have unrealistic expectations of navigation or maintenance due to... size...?? Maybe I can help in their deletion. To get a better idea of what I should be doing, please point me to the log of such deletions, and the attendant rationale. 98.0.246.242 (talk) 19:57, 18 April 2021 (UTC)[reply]
      This "large categories are useless" argument is incorrect. The size of this tracking category will give editors useful information about how many pages will be affected by any proposed change or mass edit proposed in a future RFC. Other tracking methods, including insource searches, are not as accurate as tracking categories. Tracking categories can easily be intersected with other categories and templates using Petscan to look for a wide variety of conditions in pages. As for the usefulness of category size, Category:Living people currently has 996,154 pages, but that is not seen as a problem by the community. Editors can make decisions about mass edits and perform intersection searches using categories of this (or any other) size. – Jonesey95 (talk) 17:50, 19 April 2021 (UTC)[reply]
      Searches provide sufficiently granular information for any future RfC. Editors should not be making mass edits based on this category - this is a rationale for deletion, to avoid that kind of behaviour. Nikkimaria (talk) 01:16, 20 April 2021 (UTC)[reply]
      • I wonder where all these new rules come from. Why is any category considered "permanent"? Why is a so-called permanent category prohibited from certain purposes that may be related to it? Why should editors not be making mass edits based on certain categories? Are there any objective answers? Or is it just throwing something in the argument to see if it sticks. 98.0.246.242 (talk) 04:31, 20 April 2021 (UTC)[reply]
Oh. Your comment about size, which started this sub-thread, seemed like a novel position, not exactly related to the nom"s rationale. 98.13.214.238 (talk) 18:28, 20 April 2021 (UTC)[reply]
  • Your comments are getting very confusing. We were discussing my edit of 21:24, 19 April 2021 about which you said "why is any category considered permanent" and now all of a sudden you skip back to the beginning of the thread. We have been there already, there is no use in repeating that part of the discussion. Marcocapelle (talk) 19:37, 20 April 2021 (UTC)[reply]
    Sorry about the confusion, the objective is clarity. Even though this sub-thread is a sideshow, there should be no loose ends. Following the questions about size, you seemed to shift focus to using search expressions instead of keeping categories. Compared to the size issue, this is a counterintuitive position. Anyone who has used even simple searches in Wikipedia knows of the engine's hiccups as the search (no matter how focussed) tries to cover the entire mainspace. A tracking category is a much more efficient and simpler solution when the category is overpopulated. Secondly, the category lifespan was also a novel issue. Why is the permanence or impermanence of a category relevant at present? And who can foretell a category's lifespan? 107.14.54.1 (talk) 21:24, 20 April 2021 (UTC)[reply]
    • A category is a permanent solution per definition, or at least for indefinite time. An RFC is a single event. We do not need a category as a permanent solution on behalf of an article count for an RFC as a single event. The article count can happen if and when the RFC takes place. Marcocapelle (talk) 03:41, 21 April 2021 (UTC)[reply]
      Where have you seen such a definition for categories? Tracking categories especially? They are all project-related and that determines their existence. As an aside, RfCs don't exist in a vacuum. Your opinion that they constitute single events is noted. As is your opinion implying that tracking categories are only used for article counts. Tracking categories track (for a variety of reasons). A count is a single track snapshot. I understand that you don't need such a category. Others do though. 71.167.45.141 (talk) 13:21, 21 April 2021 (UTC)[reply]
  • Keep and Rename as suggested above. The category can be used for multiple tracking purposes as discussed above, including providing data to make the case that non-hyphenated variants are popular enough to continue supporting. More to the point, the RfC at issue does not forbid such a tracking category in its second close. Imzadi 1979 → 01:21, 19 April 2021 (UTC)[reply]
  • Delete. Tracking variations in how users are correctly using templates should not be done with categories. -M.Nelson (talk) 09:19, 19 April 2021 (UTC)[reply]
    Why not? Please explain. 24.103.251.114 (talk) 12:03, 19 April 2021 (UTC)[reply]
    M.Nelson: Tracking categories are used for this purpose all the time. Many examples are given above. – Jonesey95 (talk) 17:50, 19 April 2021 (UTC)[reply]
  • Delete per Pppery. --Just N. (talk) 12:02, 20 April 2021 (UTC)[reply]
  • Keep - It's an invisible maintenance category pertaining to a minor bit of an incredibly-extensively-used template set that is under constant, active development. A bunch of randos that aren't involved in that development have no business trying to decide how those templates should be maintained as drive-by editors for a single one-off category out of many. --PresN 02:59, 21 April 2021 (UTC)[reply]
  • Delete per Pppery. Only in death does duty end (talk) 07:48, 21 April 2021 (UTC)[reply]
  • Delete, tracking category for something that isn't an issue and hence shouldn't be tracked. (Alternatively, create another categeory for use hyphenated parameters). —Kusma (𐍄·𐌺) 08:59, 21 April 2021 (UTC)[reply]
    Tracking categories can be created at any time for any reason related to the relevant project. They don't require a specific "issue". I recommend heading to the project talk page and voicing your opinion, with justification (please), over there. Btw, that category is being renamed to comply with the RfC both in spirit and letter. 50.74.165.202 (talk) 14:15, 21 April 2021 (UTC)[reply]
  • Delete per Pppery. At what point is the issue of reference param hyphenation an example of Wikipedia:Do not disrupt Wikipedia to illustrate a point? -- Mikeblas (talk) 14:06, 21 April 2021 (UTC)[reply]
    You should ask the nominator. Since the relevant category was renamed to comply with the RfC, this may be a frivolous nomination, a good example of the link you posted. 50.74.165.202 (talk) 14:15, 21 April 2021 (UTC)[reply]
  • Keep per Izno. Not only was the work of CS1 maintainers disrupted by the RfC, nominating their maintenance categories for deletion is just flat-out unnecessary. Let them do their work instead of making it harder. Elli (talk | contribs) 18:25, 21 April 2021 (UTC)[reply]
    • It's the other way around: it was the CS1 maintainers who disrupted the work of the rest of us by deprecating and converting nonhyphenated parameters. The RfC was what was necessary to convince them to stop. Levivich harass/hound 14:41, 23 April 2021 (UTC)[reply]
  • Keep, but rename to Category:CS1 properties: unhyphenated parameter aliases since there is a valid use for maintaining a list of articles using these parameters in case consensus changes as to getting rid of these parameters. I choose this name because, as far as the modules are concerned, |access-date= is the canonical form while |accessdate= is an alias. I don't think that has been disputed as a matter of fact or policy. Besides, it helps avoid the sheer irony of having to debate whether to use "multi-word" or "multiword" for the category name. I hope the name is clear enough to make it clear that it's not just any CS1 parameter alias that lacks hyphens. -BRAINULATOR9 (TALK) 21:02, 21 April 2021 (UTC)[reply]
    In the event consensus changes, the category can easily be recreated. And I do dispute that |access-date= is the canonical form while |accessdate= is an alias. That's yet another attempt to overturn the fundamental tenet of Option C of the RfC, which is that access-date should not be preferred to accessdate. Calling one of them "canonical" and the other an "alias", or (as this category in its current name does) calling one of them "discouraged", or even treating one of them differently than the other, are all end-runs around consensus. * Pppery * it has begun... 21:35, 21 April 2021 (UTC)[reply]
    That's yet another attempt to overturn the fundamental tenet of Option C of the RfC, which is that access-date should not be preferred to accessdate. It is not at all clear to me that the Option C of the RfC says any such thing. Can you quote the actual text from the close that supports your assertion? This RFC from May–July 2014, established hyphenated parameters as the form for "normal use" which I take to mean the 'canonical' form. As far as I can tell, the 2021 RfC does not overturn the 2014 RfC.
    —Trappist the monk (talk) 23:14, 21 April 2021 (UTC)[reply]
    This is what the RfC decided:

    Option C: Non-hyphenated parameters should not be deprecated; deprecation should not be continued and bot approval should be revoked. This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters.

    It is here: WP:VPPR#RFC: Citation Style 1 parameter naming convention. Nothing about categories, or canonical forms. Before the ill-fated deprecation, and for quite a long time, non-hyphenated labels were described in the relevant documentation as "aliases", with the primary, and by default canonical, labels being the hyphenated ones. It is true that the category came about because of the overturned close. In the meantime, the editors most involved in this area thought it a good idea anyway. And it does not impact the second close a all, especially since it was in the process of being renamed in accord with the RfC result before this nomination. FWIW I consider even renaming the category as a good-faith concession. 98.0.246.242 (talk) 23:46, 21 April 2021 (UTC)[reply]
    @Pppery: What I meant was that the module, as far as the programming is concerned, considers |access-date= to be the default form. You can see this by going into the VisualEditor and adding a {{cite web}} template with the URL access date specified; this is done in the same capacity as every other template. The RFC was not about making |accessdate= the default form, it was just about whether or not to keep these parameters. -BRAINULATOR9 (TALK) 19:23, 23 April 2021 (UTC)[reply]
    Oh, yes, I missed that in some contexts there had to be one "canonical" form. In that case I do agree it is reasonable for the canonical form to be the hyphenated one. * Pppery * it has begun... 20:24, 23 April 2021 (UTC)[reply]
    Technically the RfC was about whether certain parameter aliases should be removed from the code and the documentation. There was never any talk of removing parameters. The hyphenated forms were established as the primary arguments some time before the unhyphenated parameter labels started being deprecated (it had been happening in stages for a while). In my experience I have yet to encounter software, especially user-facing one, that did not employ canonical forms, whatever the name given to such forms. 64.61.73.84 (talk) 23:05, 23 April 2021 (UTC)[reply]
  • Delete, this is a really annoying category that shows up with a lot of green labeled errors within the references. I've got it where I can see what the errors are, and this is just taking up time, and the difference between hypenated or not is really not that important. --Funandtrvl (talk) 23:26, 22 April 2021 (UTC)[reply]
    When you have the following code in your Custom CSS, this will show the errors, so that you can figure out which references (when there are many) that you need to fix. Because this category has over 800K+ entries, the code "CS1 maint: discouraged parameter" will show up after the affected reference listing on many articles, and because it's not really an error, it takes time to look through it and ignore it, to find the real errors that need to be fixed. This is so annoying, and practically defeats the purpose, since that there are so many. If someone could figure out how to eliminate this category's error codes showing up, that would be great. Please note that even if the category is renamed, the multiple error codes will still show up and clutter up the references with time-consuming work. .mw-parser-output span.cs1-maint {display: inline;} /* display Citation Style 1 maintenance messages */ .mw-parser-output span.cs1-hidden-error {display: inline;} /* display hidden Citation Style 1 error messages */ --Funandtrvl (talk) 23:42, 22 April 2021 (UTC)[reply]
    I encourage you to read the above discussion more closely, and also the related threads at Help talk:Citation Style 1. Before this discussion, and following the RfC reclose, there were discussions about how to best remedy the situation. This unfortunate nomination, which seeks to expand the RfC mandate into novel territory, caused at least some delay. This is a module collection whose parts have to be kept in sync, and which impacts millions of pages. The maintainers have to proceed carefully. In general though, I agree that there is a preponderance of error messages. Not just in this project, which is big and complicated, in Wikipedia as a whole. There are other, more rational ways to signal editors, but that is a different discussion. 98.0.246.242 (talk) 00:09, 23 April 2021 (UTC)[reply]
  • Am I the only one who thinks it's really weird that there are multiple IPs bludgeoning a CFD about a recently-created maintenance category? Are the IPs multiple editors or just one editor? Can/do IP editors edit modules? Levivich harass/hound 14:41, 23 April 2021 (UTC)[reply]
    I think it's just one person using a dynamic IP address, and there's nothing wrong with that. And, for what it's worth, IP editors can edit the module namespace, although they rarely do. At the time I write this comment, there have been only 16 edits by IPs to the module namespace in the last month that aren't tests or vandalism. Of course, IPs can't edit high-risk modules since they are template protected -- but neither can most registered users. * Pppery * it has begun... 15:47, 23 April 2021 (UTC)[reply]
    A familiar line of irrelevant questions. Do not talk to the "IP", talk to the argument. This is not a social occasion. 98.0.246.242 (talk) 17:04, 23 April 2021 (UTC)[reply]
  • Keep or Rename - I don't see the harm in a list of pages... it gives me another list of pages to work on ;-) Quebec99 (talk) 14:39, 23 April 2021 (UTC)[reply]
    • What work would you do with that list? (The question no "rename" !voter seems able to answer...) Levivich harass/hound 14:43, 23 April 2021 (UTC)[reply]
      Good point, if using a hyphen or not isn't presently a maintenance issue, why the busy work?? --Funandtrvl (talk) 18:21, 23 April 2021 (UTC)[reply]
      It is a tracking category. It does not necessarily require "issues". It could be gone tomorrow or never. By all means make your displeasure known at the project talk page. If you believe you have a valid argument for deletion that is not heeded, present that argument in a new nomination here, where tracking categories are considered, and deleted, on an hourly basis. However the primary reason for this discussion is the nominator's linking of the category with the result of an RfC (while steps were being considered in order to comply). The questions about the usefulness of the category by itself, are a later development and they came about after it was pointed out that this category may have a purpose of its own. That is an issue unaccounted and unrelated to the nomination. 98.0.246.242 (talk) 22:18, 23 April 2021 (UTC)[reply]
  • delete. I am here as I noticed it in the FA currently on the main page, thinking it highly unusual that a FA would be in a maintenance category. Or at least in one more than briefly, as the issue gets fixed. There is nothing to fix though, the category explicitly says no action should be taken, so it serves no purpose. Except it does indicate the scale of the "problem", 920,000+ articles, about 15% of the encyclopaedia. Now that is known, and there is no prospect of these "errors" being "fixed", the category should be disabled.2A00:23C8:4588:B01:1480:A90:FF20:61AE (talk) 03:45, 25 April 2021 (UTC)[reply]
    Apparently, what happened is that the citation that added the currently-discouraged parameter (according to the module) was added today. I don't plan to change it, but that might be worth noting. -BRAINULATOR9 (TALK) 16:23, 25 April 2021 (UTC)[reply]
  • Keep. The maintenance category may be useful. But stop putting articles that use accessdate instead of access-date into it. What possible purpose would be served by changing from one style to the other? Aymatth2 (talk) 01:43, 27 April 2021 (UTC)[reply]
    @Aymatth2: This keep argument makes no sense. The sole purpose of this category is contain, in your words, articles that use accessdate instead of access-date. A delete closure here will not stop the CS1 developers from declaring another unrelated set of parameters discouraged and repopulating this category. Categories aren't kept because they might be needed in the future; they are created if and when they are needed. (Unless you are intending to imply that |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= should still populate this category, but it's just as much changing from one style to the other for those parameters as well, so I don't think that's what you intended) * Pppery * it has begun... 02:03, 27 April 2021 (UTC)[reply]
    It makes sense. Continue to encourage hyphenated parameters, but stop discouraging unhyphenated (un-hyphenated?) ones, so the population of this category drops from 986,131 to 0. Clean out the list of hyphen-deficient parameters from the category explanation, but keep it for future use in maintenance. I note, however, that it shows up on articles like Paul Hoberg Airport that do not use CS1, so maybe another name would be appropriate. Aymatth2 (talk) 12:21, 27 April 2021 (UTC)[reply]
    What you're suggesting is the opposite of the RFC outcome. The community doesn't want the category to drop to 0. That's why this category has no purpose or use and never will. Again I ask: what would you use the category for? What purpose? What future use in maintenance exactly? Levivich harass/hound 14:01, 27 April 2021 (UTC)[reply]
    @Levivich: I think that by stop discouraging unhyphenated (un-hyphenated?) ones, so the population of this category drops from 986,131 to 0, Aymatth2 means remove the code that populates this category, not remove all unhyphenated parameters. He then wants to keep the resulting empty category, which is why he !voted keep instead of delete. * Pppery * it has begun... 14:16, 27 April 2021 (UTC)[reply]
    Oh I see, like "keep don't rename". Levivich harass/hound 14:29, 27 April 2021 (UTC)[reply]
    "The community doesn't want the category to drop to 0.": precisely. How would you know if it dropped to 0, or saw it decrease drastically, if it doesn't exist?   ~ Tom.Reding (talk ⋅dgaf)  14:21, 27 April 2021 (UTC)[reply]
    The community would know for the same reason it knew (and moaned) about Monkbot 18. There's no way of editing hundreds of thousands of pages (which would be required for a category with almost a million pages to decrease drastically) without someone noticing the edits on their watchlist. * Pppery * it has begun... 14:25, 27 April 2021 (UTC)[reply]
    Not to spill the WP:BEANS or anything, but I (or anyone modestly knowledgeable) could easily find small, non-hyphenated pages, with very few editors, and do a lot of hyphenation under-the-radar, if I they wanted to.   ~ Tom.Reding (talk ⋅dgaf)  14:39, 27 April 2021 (UTC)[reply]
    If the hyphen-challenged parameters are to be replaced, it should be done by a bot. That way my watch-list will not be flooded. Aymatth2 (talk) 15:24, 27 April 2021 (UTC)[reply]
    It may be simpler than all this. Is module maintenance to be decided @ CfD? Further, should it be decided as a result of a nomination some consider suspect, and a misapplication of an RfC mandate? Or should this nomination be withdrawn? 71.167.45.141 (talk) 11:43, 28 April 2021 (UTC)[reply]
  • Delete. Since the RfC established that these parameters should not be deprecated, I don't understand the value of a category to track them on over a million pages. I've skimmed the discussion here and on the CS1 talk page and don't see a convincing reason. Did I mis it? The reason to not have this category is its existence means some well-intentioned editors will think something needs to be done, as we see in some of the comments above, which is unnecessary work and goes against the RfC's consensus. — The Earwig (talk) 16:34, 1 May 2021 (UTC)[reply]
    It seems that skimming the discussions may be responsible for the above, as they have been thoroughly gone through previously. The only thing to note (and in the comment by Snowfire below) is the idea that some editors may feel compelled to do something (presumably needless or detrimental) based on the existence of a tracking category. Theoretically, some editors may needlessly do that regarding any tracking category, or anything else. And again theoretically, these edits may be unnecessary or detrimental. Apart from that, is there any evidence this would happen here? Even if the category is not renamed? Or, as has been pointed out perhaps we should wait for this to actually happen before jumping the gun. 98.0.246.242 (talk) 12:16, 2 May 2021 (UTC)[reply]
    Yes, there is such evidence. See for example the "discouraged parameters" edits in these contributions (by someone participating here and therefore who should be aware that these parameters are not actually discouraged). So not a theoretical concern. I believe Fram had pointed out another such case at ANI, so also not an isolated problem user. Nikkimaria (talk) 12:42, 2 May 2021 (UTC)[reply]
    You have it backwards. The category was in the process of being renamed before this nom threw a wrench in the process. That is why it is still called "discouraged". Secondly, anyone can edit the unhyphenated parameters into hyphenated ones, this action does not fall under the RfQ. That RfQ only forbid the deprecation of hyphenated parameters, it did not mandate a specific choice. It did not even mandate a characterization of the parameters as "non-discouraged". But I have no problem of removing the "discouraged" moniker if and when you let that happen. The editor you referred to was making maintenance edits based on the current state of affairs. His summary is understandable. 50.74.165.202 (talk) 14:39, 3 May 2021 (UTC)[reply]
    "Secondly, anyone can edit the unhyphenated parameters into hyphenated ones, this action does not fall under the RfC" - Nope, definitely not. Nobody should be doing that, especially not on a large scale. Both hyphenated and unhyphenated are acceptable, that's the outcome of the RFC, and no one should be going around changing one to the other. That's why this tracking category would be not only useless, but even harmful, if it's used by editors to change hyphenated to nonhyphenated or vice versa, because that would be against consensus. Levivich harass/hound 15:20, 3 May 2021 (UTC)[reply]
    Do read the RfC mandate (to apply Option C as the RfC decision). This was only about the treatment of certain parameter aliases by the module collection Citation/CS1, the dependent templates, and the related documentation. And the behavior of an associated bot. There is nothing about categories, or directives to editors not to edit something or other. The RfC applies to the module maintainers, and in a very narrow sense, regarding the non-deprecation of six aliases. 64.18.9.203 (talk) 18:55, 3 May 2021 (UTC)[reply]
    The RFC isn't the only relevant global consensus. Changing from nonhyphenated to hyphenated is a WP:COSMETIC edit. An editor making such mass edits without using a bot would still be editing against the RFC consensus per WP:MEATBOT (and maybe WP:CITEVAR). That's why no one can go through this category and change all the nonhyphenated parameters to hyphenated parameters. And that's why the category is unnecessary. Levivich harass/hound 19:54, 3 May 2021 (UTC)[reply]
    Well re-read this nomination then, that specifically ties the proposed deletion to the RfC outcome. As for the rest, the opinion that this involves cosmetic edits is neither here nor there. Another may have the opinion that these are necessary edits for consistency, efficiency and clarity. WP:CITEVAR does not apply because this is wholly within one citation scheme. Anyone can go through any category and make mass edits based on that category. Should all categories be nominated for deletion? 98.0.246.242 (talk) 23:50, 3 May 2021 (UTC)[reply]
    Anyone can go through any category and make mass edits based on that category. Exactly! As others have pointed out here, it's very likely that someone will do exactly that, which is why this category should be deleted: to stop anybody from making mass edits based on this category. Levivich harass/hound 00:09, 4 May 2021 (UTC)[reply]
    Of course, it makes perfect sense that this may or may not happen. But let's be thorough. The search engine should be modified so that any search that includes a regex referencing unhyphenated parameters is routed to a blackhole. The search results could be used to make mass edits of some sort. 98.0.246.242 (talk) 01:32, 4 May 2021 (UTC)[reply]
  • Delete per delete arguments. There's nothing wrong with tracking actually discouraged parameters, but per the RFC, the only thing currently tracked by this parameter is not discouraged not deprecated, and is perfectly harmless. Tracking it just encourages well-meaning editors to believe that there's some problem for them to solve, when no such thing is true. SnowFire (talk) 21:51, 1 May 2021 (UTC)[reply]
  • Rename/don't delete. Consensus has said not to change the parameters. Thus, this shouldn't be a maintenance category, and shouldn't appear on the page to people who have signed up for CS1 maintenance templates to show on the page. The correct response to that is to make it a a different type of category with different CSS to view, not to delete it. The maintainers of the template are entitled to keep a count of how many people are using their template in a certain way, and as long as they make it clear that people shouldn't go changing it to be the other way, I don't think there's any point in us telling them what they do and do not get to keep track of. Also, everyone, please WP:AGF. Tamwin (talk) 07:15, 2 May 2021 (UTC)[reply]
  • Keep/rename - the cited RfC did not find any consensus to delete this category. No other deletion reason is given by the nominator, and no attempt seems to have been made on the talk page to discuss any issues with the maintainers. --Joshua Issac (talk) 13:11, 2 May 2021 (UTC)[reply]
  • Rename per Tom.Reding and Tamwin. I was going to !vote delete, but the existence of the category doesn't harm anyone, so long as the category name doesn't imply that the absence of hyphens in these parameter names is wrong. — OwenBlacker (he/him; Talk; please {{ping}} me in replies) 21:19, 4 May 2021 (UTC)[reply]
  • Delete this polarising non-issue. It seems a half-step towards deprecation although the proposers of this category seem not to mention the reason behind it. Monitoring it is one thing, but labelling it "discouraged" implies a valued judgement and a certain motivation to do something about it. If I hadn't engaged my brain on the futility of the exercise, I would have adapted my script to add hyphens to those concerned parameters. However, most editors don't care whether a date parameter has hyphens or not, especially when these are all properly aliased and don't result in display errors. I wouldn't like to see discussions further down the line about removing or keeping the parameter. -- Ohc ¡digame! 22:03, 4 May 2021 (UTC)[reply]
    Well, this is amusing, but I believe it is not going to be long before the uninformed and irrelevant commentary produces enough entropy for ennui to set in. It may be time for this charade of a nomination to be retired. I don't think it deserves a closing decision or opinion of any kind, just withdraw it. 98.0.246.242 (talk) 00:36, 5 May 2021 (UTC)[reply]
    It's unfortunate that CfD is chronically short on closing admins and thus this discussion has been unclosed for so long, but aborting it without a closing statement is not the answer. Nor do I see what makes Ohc's comment uninformed and irrelevant, or Fram's nomination a charade. * Pppery * it has begun... 00:40, 5 May 2021 (UTC)[reply]
    I guess that we just have to accept their trolling as a fact of life. We're talking about potentially deprecating a parameter that is used in 1.2 million articles, meaning that a sixth of the articles here have been meaninglessly tagged with an error message indicating it was "discouraged". Then again, if the green error messages hadn't appeared, I wouldn't have even been aware of this change. -- Ohc ¡digame! 07:15, 5 May 2021 (UTC)[reply]
We are not talking about "potentially" doing anything. A "potential" application of a category is not a reason for deletion. Another may think that this category has "potential" for great things. These "may or may not" contingencies and personal "feelings" about the category are irrelevant. None of the above is the reasoning for this nomination which has to do with an RfC close. The comments about "discouraged" parameters are simply uninformed. That moniker was an effort to comply with the previous, overturned RfC opinion, as was the creation of this category. This faulty nomination seeks to expand a contentious RfC close into dictating the fate of a tracking category. The rationale behind the workings and existence of CfD may have to be reexamined. In the meantime, we are having fun until all such fun can be had. 65.204.10.232 (talk) 17:09, 5 May 2021 (UTC)[reply]
  • Delete per nom and Thryduulf et al. There seems to have been a lot of refusal to drop the stick from those who wanted to "discourage" or "deprecate" the non-hyphenated parameters, and Wikilawyering the close to suggest that those parameters are still second-class citizens compared with their hyphenated cousins. But that's not true. The decision was to continue allowing them and turn off the bots, which means that they are still fully supported and fully permitted parameters. As such, there is no reason for a site-wide template to be "tracking" those parameters. If editors really want to generate a list of them, in order to shake their fists at the screen at the injustice of it all, then they should write a script for that off-wiki, or in their own user spaces. It's time to delete this template (as appears to be the consensus already in this discussion) and move on from this debacle. Cheers  — Amakuru (talk) 11:58, 5 May 2021 (UTC)[reply]
Another opinion that adds nothing that has not being discussed above at length. It does add novel items that have nothing to do with the matter at hand. I do agree with the sentiment expressed by Pppery about lack of proper administration in CfD. The continuing existence of this nom is in my opinion, an indication. Not just a faulty nomination but also one that refuses to die. In the meantime the irrelevant and uninformed comments pile on. Nice! 65.204.10.232 (talk) 17:09, 5 May 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Theistic finitism

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:44, 27 April 2021 (UTC)[reply]
Nominator's rationale: merge delete per WP:SMALLCAT, contains the main article and an article about a book. Marcocapelle (talk) 12:40, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:19th-century Roman Catholic bishops in Czech Republic

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: merge to Category:19th-century Roman Catholic bishops in Austria-Hungary. Good Ol’factory (talk) 00:41, 5 May 2021 (UTC)[reply]
Nominator's rationale: for consistency with Category:20th-century Roman Catholic bishops in the Czech Republic, Category:21st-century Roman Catholic bishops in the Czech Republic. BenKuykendall (talk) 09:00, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Moths by non-island country

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: merge to continental categories, which is consistent with the stronger consensus at Wikipedia:Categories_for_discussion/Log/2021_April_13#Butterflies_by_non-island_country. List articles will need merging to additional parents. – Fayenatic London 06:42, 16 May 2021 (UTC)[reply]

Please delete:

Since moths don't know anything about the borders of these countries, many of them will have ranges which cross national borders to the point of making these category divisions meaningless. Animal lover 666 (talk) 07:28, 16 April 2021 (UTC)[reply]

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:People with synesthesia

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Jc37's points about OR and BLP are significant. Good Ol’factory (talk) 04:03, 28 May 2021 (UTC)[reply]
Nominator's rationale: delete, non-defining characteristic and it is a previously deleted category, see this discussion. Marcocapelle (talk) 07:13, 16 April 2021 (UTC)[reply]
  • Speedy Delete Per WP:G4, recreation of a page that was deleted per a deletion discussion. - RevelationDirect (talk) 23:08, 16 April 2021 (UTC)[reply]
  • Keep The previous discussion had minimal participation, and it is unclear why the given arguments for non-definingness are always valid. Most of the members seem to be musicians who associate sound with colors. –LaundryPizza03 (dc̄) 06:15, 17 April 2021 (UTC)[reply]
    • With only a few exceptions, having synesthesia is mentioned as a brief note in the "Personal life" section of the articles. If musicians with synesthesia is a notable topic in its own right, by all means write an article about the topic. Marcocapelle (talk) 07:36, 17 April 2021 (UTC)[reply]
  • Keep That is an information that I would want to look up by categories' help. It is a defining personality trait as far as I see it. And no, not a good idea to give an extortive remark about a missing article. If Marco needs an article he is empowered to provide it as anyone else. --Just N. (talk) 12:14, 20 April 2021 (UTC)[reply]
  • Delete - List of people with synesthesia is tagged with WP:OR. Please address this in the list and such related articles first, then discuss whether there should even be a category (WP:V and WP:CLS). As things stand, even if we don't talk about WP:DEFINING (itself another issue here), this category current exists merely as OR, and per WP:CAT and WP:BLP, this category should not be on any such articles without references indicating veracity of this claim, and its defining-ness to the individual in question, at the very least.. - jc37 16:22, 9 May 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:42, 27 April 2021 (UTC)[reply]
Propose deleting:
Nominator's rationale: This appears to be some sort of attempt at something akin to the WikiProject assessment categories, but much cruder. It doesn't have the by-quality or by-importance ratings.
The India-related category dates from 2008, and the West Bengal cat is from 2016, but between them they contain only 14 pages. Whatever the idea was when they were created, they serve no useful purpose now that the articles are all categorised properly in other ways, so there is no need to merge. --BrownHairedGirl (talk) • (contribs) 06:52, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:2012 Vice presidential election

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete (non-admin closure) Marcocapelle (talk) 20:33, 26 April 2021 (UTC)[reply]
Nominator's rationale: This topic may be too small for a category —Naddruf (talk ~ contribs) 04:14, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Football and apartheid

[edit]

Relisted, see Wikipedia:Categories for discussion/Log/2021 May 1#Category:Football and apartheid

Category:Rashtra

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete (non-admin closure) Marcocapelle (talk) 20:37, 26 April 2021 (UTC)[reply]
Nominator's rationale: Does not make sense. No real connection between Maharashtra and Malla (Ancient India). —Naddruf (talk ~ contribs) 03:18, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Non-alumni attendees of Dartmouth College

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: merge (non-admin closure) Marcocapelle (talk) 20:40, 26 April 2021 (UTC)[reply]
Nominator's rationale: I think what is being indicated here is that the persons in the category attended Dartmouth College but were not awarded a degree from it. The definition of "alumnus" is usually "a former pupil or student", i.e., broad enough to include non-graduates, though an alternate definition can be "a graduate". Alumnus says, "An alumnus ... of a college, university, or other school is a former student who has either attended or graduated in some fashion from the institution". As far as I know, the many, many alumni categories WP has are not applied in a way that restricts them to those who were awarded a degree. (Another point of view, which would suggest deletion, is that if they weren't awarded a degree, perhaps this feature of their life is not even worth categorizing by.) I'm pretty sure this general issue has been discussed before, but I can't find it. Good Ol’factory (talk) 03:03, 16 April 2021 (UTC)[reply]
Support merger ao that this school is consistent with others. UnitedStatesian (talk) 17:05, 16 April 2021 (UTC)[reply]
  • Merge/Comment I actually don't think we should categorize people by schools they didn't get a degree from because it's not defining but that's a broader conversation. There's no reason to treat Dartmouth differently. - RevelationDirect (talk) 01:07, 18 April 2021 (UTC)[reply]
  • Merge per nom. Was "Non-alumni attendees" eventuelly meant to give sb. the dirt on sb. (denunciate as non-achiever or miser)? I really thought about that for a little while. --Just N. (talk) 12:30, 20 April 2021 (UTC)[reply]
  • Merge we use alumni for anyone who was a student at a location, regardless of whether they graduated or not. The one exception might be people who were present at a University or college or school in a non-degree program. Extremese might be my connection with Ohio University, where I was present for a week with Especially for Youth, a program of The Church of Jesus Christ of Latter-day Saints Church Educational System that was just renting space there. A slightly more possible connection might be some people who were students at BYU's Summer program to study the history of The Church of Jesus Christ of Latter-day Saints in the early 2000s. Would someone who that was their only time on BYU campus count as an alumni. I am actually willing to say yes, but if the answer is no I would say such people have so little connection with the institution that the connection is not categorizable by. We can also use alumni for current students, it is a little irregular, but it is not worth having current student categories because A-only a few current students will be notable and B-that would be a maintenance nightmare.John Pack Lambert (talk) 14:17, 22 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Harvard Business School alumni

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: Delete - jc37 18:21, 9 May 2021 (UTC)[reply]
Nominator's rationale: Is there any reason that these articles should not just be merged to the appropriate alumni category? We don't generally categorize alumni by specific programs within a school. Good Ol’factory (talk) 02:58, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Bandung Conference attendees

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: Delete - jc37 18:25, 9 May 2021 (UTC)[reply]
Nominator's rationale: Having attended the Bandung Conference is not defining for these politicians. Politicians attend many conferences during their tenures, and we generally do not categorize politicians by this feature of their positions. Good Ol’factory (talk) 02:56, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Federal and provincial leaders of the Opposition (Canada)

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: merge to Category:Opposition leaders in Canada. ✗plicit 08:25, 29 May 2021 (UTC)[reply]
Nominator's rationale: Completely overlapping scopes. The target category is more inclusive as there are also territorial opposition leaders in Canada, and we have an article for one that is included in the "federal and provincial" category. Good Ol’factory (talk) 02:45, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Wikipedians in the Cleanup Taskforce

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:40, 27 April 2021 (UTC)[reply]
Nominator's rationale: Wikipedia:Cleanup Taskforce is marked as {{historical}} * Pppery * it has begun... 02:28, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Article Improvement Drive categories

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:39, 27 April 2021 (UTC)[reply]

Nominator's rationale: Wikipedia:Article Collaboration and Improvement Drive is marked as {{historical}} * Pppery * it has begun... 02:23, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:XBIZ Awards

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:38, 27 April 2021 (UTC)[reply]
Nominator's rationale: WP:SMALLCAT and the spirit of WP:C2F, a category with one eponymous article
The XBIZ Awards honor people in the American pornograhic film industry. In a prior CFD nomination, we deleted the Category:XBIZ Award winners subcategory and this a follow up nom. All that was left behind in this category was the main article and Category:XBIZ Awards templates, which is already well categorized. I don't seem much growth potential here but, if I'm wrong and there are ever 5+ direct articles, no objection to recreating later. - RevelationDirect (talk) 00:18, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Wason Medalists

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete. Good Ol’factory (talk) 02:37, 27 April 2021 (UTC)[reply]
Nominator's rationale: WP:NONDEFINING (WP:OCAWARD)
We don't have a main article on the Wason Medal but it's an engineering research award from the American Concrete Institute (ACI). The articles for recipients don't treat it as defining and generally mention the award in passing like with W. Gene Corley, Fazlur Rahman Khan, and Nathan M. Newmark. (The only 1 of the 7 articles to mention it in the lede is Abraham Burton Cohen.) All the category contents are now listified right here in the ACI article for any reader interested in the topic. - RevelationDirect (talk) 00:18, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.

Category:Songs written by Bradley Cooper

[edit]
The following is an archived discussion concerning one or more categories. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was: delete (non-admin closure) Marcocapelle (talk) 20:45, 26 April 2021 (UTC)[reply]
Nominator's rationale: Only one entry which is a redirect. No navigational help. Richhoncho (talk) 00:13, 16 April 2021 (UTC)[reply]
The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the category's talk page or in a deletion review). No further edits should be made to this section.
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Categories_for_discussion/Log/2021_April_16&oldid=1028279846"