Wikipedia

Wikipedia:Bots/Requests for approval/Theo's Little Bot 25

< Wikipedia:Bots‎ | Requests for approval
The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was Denied.

Theo's Little Bot 25 edit

Operator: Theopolisme (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 17:03, Friday August 2, 2013 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python

Source code available: on github

Function overview: Theo's Little Bot 24 (convert templates to use {{start date}}), but for all templates listed at User:Pigsonthewing/to-do#Date conversions

Links to relevant discussions (where appropriate): successful request for comment

Edit period(s): I'll start the run for each specific template manually

Estimated number of pages affected: Lots

Exclusion compliant (Yes/No): No

Already has a bot flag (Yes/No): Yes

Function details: For all pages that transclude a given template:

  • if a specific date parameter is present and actually contains a date:
    • parses the date into a datetime object using the dateutil Python module
      • prints this date out into {{start date}}, with df parameter == y if the original format was DD Month YYYY
      • updates the specific date parameter to be equal to the start date template with an html comment saying it was bot generated
  • if the bot was unable to parse, adds the page to hidden category Category:Infoboxes needing manual conversion to use start date

I think this request is applicable for speedy approval, since BRFA #24 was effectively a trial, but I'm happy to do another trial if you'd like.

Discussion edit

  • Support as requester. I'll work with Theo to make sure that only applicable templates/instances are are updated and to handle any edge-cases or issues arising. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 2 August 2013 (UTC)[reply]
  • Since we're dealing with thousands of pages now, I think we need to watch for certain edge cases the previous trial missed. We've seen the bot handle YYYY, Month YYYY, Month DD, YYYY, and DD Month YYYY, but not things like YYYY-MM-DD or the more ambiguous MM-DD-YY, DD-MM-YY, DD/MM/YY, etc. Even if you parse them correctly, the usage of {{start date}} will change the appearance of the page, although that's probably fine. Additionally, there's the matter of times being included, which is acceptable in {{start date}}, and that brings additional challenges for the parser, since I don't think you're handling them. Finally, you should consider the limitation the template mentions with out-of-range dates. Maybe some marker or category should be added in cases where the date is parsable but too old to use the template? — Earwig talk 01:34, 3 August 2013 (UTC)[reply]
    • Anything outside the YYYY, Month YYYY, Month DD, YYYY, and DD Month YYYY pattern is not changed, but added to a tracking category, so we can see what actually exists and determine now best to proceed (leave it, change manually, or update the bot). This would apply to the edge cases you mention. We'll start with templates that have no instances where the Julian calendar issue might apply (movies, spaceflight, etc. - see the separate lists on the to-do page) and address that later. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 3 August 2013 (UTC)[reply]
      • I've talked with Earwig about this on IRC; firstly, yes, ambiguous dates will now be properly ignored. Andy, I'd actually like to write the code for parsing times, since it's fairly trivial, and some infoboxes may very well include it (and why force humans to parse it if the computer can?). Same with the Julian calendar issue; it's just a matter of writing some constraints. I think it's better to spend a few hours up front than to have to continually update the script later. Theopolisme (talk) 14:54, 3 August 2013 (UTC)[reply]
        • No problem if you want to include the Julian exclusions from the outset. I think the visual display of times in {{Start date}} isn't as good as it could be and may cause complaints. I think it would be better to address that later, though we certainly should. I've started a discussion at Template talk:Start date#Time display. Meanwhile ether are plenty of infoboxes needing this change, where no time component is likely to occur. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:13, 3 August 2013 (UTC)[reply]
          • I've added the range-checking functionality. Andy, as far as timezones go (yes, timezones :p), how should they be parsed? Python has notoriously bad handling of timezones (in fact, it was nonexistent until very recently), and so I'm rather doubtful that we'll be able to parse them with a high accuracy rate...it might be better to just tag all times that don't use GMT for manual conversion. Would that be okay? Theopolisme (talk) 15:50, 4 August 2013 (UTC)[reply]
  • Time/timezone handling (and appropriate tagging) is done, for the record. Waiting on the below discussion, though. Theopolisme (talk) 22:18, 9 August 2013 (UTC)[reply]

Subsection edit

  • I am aware of Andys penchant for metadata, and I am slightly concerned that this request seems to be an invitation to insert the {{start}} {{start date}} template all over the 'pedia to collect metadata the purpose of which is unclear, and to burden Wikipedia's servers with parsing and compiling tens of such templates in hundreds of thousands of articles. I'd like to enquire as to what is meant by "a specific date parameter", and what infoboxes the bot will target for insertion. In particular, I'd like to know what expected benefit there will be to our readers? The list of infoboxes seems to be quite extensive – is this list "locked" or would Andy or the operator be able to add to the list at will? Dates that currently populate these fields in these infoboxes don't need much parsing for humans. And if the dates that populate the |date= fields comply with WP:MOSNUM, they can equally be parsed easily by machine. Also it's the multiple insertions or the single insertion into multiple templates in any given article that concern me above all – this example gives me the willies.

    I'd also like to enquire if this bot will respect WP:TIES and also instances of {{use dmy dates}} within articles acted upon? -- Ohc ¡digame!¿que pasa? 04:36, 6 August 2013 (UTC)[reply]

    • Please note that this request page links to the RfC which both answered many of these points and showed near-unanimous support for the proposed edits. The {{start}} template is not involved; the template is {{Start date}} (and the number of transclusions has risen, since the RfC, to 125,577) WP:TIES is respected, as noted in both the RfC, and above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:42, 6 August 2013 (UTC)[reply]
      • Yes, I'm sorry I meant {{start date}}. Three things:

        General undesirability of "inconsequential edits": I note that the RfC, from just over a year ago, noted as regards dates that "No visible changes will be made to any article". This would surely make the edit "inconsequential" in AWB and bot terms, and thus generally accepted as being undesirable – it will lead to editors complaining of hundreds of changes that light up their watchlists for no apparent benefit. I'm surprised that nobody has brought that up before. Also, the absence of visible changes does not imply that WP:TIES will be respected. It just means the bot will not change a mdy date into a dmy date. I don't think there is any question that a yyyy-mm-dd date should be left as it is and not converted into the prevailing style. It would be infinitely more helpful if UK, Ireland, Australia articles should be given "start dates" in dmy format for such articles. At least that will mollify some of the likely objections to apparently useless edits.

        Clarify benefit for readers and editors: No examples of such potential use of such metadata was ever requested nor given. Of course you don't want to re-open the discussion because there was never any consensus for embracing microformats, and drawing attention to that may jeopardise your "successful RfC" Bot Requests, but you have still not justified the real reason behind your drive to extract metadata other than saying it needed to be "machine readable" by Google and Yahoo. Where the dates in WP follow WP:MOSNUM, they must already be machine readable. I'm not aware of any request from Google or Yahoo to receive our metadata, although all the signs are that they are already able to do that without any effort on our part. Quite simply, just taking the given example, it should be clarified bow the many instances of {{start date}} template insertion in here are likely to be used? "No cogent reasons for not deploying" does not equate with reason for deploying when the benefits are unclear and the increased burden to our servers is obvious. WP is not the NSA. ;-)

        Respect for {{use dmy dates}}: Editors often insert infoboxes and place non-compliant date formats or formats that do not correspond to WP:TIES or the prevailing style as tagged. I think it's mostly because they are not aware of the required parameter. The least the bot operator can do is to ensure that the bot inserts "|df=yes" if it comes across an article that is so tagged. Failure to do so would cause a further flurry of edits to correct what could have been addressed in one edit alone.

        -- Ohc ¡digame!¿que pasa? 04:20, 7 August 2013 (UTC)[reply]

        • The people supporting the RfC clearly disagreed with your view as to the usefulness of the proposed edits. The fact that instances of {{Start date}} have risen so quickly since that RfC suggests that the wider community is also happy to use it. Merely complying with MOSNUM does not make dates part of the microformats emitted by the infoboxes involved. I'd be happy for the bot to take account of {{use dmy dates}} providing we can change that if there is opposition from the community. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:44, 7 August 2013 (UTC)[reply]
  • I'd like to enquire as to the rationale to this bot/bot job not being exclusion compliant? -- Ohc ¡digame!¿que pasa? 04:42, 7 August 2013 (UTC)[reply]
  • I've just seen this on OC's contribs page. Could we know exactly what the advantages are, and how these make the increased clutter worth it? Tony (talk) 08:18, 7 August 2013 (UTC)[reply]
  • I've just seen this on AM's contributions page. The proposal at the RfC stated:
  • "Wikipedia emits many thousands of hCalendar microformats, mostly though infoboxes (see Category:Templates generating hCalendars), making the dates and other details of events machine readable and reusable. We have done so since around 2007. WikiProject Microformats has more information. They are parsed, among others, by Yahoo! and Google. However, many of our hCalendar microformats do not include a valid date parameter, because the infobox does not use the  () sub-template."
And the closing admin's conclusions were:
  • "This has been open for over a month, and ample opportunity has been provided for interested parties to comment. It appears that the change is uncontroversial, in that it merely alters existing input so that it can be parsed by search engines (its stated purpose) and here is no objection to the task in principle, thus I find that there is consensus to implement this proposal."
Hopefully reading the Bot Request RfC in detail will make clear to Tony and Ohconfucius that their concerns have been debated and taken into consideration already. The fact that the visual appearance of a page is not to be altered by a specific edit does not mean that the edit is "inconsequential". I regularly add alt text to images and scope to table headers, neither of which alters the visual display, but they are by no means inconsequential edits as they improve the article for screen readers. Similarly, as stated in the RFC proposal, marking up dates to provide standard microformats is an increase in the functionality of the article by extending the standardised data it makes available to many third-party re-users which will include individual researchers as well as the giants like Google. The template used is very cheap in server time and imposes a negligible burden on servers when editing - and obviously no burden at all for readers since for them the page served is from a squid cache. Try previewing a page that transcludes {{start date}} with and without the template; the time taken to serve is on the last line of the resulting page source and you'll be hard-pushed to see any significant difference in the time taken. HTH --RexxS (talk) 15:59, 7 August 2013 (UTC)[reply]
I've inserted "[not to]", above. That seems to be what you meant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 7 August 2013 (UTC)[reply]
Yes - thank you for spotting that. I've replaced the [] with markup and affirm that intent in what I wrote. My brain sometimes runs ahead of my fingers. --RexxS (talk) 16:57, 7 August 2013 (UTC)[reply]

I've asked around some tech-savvy individuals, and it seems that I may be one of one of those who "doesn't get" the importance of a need to datafy Wikipedia. But let me say this: I'm not totally opposed to the gathering of metadata if there is a demonstrable benefit, although I can accept that I may not know the benefits if they stared me in the face. But there is no question that metadata gathering should be done for its own sake – it certainly must not be done to the detriment of editors. The real underlying problem of this "project" is that it appears that little has been learned since the RfC initiated by Xeno some three years ago that received participation from exactly 50 users, including many tech-savvy individuals and Pigs himself.

As we all know, Xeno is no tech ingénue and has been on the BAG for a number of years. During the earlier RfC, he noted, referring to one of many template created by Pigs, that we must avoid "unnecessarily complicating our templates and burdening editors with having to use things like {{duration}} for song lengths to provide metadata that few readers will ever access". Furthermore, the current proposal, largely crafted and defended by Pigs and his trusted ally, has learned nothing out of Orange Dog's concerns either, viz:

  1. As detailed here, the absence of user applications that make meaningful use of our microformats except with geo-coordinates.
  2. As also expressed by Tony, above, many Wikipedia articles are beyond the usable levels of complexity, both in terms of template code and generated HTML. If much of the metadata were removed, these pages would be far more usable, and templates more easy to maintain.
  3. Over-usage of metadata in all its forms – A concern that I raised above – actually makes the data less useful. In particular, multiple instances of {{Start date}}, for example, being used repeatedly on the same article, with no clear indication of what it means to be a "start" date, nor which start dates correspond to which end dates. This both increases the problems of #2, and renders all the metadata useless, as the semantics are no longer clear.
  4. In some cases (e.g. {{Duration}}), existing style, flexibility and guidelines must be violated in order to correctly emit microformats. Sacrificing what everyone sees for the benefit of what almost no-one will ever see is a clear mis-placement of priorities.

Then, there is Nihiltres, no opponent of microformats on Wikipedia, said "Wikipedia content is meant to be read by humans, not machines. The inclusion of a microformat should not compromise in any way the experience a human reader has, including special cases like the experience of blind users with JAWS."

Even at the time, Pigs has been dismissive of the concerns, labelling most of them as "Unsubstantiated assertions". It seems that if metadata templates are coded in this way, the compromised ability of the reader to parse lies with the reader and not the chosen metadata format – any user that finds these confusing needs to "go to the project page", which is the equivalent of saying "fuck off, you ignoramus"; it's asserting the importance of technology over usability. Today, absolutely nothing has changed with this proposal, the response is equally dismissive, drawing only attention to the "successful RfC" of a year ago and supported by seven individuals, that glossed over or materially omitted many issues, including two major concerns raised during that RfC.

It seems like gathering metadata has become a means unto itself. Forget the dead bodies along the route. As the proverb goes, there's more than one way to skin a cat. Yet Andy Mabbet has gone to some length to push for "his way" of metadata gathering whilst possibly excluding all other possibilities, to the extent that one user has called for his site ban.

I'm not questioning the "successful" transclusion count for the template as such, but would point to Pigs, through the creation of his own version of walled garden (some 828 templates including documentation pages), and his incremental editing to gain acceptance for nesting 'start date' template into a large number of templates that have dates, and probably through his own direct efforts, accounts for the increased number of page transclusions. Again, I'm not question the desirability of the metadata gathering (as apparently confirmed by the RfC of last year), but how it's done. Yes, Smackbot was approved to do insert the 'start date' template in 2009, but it appears the operator later had misgivings about it and stopped working the implementation; Snotbot 6 got denied as being "too controversial", and the appeal wasn't any more favourable. In response to my query as to the benefits, one colleague confirmed my assertion that MOSNUM-compliant dates can be machine parsed. He said "with the advent of Lua, it should be perfectly feasible to emit this meta-data without 'cluttering the edit window'", and I would continue to insist that converting "12 September 2009" into {{start date|2009|9|12}} is completely counter-intuitive and unhelpful to the reader-editor, particularly as the template can seemingly parse {{start date|12 September 2009}} so the proposal must not go forward without suitable amendment.

Kindly note that, with the above responses from Pigs and Rexx, the "other people don't agree with you" approach is an insulting personalisation without addressing legitimate unaddressed concerns. I'm unimpressed at how previously-expressed concerns were not laid out during the May 2012 RfC emphasing the "successes" without mentioning the failures – that bot approvals failed, bringing into question whether it was achieved under less than full transparently. I'm sorry to disagree... it's quite a different thing to insert an alt comment manually to an image insertion (that will not appear on the face of an article but will reveal itself with a mouseover) than doing anything inconsequential to tens of thousands of articles by automated or semi-automated means. The alt tagging enhances accessibility. OTOH, this job is by definition inconsequential. As to the "cheapness" of processing time for the template, one colleague mentioned above said "I also have a suspicion that we should be going down a completely different path where the meta data is emitted selectively - either through an API call or through a sub page. The overhead of all the cruft on WP pages is considerable, even if the individual parts are relatively innocuous."

So in conclusion, I'm not asking for the project or the job to be withdrawn, but that it be re-written in light of previously and currently expressed concerns and of technological evolution. I sense that there is little "buy-in". We need a pragmatic and practical approach that can adhere and inspire. And for that to happen, some serious learning needs to occur prior to large-scale implementation by bot. There also needs to be clearer definition of the job requirement and the roadmap. -- Ohc ¡digame!¿que pasa? 04:39, 9 August 2013 (UTC)[reply]

Some additional points I should mention is that the site as well as the state of Metawiki is evolving, and the success of an RfC over a year ago should not nullify concerns against another RfC a year later. Two great changes have been introduced since May 2012 that could cause the whole approach to be re-evaluated: the introduction of Lua and the release of VisualEditor. While Lua offers many potential functional improvements, the developers have identified template support as "the single most complex thing" in the way of the development of VE. It implies that perhaps we, as part of the global wiki that will use the function, should be looking to maximising the advantages of Lua whilst at the same time look to limiting use of templates in general. The proliferation proposed here potentially runs counter to the ease of its development. -- Ohc ¡digame!¿que pasa? 09:36, 9 August 2013 (UTC)[reply]

Talk about filibustering...

My name is not "Pigs".

The claim that there are no applications that make meaningful use of our microformats except with geo-coordinates is utterly bogus. There are a number of in-browser tools (including the Operator plug in for Firefox and Microformats for Google Chrome) and websites (e.g. [1], [2]), many more) which do so. Among other things, they allow the extraction of microformat-marked-up data as XML or JSON. Why are you making pronouncements on the validity of this request if you do not understand such things?

There is no "Over-usage of metadata ". Each instance of  () will be contained in a parent hCard or hCalendar microformat which defines the former's scope. This is documented both in our articles and our help / project pages. Why are you making pronouncements on the validity of this request if you do not understand such things?

This request is not about {{Duration}}.

This bot recently had a trial run. How many of its edits were reverted, or complained about, or were otherwise controversial?

This request does not affect the readability of Wikipedia content by humans, because ("use DMY/MDY" compliance as requested by others aside) it makes no visual changes. there is no "compromised ability of the reader to parse". This allies equally to the experience of blind users with JAWS. Why are you making pronouncements on the validity of this request if you do not understand such things?

You seem to think one user calling for my site ban nullifies my arguments, I hereby call for you to be banned from Wikipedia. There, now we're equal.

Your "walled garden" assertion is utterly fatuous. This is a wiki, anyone can edit, and all microformat related template code is well documented. Your gratuitous link to WP:OWN is unsubstantiated by any evidence, and is irrelevant.

The fact that Snotbot 6 "got denied" led to the RfC which supported these changes. that RfC included links to prior discussions, not least SmackBot XV and Snotbot 6 Requests for approval, plus BOTREQ archives. Your insinuation of a lack of full transparently is bogus.

You advance no argument as to why Lua should prohibit the execution of the proposed changes. The coming of the Visual Editor will render baseless any arguments about the supposed complexity of wikicode, as it will handle data entry for templates. There is no suggestion whatsoever that VE requires us to "limit use of templates in general[citation needed]".

There is no need for this job to be "re-written" (re-written how is not specified); it does exactly what is needed to complete the microformats already applied to hundreds of templates, with wide community support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 9 August 2013 (UTC)[reply]

No response. May we now proceed with this important, useful; and RfC-approved task? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 19 August 2013 (UTC)[reply]

Not so fast.

This will be my final response and I will keep this response short as I can.

  1. Pigsonthewing – rather an unfortunate username if you expect never to be referred to simply as "Pigs". I would apologise if any offence was caused.
  2. Unlike some others, I never claimed to know everything there is to know about metadata or how we can achieve the goals, which is why I did ask around for other opinions as well as as here for clarification. The comments I received and the rather forthright and generally dismissive response I got from Andy seemed to confirm my suspicious that "Andy's way" isn't the only or the best way.
  3. I believe it was unwise of Andy to imply that only experts should comment and that layman's opinions were not welcome.
  4. In dismissing my opposition, Andy said that ('use DMY/MDY' compliance as requested by others aside) makes no visual changes, so there is no 'compromised ability of the reader to parse. This would be true if humans only read and parse in 'read' mode and only machines edit and parse in 'edit' mode. But the premise is false. As I said, the form "{{start date|2009|9|12}}" is completely counter-intuitive and unhelpful to the reader-editor. Why do we have to have this when the template can seemingly parse "{{start date|12 September 2009}}"? Many editors already find it less than easy to parse than "2009-09-12".
  5. When editors – newbie and experienced alike – open the edit window, they take fright from the increasing levels of screen clutter. We should not be adding unnecessarily to that edit-window clutter.
  6. The assortment of infoboxes, templates, documentation, and other self-reinforcing arguments used to spread metadata collection here on WP make up the "walled garden".
  7. I don't think Andy Mabbett will deny that using the {{start date}} template and various infoboxes is an integral part of his scheme to gather metadata. But I totally reject why in this day and age, and with Lua, that the infobox itself (via one of its parameters) cannot be used directly to deliver/extract the metadata, and why a consequential increase in edit-window clutter is the only way to proceed.
  8. I'm sorry, but I'm not prepared to accept as gospel that the 'start date' template is the only way" to achieve the metadata gathering. The fact that there are already thousands of transclusions of such a potentially redundant template seems only to be relevant to the extent of the numbers of these templates that could potentially be removed if we worked smarter. Just because {{start date}} is "cheap" in terms of processing and compilation doesn't mean we shouldn't pursue even cheaper methods.

Andy's determination is admirable: he has invested massively in metadata extraction for years, and it now seems to be his entire raison d'être. His blind orthodoxy concerns me hugely, His pushy behaviour concerns me even more.

In insisting on imposing infoboxes to further his attempts to gather metadata in 2007, it was found that Andy was acting in contempt of "the Wikipedia way of doing things". Andy now seem to be repeating this campaign to force infoboxes on classical composers' articles against heavy opposition suggests that a)the wider metadata project is not without opposition, contrary to Andy's implied assertion using a deliberately narrow scope and b)not a lot has changed in terms of Andy's behaviour to achieve his goals since he was blocked for 12 months by Arbcom. Now he's pushing to automatically make inconsequential edits to tens of thousands of articles to put in templates of questionable necessity. Therefore, the questions surrounding this bot job lies as much with the controversial nature of the task at hand as Andy Mabbet's own behaviour as a project overlord.

I would therefore conclude by reiterating my strong opposition to the form of this proposal. At best, it should be stayed until at least the end of the currently-open Arbcom case centred on Andy Mabbett. -- Ohc ¡digame!¿que pasa? 22:35, 19 August 2013 (UTC)[reply]

My opposition to this has always been on a technical level -- the addition of user-unfriendly templates with user-unfriendly parameters. We have Lua now, so why cannot this be done that way with 0 extra clutter for infoboxes (except for some exceptions)? VE does not obsolete markup editor. And VE presents no user-friendly option to edit these templates, in fact it makes it harder. And I hardly expect MW devs to focus on these specific English WP metadata issues any time soon. —  HELLKNOWZ  ▎TALK 21:54, 25 August 2013 (UTC)[reply]

Because without an AI-level natural language parser, lua can't determine whether the words people insist on placing in these parameters, before or after a date like ("circa" or "in Germany" or "around " or "on DVD" or "not before" or "launched" or a myriad others) qualify the date or not. As noted, we've had an RfC on this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 25 August 2013 (UTC)[reply]
RfC was before Lua. As per editors placing those comments, how is current request dealing with them then (since they require NLP AI)? —  HELLKNOWZ  ▎TALK 22:14, 25 August 2013 (UTC)[reply]
This request deals only with articles with no such text, leaving it to human editors to apply the template selectively and manually (as already done) where text is present. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:19, 25 August 2013 (UTC)[reply]
So why can't Lua just skip everything with extra text and deal with these articles all at once? We can then work out how to deal with the rest (for now, with {{start date}} and family)? —  HELLKNOWZ  ▎TALK 22:23, 25 August 2013 (UTC)[reply]

I don't want to argue further on my opinion alone and BAG shouldn't take this as me opposing the task against previous consensus, but I do think Category:Articles with automatically detected infobox date metadata is a viable alternative with potentially 85%+ articles out of the box needing no further edits to output customizable metadata. —  HELLKNOWZ  ▎TALK 09:18, 4 October 2013 (UTC)[reply]

Not a viable alternative, as I explained in my comment dated '22:07, 25 August 2013'. How many more times? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:19, 12 March 2014 (UTC)[reply]

Redux edit

Despite his best efforts, Hellknowz has not come up with a viable alternative to {{Start date}}, and neither has Ohconfucius. May we now proceed with this task, which has already been approved at RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:05, 4 October 2013 (UTC)[reply]

WP:NPA
  • Well, let's see... the Arbcom case involving POTW found the following:

    "3) Pigsonthewing (talk · contribs · deleted contribs · logs · edit filter log · block user · block log) (also known as Andy Mabbett) has had a long history of editing articles with the focus on adding or modifying infoboxes, and has been previously banned from editing the day's feature article (TFA) 30 as well as sanctioned in Arbitration cases; he was banned for one year in 2006 by amendment to Wikipedia:Requests for arbitration/Pigsonthewing and for an additional year in 2007 in Wikipedia:Requests for arbitration/Pigsonthewing 2."

    and

    "4) Pigsonthewing's contributions to discussions about the inclusion of infoboxes are generally unhelpful and tend to inflame the situation.313233 He also selectively chooses what discussions he considers consensus34".

    Remedy concerning him stated:

    "1.1) Pigsonthewing is indefinitely banned from adding, or discussing the addition or removal of, infoboxes."

    Make of that what you will. POTW will tell you that these have nothing to do with metadata-collecting templates, but take note that technically an infobox is a specialised template, and the underlying thrust of infoboxes insertion is also primarily to collect metadata. Closer, choose between User:Hellknowz and I know nothing and simply "don't like it", or Andy Mabbett "didn't hear that". -- Ohc ¡digame!¿que pasa? 11:34, 4 October 2013 (UTC)[reply]
None of this is germane to the discussion and both views constitute personal attacks that will only distract everyone from solving the actual problem. A solution will only be found if everyone stops dragging personalities into it - BOTH personalities - and starts looking at the actual technical merits of each position, preferably by people who don't give a flying f--- about the personality issues AND who actually know what they are talking about. As I am not one of the people who understands markup language very well, that person is not me. But I know when a discussion is about to be hijacked by irrelevant issues, and this is one of those situations. Montanabw(talk) 16:36, 4 October 2013 (UTC)[reply]

Given the collapse of this conversation, I'm planning on closing this as denied. With the advent of Lua, I view that this change will be unnecessarily disruptive and decreases the human readability of the wikitext. Josh Parris 10:10, 5 November 2013 (UTC)[reply]

Per my stated intention and failing any objections, Denied. Josh Parris 05:37, 9 November 2013 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.
Discussion following after out-of-process re-opening
The following discussion has been closed. Please do not modify it.
With respect, I've reopened it. I wasn't informed, nor even aware, of your proposal to close it, made last November, or otherwise would have objected, not least as an RfC has already approved this task. The discussion was derailled by the irrelevant section which I have now collapsed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:16, 12 March 2014 (UTC)[reply]
Josh Parris is a member of the Bot Approvals Group and he has denied this request. You should not have re-opened it. –xenotalk 21:33, 12 March 2014 (UTC)[reply]
And the policy stating that BAG outranks community RfC is..? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:07, 13 March 2014 (UTC)[reply]
You mean that lightly trafficked RFC from two years ago? See Wikipedia:Bot policy#Approval process. Please revert your out-of-process re-opening of this request; and seek the advice of User:Josh Parris on how you might proceed. –xenotalk 19:17, 13 March 2014 (UTC)[reply]
That's a long winded way of saying there is none. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:19, 13 March 2014 (UTC)[reply]
There is long established consensus that the Bot Approvals Group is the body that oversees bot approvals and may decline "a request which fails to demonstrate community consensus to perform the task". Josh has determined that this task has not adequately demonstrated community consensus and has declined the request. You should not have unilaterally re-open the request. Please re-close it and seek the advice of User:Josh Parris as to how you may proceed. –xenotalk 19:25, 13 March 2014 (UTC)[reply]
So no policy, then. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:46, 13 March 2014 (UTC)[reply]
It's a well-known policy known as the bot policy. Please stop selectively choosing which discussions you consider consensus and revert your disruptive and out-of-process re-opening of this request. –xenotalk 19:48, 13 March 2014 (UTC)[reply]

I asked you for "the policy stating that BAG outranks community RfC". Where does the Bot policy do that? And further to your earlier comment, Josh ignored the view of the independent admin who judged that the RfC did have community consensus and unilaterally made a bogus assertion that "this change will be unnecessarily disruptive". It was the closure contrary to the rfc that was out-of-process. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:52, 13 March 2014 (UTC)[reply]

Josh presumably reviewed the lightly-trafficked RFC from two years ago along with the newer discussion here and determined that this bot request did not have sufficient community consensus to approve it. If you wish to appeal Josh's decision, you could try contacting another member of the Bot Appeals Group, but you should not unilaterally re-open the request without his consent, this is disruptive. –xenotalk 19:55, 13 March 2014 (UTC)[reply]
I have no need to appeal his out-of-process closure; an admin already (contrary to your personal attack, above) judged that the RfC had consensus; you have failed to provide a policy allowing BAG to override that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 13 March 2014 (UTC)[reply]
Wikipedia:Bot policy. Your lightly-trafficked RFC from two years ago does not create an end-run around it. What personal attack? –xenotalk 20:31, 13 March 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Requests_for_approval/Theo%27s_Little_Bot_25&oldid=1144427083"