Wikipedia:Village pump (proposals)/Archive 79

WikiPedia for goodness of our nature
Why not post a wikipage that all topics related for the goodness of our nature will be there. So people could be exposed what are the bad effects that could kill our home planet. With this simple message hope you find the idea what I want to say.. Thanks guys and More power to your team — Preceding unsigned comment added by 202.57.35.170 (talk • contribs) 09:51, 14 October 2011‎ (UTC)
 * That might fall afoul of Wikipedia is not here to tell the world about your noble cause, but we do have articles on environmentalism and related topics. Dcoetzee 10:08, 14 October 2011 (UTC)
 * Maybe you're looking for Portal:Environment?  S ven M anguard   Wha?  11:51, 15 October 2011 (UTC)

We have to remember that Wikipedia is not a soap box, much as you might have some noble cause you wish to tell the world (see  What Wikipedia is not), but as has been pointed out above, we do have an article on environmentalism. If you feel strongly that Wikipedia needs more of this type of article, why not set up a WikiProject on environmentalism if there is not one already? ACEOREVIVED (talk) 15:08, 20 October 2011 (UTC)

There is actually WikiProject Environment. ACEOREVIVED (talk) 15:21, 20 October 2011 (UTC)

WikiKids - Vikidia: encyclopedia for children
Hi all,

I've just checked some of the old messages about this topic, which has been put in light time to time, most recently there: here and there (with the response "We do have the Simple English Wikipedia.")

I am a French wikipedian, and would like to tell you about this pretty old project: a wiki encyclopedia designed and partly maintained by children.

The idea of a equivalent of Wikipedia for children was discussed in particular in 2005-2006 on this page : Wikikids

Although it had no continuation as a Wikimedia project, wikis with such a feature were launched first in Dutch: WikiKids; in french a few month later: Vikidia and then in Spanish (Vikidia in spanish) for 8-13 years old children. I opened Vikidia.

WikiKids and Vikidia in French are doing well and are quite alike in size and activity, whereas Vikidia in Spanish doesn't make it so well.

On Vikidia in French, we currently have a guest-book opened, and the comments left on it are quite encouraging (Google translation). Children say they appreciate the articles to be more readable for them than on Wikipedia, their main reserve being that some article are not developed enough, or that there isn't articles on every subject they would like to know about... They clearly expect (and claim) some substantial content, though it has to be easier than the wikipedia's content.

We have yet a bit more than 10,000 articles in Vikidia in French, and about 220,000 unique visitors a month.

This "Wikikids" question was mentioned again in the Wikimedia scope one year ago there: meta:2010 Wikimedia Study of Controversial Content: Part Two:

Recommendations: Controversial Text
Because of the considerations outlined above, our recommendations surrounding text in WMF projects are the following:

It is recommended:
(...)

3. That, however, the Foundation investigate the creation of a “WikiJunior” version of the Wikipedias, aimed at children under the age of 12, either as a stand-alone project or in partnership with existing and appropriate educational institutions.

Explanations:
(...)

(...) ''Much more successful, in our opinion, is a project specifically targeted to children, and to the quite different needs of children in different age groups. Some projects of this nature have already been begun in the WikiJunior section of WikiBooks, but it is our feeling that the scope of such a venture might necessitate the formation of partnerships with institutions who have experience and resources already devoted to this area.'' is all well and good but only if behaviour is a recognised term a script might want to use. If all of Category:Birds had semantic-behaviour as an expected type the embedded data would be easily used and thus (more) useful. I'm probably not using the right terms but hope my meaning is clear enough. If nothing else it gave me some typing practice. I guess in essence what I'm saying is that random collections of data are no more organized than human-readable pages so if this data is to be used by machines it would be best to get it as organised as possible before it spreads too far in a disorganised form. --  fg T C  05:26, 20 October 2011 (UTC)
 * Recommendations 2 and 3 
 * If I understand you (FG) correctly, it sounds like you are suggesting the development of an ontology of relationship types that would be used to standardize the use of the SWL template. I think this is a laudable goal that would indeed increase the value of the semantic links, the main question is how we achieve it.  It sounds like you are advocating a pro-active attempt at building this ontology and some kind of subsequent enforcement of its application.  (Correct me if I’m wrong!)  In my opinion the relationship types should emerge organically from their use in much the same way that articles do.  Someone boldly creates one, others disagree and make changes, and in most cases a stable consensus eventually emerges.  Also, in the worst-case scenario that you allude to - of prolific SWLs without consensus and consistency - I still feel that the data would be more useful for scripts than plain text.  If you look at Pleiotrope’s example, I would personally would prefer to use a different property than “behavior” to link the owl to “nocturnal”, yet the presence of this loose semantic link is still valuable.  The script extracted and displayed it correctly.  I got the basic idea and, because I saw it, I am substantially more likely to get in there and alter the SWL to something that makes more sense to me.  Benjamin Good (talk) 18:09, 20 October 2011 (UTC)
 * Yes "ontology" is a very good word. I would have used it if I'd known it. "Organic ontology" makes for an interesting Google search. It seems we are paddling along with the swell of a wave. Do we try to stand or let it roll beneath us? I grabbed a few links to share. I visited each and have seen nothing suggesting ill will at any of the addresses (I worry about viruses etc).
 * http://bricobase.com/organic.shtml
 * http://fractalontology.wordpress.com/category/parasite
 * http://www.duo.uio.no/sok/work.html?WORKID=58292&lang=en
 * If the semantic data were held in something akin to a JavaScript or JSON "object" we would have the basic set of rules steering the way for standardization with the freedom that our object is effectively unlimited. This concept would allow as a tree allows twigs that all semantic data would be born of a solid trunk (root would sound better but not so good for the analogy). Although we Humans are extraordinarily adaptable, machines/scripts are not (yet). Since the best use of semantic data is as machine read data we need to consider the needs of a script. It wants predictable structure. A JSON parser deals with any JSON object thrown at it because it follows specific rules. The object it reads could contain anything but it won't upset the script. There we have Organic (unlimited and adaptable) Ontology (formal, explicit specification of a shared conceptualisation). I think we should be bold. Take this bull by the horns and tame it. --  fg T C  22:08, 20 October 2011 (UTC)
 * So, just to make sure I've got your point here - you are saying that the ontology we are talking about can and should emerge and evolve organically as the examples you provide in the links enable, yes? Also, regarding the needs of scripts.  The SWL template does currently emit machine readable HTML and there are a couple prototype scripts that already process it.  It has a consistent, parseable structure (i.e. 'syntax').  The only challenge is clarifying the meaning or semantics of the relationship types it is used to encode.  Right now the relationship types are represented as categories (sub pages of the upper SWL category).  This is where the community can work to evolve a useful ontology of relationship types. Benjamin Good (talk) 22:50, 20 October 2011 (UTC)
 * Yup it's the style of the embedded data that I think needs to be standardized not the data itself. The JSON object example is a close to a practical example I can think of. Allowing author freedom while a script sees only order. That the script can read the template is not in question it's more what it will get from it. On page a of cat:a the script gets perfectly reasonable data and on page b of cat:a it also gets perfectly reasonable data. If it then tries to compose a table using the data from all pages in cat:a it runs into a fatal problem. The data types have no obvious correlation. As Humans we are used to interpreting what we find and filling in the gaps. We can edit and alter things as we see fit. Scripts can't (unless extremely complex and massive) and thus the perfectly reasonable data from all cat:a pages becomes almost valueless. If however all cat:a pages had a specified object structure a script could draw data from any page in that category and use it any way it was written to without hiccough. If the idea of categorical structure was carried outward to encompass all categories e.g. ((A(a)(b)(c))(B(a)(b)(c))(C(a)(b)(c))) we have a secure working environment for scripts across all categories but each cat can have it's own quirks and even each page. I think I may be explaining this badly. It is quite possible that I understand the subject so poorly that my opinion is pretty much worthless too Face-smile.svg. I am just thinking that while the chance exists it would be good to at least attempt to lay down some guides that make the templates both user-friendly and script-friendly with an eye on the forseeable future. Too much of our modern systems are reliant on old ideas so deeply embedded that we are trapped into their continued use. It seems there is great value in semantic data on the web and it would be nice if it was organized...My thinks are coming out upside-down. Owl:type=behaviour|target=nocturnal;Sparrow:type=color|target=brown;result=messed up table of unrelated/able data. More options and nested options. If we are gonna have a tool lets make damn sure it's as good as it can be so it doesn't snap and sharp bit stabby stabby! --  fg T C  23:37, 20 October 2011 (UTC)
 * OK, I think its important to separate authoring/viewing tools from representation here. I think it would be very  useful if we had a tool that would help editors author SWLs in a consistent way by suggesting relationship types to use as the semantic link is being created.  This is totally achievable given the current representation and I would be happy to help work on it.Benjamin Good (talk) 00:02, 21 October 2011 (UTC)
 * Now that is an extremely good idea! Face-smile.svg --  fg T C  00:00, 21 October 2011 (UTC)
 * I agree with Benjamin, the ontology should emerge from the community itself, suggestions in order to facilitate things to users should be provided as well. However, will this ontology be empty at the beginning? I think some common relations can be added at the beginning and then let it evolve. What about using relations coming from other ontologies? skos:broader and skos:narrower for instance? -- '''ljgarciac 17:43, 23 October 2011 (GMT)
 * There are several problems with this idea. First of all, the hard part is not creating a script that makes a "fake" infobox from some data. The hard part is coming up with a reasonable data structure. And in this case it hasn't been done. You have a pair "type=behavior|target=nocturnal". Now you are proposing "type=active_period|target=nocturnal", someone else will mark it as "type=is_nocturnal|target=yes", "type=is_nocturnal|target=1" etc. Also, someone will take something like a sentence in lead of article "Pony" "Ponies are generally considered intelligent and friendly, though sometimes they also are described as stubborn or cunning." and make pairs "type=behavior|target=intelligent", "type=behavior|target=friendly", "type=behavior|target=stubborn", "type=behavior|target=cunning". The result will be a complete mess - any program that can make sense of such data will probably make more sense of the article itself. Furthermore, that way we lose information: in the article the equivalents of "type=behavior|target=intelligent", "type=behavior|target=friendly" were qualified by "are generally considered", while "type=behavior|target=stubborn" and "type=behavior|target=cunning" - with "sometimes they also are described". We lose those qualifications in the "fake" infobox.
 * There is another problem concerning confusing syntax, but others have already explained it, thus I'll just add that almost every possible way to make this system more useful to computers will make the syntax even more confusing.
 * Thus I'll put it as harshly, as I can: nothing similar must ever be implemented in Wikipedia. Each Wikimedia project must do one thing and one thing only - but do it well. Wikipedia is meant to be an encyclopedia - and nothing else.
 * But while nothing like that can be allowed on Wikipedia, I don't see why we shouldn't create a different Wikimedia project, that would be dedicated to just that. "Wikiontology", perhaps, referring to Ontology (information science)..? So, go to m:Proposals for new projects and propose it! Yes, seriously. Looks like there are enough users who would like to work on such project. --Martynas Patasius (talk) 18:29, 20 October 2011 (UTC)
 * Dear Martynas, a quick note regarding your pony example, I assume that we would trust editors to use only add the template to links where it would make sense. Currently none of the words you highlight ("intelligent", "friendly", "stubborn", "cunning") have been wikilinked, so personally I don't think anyone would add the SWL template to them.  On the other hand, I could see someone clarifying the wikilink to "horse" using SWL (  .  That would allow a user to easily generate a list of animals that are types of horses, differentiating them from animals that eat horses and plants that are eaten by horses, for example.   Cheers, AndrewGNF (talk) 19:26, 20 October 2011 (UTC)


 * Er... So, someone who wants to put some fact into "fake infobox" must find a way to insert some internal link (using this template) into the article text? And that is supposed to be easier than the alternative..? --Martynas Patasius (talk) 20:00, 21 October 2011 (UTC)
 * Hi Martynas, I've addressed some of your concerns below. I would encourage you to give the userscript a try and see what happens when you actually write one of these templates. Pleiotrope (talk) 01:40, 22 October 2011 (UTC)

I'm a prolific writer and editor and I think this is a really, really bad idea. It's going to make it much more difficult for casual editors and experienced editors to edit. That's a lot of parsing to do in the edit screen. Then there's the issue of what you should put in this template. Some editors will add it to almost everything so that the article is full of little orange boxes. Some will spell behavior as "behaviour", making it harder for any script to parse data. We need to devise ways to make editing easier, and while this may make reporting easier (I'm not convinced), it will make editing more difficult. Karanacs (talk) 18:05, 20 October 2011 (UTC)
 * Agree with Karanacs, just above. I add that the concept is very - very! - interesting, but the implementation seems very, very bad. editing is already hard enough, we do not need to ad this. No good having some interesting tools, if there is not enough people to use them (properly) - Nabla (talk) 18:37, 20 October 2011 (UTC)
 * Hi Karanacs and Nabla, thanks for your input. You're absolutely right- this adds a degree of complexity to an already-difficult editing process. Our current implementation is very much a proof-of-concept, and we were hoping to get suggestions as to how to make it both unobtrusive and useful. One way is to alter the template- the fields and syntax are not set in stone by any means! I also would imagine that guidelines could be agreed on that established the use of these templates to avoid being disruptive. As precedent, the system adds large blocks of complicated markup into the article, but we as editors work with it because it's necessary and useful. While our template isn't on the same level of importance, it's also not nearly as complicated (and could be made much less so). Finally, I think there's a not-unreasonable tradeoff in short-term complexity for long-term benefit: while it does make the source more obtuse, imagine the benefits it could bring to even more tedious tasks like manual list maintenance and categorization. Would you be able to think of possible changes that would make this something you could use? Best, Pleiotrope (talk) 19:17, 20 October 2011 (UTC)
 * I think this concept works much better in a format such as the persondata template - we have a defined topic (biographies) with defined fields about which we'd like to have more information. This is then placed at the bottom of the page, so it does not clutter up the editing screen, and it can be used in scripts.   I don't see any good coming from a system that doesn't have a hard-and-fast definition of what types of keywords should be used. Karanacs (talk) 20:29, 20 October 2011 (UTC)
 * Agreed. Without a pre-defined ontology I can't see this being of any use at all. Malleus Fatuorum 20:45, 20 October 2011 (UTC)
 * I understand where you're both coming from, though I would posit that Wikipedia thrives because of the lack of hard-and-fast definitions around a lot of its content. Editors are currently already under the onus of making sure that, for example, articles they create don't already exist, and words they make wikilinks have articles backing them (or, if not, they're okay with having them be redlinks). In a hypothetical future Wikipedia where people use this template, I think there'd be the same type of practice around the template parameters. If an editor makes a template that uses some arbitrary relationship, it's easy enough to change it to whatever may be already established. If an editor was to add them everywhere, another editor could remove the ones that would be inappropriate (as per the bold, revert, discuss policy). Additionally, if the use of this template becomes fairly common, there's nothing preventing the establishment of a preferred ontology, especially within specific WikiProjects. This, like most other parts of Wikipedia, would be a matter of consensus, don't you think? --Pleiotrope (talk) 21:11, 20 October 2011 (UTC)
 * I'm not a great fan of consensus in areas such as this (and many others as it happens, but that's another story). Karanacs example of PERSONDATA is a good one. Malleus Fatuorum 21:15, 20 October 2011 (UTC)
 * Would you care to elaborate on why you are opposed to enabling consensus formation on this issue and how this is different from, for example, creating and applying categories or naming articles in the existing system? Benjamin Good (talk) 21:31, 20 October 2011 (UTC)
 * Because metadata is useless unless its meaning is defined. (We already have guidelines for naming articles, and categories are just a useless distraction that few bother about anyway.) What's the point of embedding metadata if every editor is inventing their own flavour? It's like everybody inventing their own language. Malleus Fatuorum 21:50, 20 October 2011 (UTC)
 * As long as it is created in good faith, individually-authored metadata can be used to enhance single articles as shown in Pleiotrope's example. As you suggest, when making use of metadata across many articles, for example to compose a list based on a query (e.g., nocturnal animals in north america), it is important that standard forms are used consistently across articles.  There are many ways to approach the creation of a standard.  One is for some power to dictate the standard.  Another is to let it emerge organically (see above discussion with user FG).  Within Wikipedia I think the latter makes the most sense.  Benjamin Good (talk) 23:12, 20 October 2011 (UTC)
 * Good faith has nothing to do with anything in this context, except for leading to the construction of a pointless Tower of Babel. Malleus Fatuorum 23:53, 20 October 2011 (UTC)
 * I think its also important to keep in mind that this is in no way intended to be a replacement for infoboxes like persondata. When there is an established desire for a particular set of attributes to be displayed on a large number of pages, an infobox template is an excellent mechanism and could replace the corresponding SWLs on relevant articles. Benjamin Good (talk) 21:45, 20 October 2011 (UTC)
 * Pleiotrope, adding more specialised templates is bad, the current situation is already way overboard, I think, and editing the wiki is already very much un-wiki (not fast, not friendly, not 'for all'), much because of the proliferation of specialised templates, de facto enlarging the wiki-markup to thousands(?) of keywords. If ever, this would better be kept out of the main text - like the already mentioned persondata (it does not look that great too, but at least a casual editor may ignore easily) or categories (aren't categories somewhat similar? how about ideas to improve - eventually replace - categories instead of adding a feature?) - Nabla (talk) 22:01, 20 October 2011 (UTC)

Nabla, I'm not sure I agree that adding more templates is bad. Templates are an accepted method of controlling the complexity of Wikipedia articles. I have seen new templates be created and used on pages without ill effect- I hypothesize that inexperienced editors simply ignore them.

One thing that I want to point out is that we've been discussing mostly predictions: that these templates will be useless without an established ontology, that they will add too much clutter to source text and discourage editors. While your (and Malleus', and Karanacs') reservations are totally valid, don't you think we should actually test our respective predictions? It's perfectly possible that these concerns won't come to pass. If this works, we've started building a valuable tool to categorize and annotate the huge amount of information we've created here. If it doesn't, the templates are gradually removed and no harm is done. This encyclopedia is not made out of delicate parchment, we can and should innovate and experiment.

Would you all be totally opposed to a small, limited test of these templates on a selected group of pages? We could then actually get some data for our predictions by seeing how they're received on live articles by editors. --Pleiotrope (talk) 23:46, 20 October 2011 (UTC)


 * Without an established ontology it's more of a foregone conclusion than a prediction. Malleus Fatuorum 23:56, 20 October 2011 (UTC)
 * Yes, I'm opposed to a small, limited test of these templates. There's no consensus that these would be useful and no methods to neutralize any of the concerns.  I'm a computer programmer; a good portion of my job is enabling people to enter and report on data.  The number one lesson that I teach all of my new employees is that one of the most important requirements to define for any project is "what type of reporting will be necessary?"  Without specifics on that, whatever you design will ultimately fail, because if the planning doesn't take place up front it will end up being impossible to get the reports you want.  If we don't know up front the type of metadata that we want to collect, then how on earth can the metadata be useful?  If we don't know what it is being used for, why would we want to put it in an article?  If we don't know whether it is useful to anyone, why clutter the editing screen and make editing harder than it already is?  There must be a way to measure effectiveness for something like this, and I don't see one yet. Karanacs (talk) 14:40, 21 October 2011 (UTC)
 * How would you measure the effectiveness of hyperlinks? Benjamin Good (talk) 17:10, 21 October 2011 (UTC)
 * I don't see any clear purpose to these templates. We've had PERSONDATA for years; does any program actually use that data? I don't think I've ever noticed it being used anywhere. Does any program use the geo coordinate data on location articles? The idea of a generic metadata class to be used anywhere without a clear schedule is destined to fail (and to deter a lot of editors along the way). I'd rather start with specific examples of use cases before starting any "limited test". Otherwise we have no idea what's being tested. The pony case seems worthless to me, for example. What does it mean that a certain relationship is behavior-based? What kind of a program would "mine" that information? How would it be better than just having a database of animal characteristics on some other site, rather than mixing it with natural language? And as others pointed out, you're losing all kinds of qualifiers. Presumably people would add these tags en masse with little regard for subtlety. Bad information is worse than no information. The other example was that one article is the capital of a different article; wouldn't both articles already link to each other in the infobox for that reason? And, again, wouldn't someone looking for this information turn to public databases rather than English-language articles? —Designate (talk) 20:15, 21 October 2011 (UTC)
 * Hi Designate, yeah, there are actually a number of really useful tools that use metadata in Wikipedia- check out [//freebase.com freebase.com] and [//dbpedia.org dbpedia.org]. But these are limited in their parsing because they are limited to preexisting structured content. For context, I can attest that the use of this generic metadata creates "noisy", not bad, information. Noisy information can be filtered and cleaned easily. As far as the use cases for these template, I was attempting to show how an editor could create a rapid summary of the useful information in the article, which could then be used to categorize the pages, provide candidates for additional fields in the article's infobox, or simply highlight key points at minimum. My example may not have been the best, but if you use your imagination, you can imagine better ones. I've addressed the issue of people adding these templates en masse above; my point was that people should show the same restraint as they do in any other task on WP and appropriate "tagging" policies could be agreed upon. In regards to an often-brought-up point that it would deter casual editors, I haven't seen any evidence of this and think that may be an unfair implication of casual editor's intelligences. Pleiotrope (talk) 01:40, 22 October 2011 (UTC)


 * Re: Karanacs: Hello fellow programmer! I'm currently working in bioinformatics as a research programmer, and I agree that project planning is very important. However, I would point out that nobody was planning the structure or organization of Wikipedia when it began, but it organically developed tremendous amounts of organization and information regardless, and people are able to use it today (both casual readers and groups like the links I posted above). The same idea is behind our resistance to pre-defining an ontology: we could never design one that could be as appropriate as one that grew naturally through trial and consensus. Pleiotrope (talk) 01:40, 22 October 2011 (UTC)


 * Do we really need a test to find out if " " is going to be more confusing than " nocturnal "..?
 * And the problem with "I would posit that Wikipedia thrives because of the lack of hard-and-fast definitions around a lot of its content" is that in this case we do not get an equivalent of Wikipedia - we get an equivalent of Wikipedia with no policies, no guidelines, no essays and no talk pages. And we know it wouldn't work like that.
 * For example, what if I want to find out what "type=behavior" is supposed to mean? How would I find some documentation? How would that documentation look like? That is what you have to show, and not just a fun toy that does what we can already do in another way (that might also be easier).
 * Also, I'd like to repeat my proposal to stop trying to implement semantic links (and the like) in Wikipedia and to start a sister project dedicated just for that. Then, for example, you might be able to make a namespace for those "types", implement redirects (for example, between "behaviour" and "behavior"), add documentation there, make "articles" that consist only of that "link metadata" (reducing the confusion)... Wouldn't that be a much better option for everyone? --Martynas Patasius (talk) 20:55, 21 October 2011 (UTC)
 * There have been many attempts to build other projects outside of Wikipedia with the goal of creating open, structured knowledge bases. See for example, Freebase.  The trouble with all such examples so far is that none of them have managed to come even vaguely close to the level of editing activity that Wikipedia has.  It is worth attempting to bring this kind of functionality (some level of structured data) directly into Wikipedia because this is where the people that really care about sharing the worlds knowledge openly are actually working.  If the Wikipedia community had a better knowledge authoring platform to work with we simply wouldn't be having this discussion.  The ability to clarify the meaning of the relationships between concepts in a way that could be used within the system to enable queries, improve navigation, improve search, and automate mundane tasks such as list creation would simply be built in.  But, for various unknown reasons, we don't.  We can wait until another better platform magically appears (I don't see it coming soon), we can move such efforts like this away from this wonderful community (and likely towards corporate concerns) or we can work right here with what we have. Benjamin Good (talk) 21:50, 21 October 2011 (UTC)
 * So, in other words, you want to make Wikipedia into a knowledge base, because that would be good for that field of study..? And you hope that if this field of study will develop significantly, Wikipedia will also get some benefit (but you do not really know or imagine how exactly that will happen)? --Martynas Patasius (talk) 23:30, 21 October 2011 (UTC)
 * What? Could you clarify this comment, please? Pleiotrope (talk) 01:40, 22 October 2011 (UTC)


 * Well, I guess I could, but what exactly should I clarify? Anyway, I'll try again: do I understand correctly that the supporters of this change want to implement semantic links on Wikipedia because that would help to develop the field of study that concerns those semantic links? And that they hope that those developments, in turn, would be beneficial to Wikipedia (in some way)? --Martynas Patasius (talk) 16:25, 22 October 2011 (UTC)


 * We are not trying to "develop a field of study", we are honestly trying to make Wikipedia a more useful place to capture and share knowledge. I assume the 'field of study' you speak of is the semantic web and, more specifically, semantic wikis.  These fields are actually pretty well established and the point of this exercise is not to extend that field of research.  We simply hope to make use of their progress in the context currently offered by Wikipedia.  To see a long list of examples where semantic relationships are freely created by wiki editors and used to great effect, have a look at this list of semantic media wiki deployments. By the way, thanks for all the hard work and thought you've put into this discussion.  Though we clearly don't agree, I appreciate your enthusiasm.  Benjamin Good (talk) 17:21, 24 October 2011 (UTC)


 * The userscript is not actually a toy. If you had installed it and given it a try, which you weren't obligated to do, of course, you would have seen that clicking on the relationship in the "infobox" would have directed you to a page regarding the meaning of that relationship. If you had actually tried writing an SWL template in the sandbox article, you would also have seen that your previous examples regarding the pony and behavior fields would have resulted in malformed wikitext and would have been inappropriate. But since you didn't, and are playing the part of a user without the userscript installed and curious as to the use of the SWL template, I would imagine that you could look on the template's documentation (at Template:SWL/doc, like every other template), and discuss it on the article's talk page. This is the established procedure for everything else on Wikipedia. Pleiotrope (talk) 01:40, 22 October 2011 (UTC)


 * Sorry, but it is a toy. A nice toy that is fun to play with and must have been fun to create, but still just a toy and not a serious tool, nor a prototype of one. For if we really wanted to create custom infoboxes, we would do what we do with succession boxes (you know, a template for the start of the box, a template for the end, templates for the records - Template:s-start, Template:s-end etc.). I don't see in what respect that would be worse than this "fake infobox" (unless, of course, you count using semantic links as a good thing and not a bad one).
 * Looks like another proposed use of semantic links was generating lists automatically. Now that has actually been tried in Lithuanian Wikipedia: parts of articles about days and years that concerned births and death were generated from biographic articles (lt:Vikiprojektas:Gimtadieniai ir mirtys, lt:Vikiprojektas:Neaprašytos asmenybės). The result was a complete mess. I guess that only the initiator himself (and his sockpuppets) could actually use the whole system of biographic articles, day articles, year articles - and lists of birth and death records for persons without articles about them...
 * Now about "previous examples regarding the pony and behavior fields". Well, now I know that you expect that internal links will not be created just so that semantic links could be added. But still, there should be some draft of a guideline that would actually say so - and I think that you should start from it and not from some template or user script.
 * Also, concerning one more "If you had actually tried [...]"... I see that the type "behavior" should be described and documented in Category:SWL/behavior, right? I guess that in such case its description could be discussed on the category's talk page... But, unfortunately, no description has been given. Furthermore, the category hasn't been added to Category:SWL like some others. And also, "if any of us had actually looked at it", we would have seen several mainspace articles in that category... In short, the trial has been started some time ago. And the users who are the most enthusiastic and knowledgeable about semantic links participated in it. And - yes, the system is a mess already... So, do we need another trial, or can we accept the results of this one..? Oh, and I think we should actually end it and remove the template from mainspace articles. --Martynas Patasius (talk) 17:27, 22 October 2011 (UTC)

I don't like the overall cost/benefit ratio. There is some benefit for readers (though I'm not convinced it's that big a deal) and there's a lot of potential for benefits for algorithms trying to make sense of the data which in turn may help readers. But the costs are way too high. The biggest problem is the added markup. Moving from
 * It is a strictly nocturnal owl, which feeds on small mammals and birds.

to
 * It is a strictly owl, which feeds on small mammals and birds.

is a significant problem for new editors. True, the ref tags are also a big problem but we absolutely need mechanisms for referencing whereas this proposed experiment is not essential. I'm also pessimistic about an orderly introduction that doesn't involve megabytes of discussion about the preferred ontologies and widespread confusion. Editing time is a limited resource and I believe it would be better spent elsewhere. Pichpich (talk) 16:07, 25 October 2011 (UTC)

At this stage, especially with in-line refs already being a huge nuisance, I would also agree that the cost/benefit ratio is too high. And, as small potatoes as this sounds, I also dislike the visual clutter of the orange underlines. --Hobbes Goodyear (talk) 12:07, 26 October 2011 (UTC)

Proposed change to CSD template text display
In the interest of drumming up some comments, there's a protected edit request at Template talk:Db-meta. – Luna Santin  (talk) 20:35, 26 October 2011 (UTC)

Google Knol

 * De-archived for more feedback. Headbomb {talk / contribs / physics / books} 07:31, 26 October 2011 (UTC)

I'm browsing the wiki and it seems all references I see to Google Knol are either spamlinks or completely inappropriate for other reasons. Would there be any problems / objection to adding it to the edit filter per WP:RS? Headbomb {talk / contribs / physics / books} 05:53, 14 October 2011 (UTC)
 * A couple I just checked in the LinkSearch list did not seem helpful. Johnuniq (talk) 06:53, 14 October 2011 (UTC)


 * Ditto for answers.com, answers.yahoo.com, wolframalpha.com, metafilter.com, vark.com, nndb.com and similar sites. Talk and other pages are OK but no way are these reliable sources in an article. Do need to be able to include the main website link in the article about the site. ---— Gadget850 (Ed)  talk 11:51, 14 October 2011 (UTC)
 * Speaking technically, is there a user right that allows its holder to add a link that's on a blacklist? Of course, an admin could remove the link from the blacklist, add it to the page, and restore it to the blacklist, but that definitely doesn't seem ideal.  If so, it would seem to me that we could simply blacklist these pages, add comments to the articles about these sites noting that their links are blacklisted, and add a note to the relevant warning (i.e. the one you get if you try to add a link that's blacklisted) instructing users to post at WP:AN or whatever the relevant page would be if they have good reasons for including their links.  Nyttend (talk) 21:32, 14 October 2011 (UTC)

De-archived for more feedback. Headbomb {talk / contribs / physics / books} 07:31, 26 October 2011 (UTC)


 * Pardon the potentially unwanted metacommentary, but is there a reason that the blacklist still exists as a separate entity to the edit filter at this time? It seems as though the edit filter has all the features needed for it to handle blacklist content (i.e. match a regular expression and prevent an edit containing it). FWIW I'm in full agreement that the UGC sites in question (yours and Gadget's) should be filtered from mainspace. Chris Cunningham (user:thumperward) - talk 12:34, 26 October 2011 (UTC)


 * One problem with moving the blacklist entries to the edit filter is that the edit filter already hits the condition limit regularly, which lets things slip through that shouldn't. The more stuff that's added to the filter, the more often this limit is hit. 28bytes (talk) 15:40, 26 October 2011 (UTC)


 * I'd prefer blacklisting it, but the edit filter would be better than nothing. Dougweller (talk) 13:47, 28 October 2011 (UTC)


 * Neutral I can imagine a "google knol" article being a courtesy copy of a real published paper, so the black list may be inappropriate. However, I quite agree that almost all uses are either of "articles" completely unusable, or being suggested in violation of an ArbCom rulling (CH), I don't have a definite opinion.  — Arthur Rubin  (talk) 22:14, 29 October 2011 (UTC)
 * Support as an edit filter. If some slip through so be it, LinkSearch will allow patrollers to catch usages. Don't blacklist it, as there are some legitimate uses (WP:SELFPUB). &mdash; Train2104 (talk • contribs • count) 13:47, 31 October 2011 (UTC)
 * Neutral The externals to it I've seen have been rubbish or spam for a blocked user and it could never be counted as a reliable source but I'm unsure about this idea of actually blacklisting it. Dmcq (talk) 17:31, 31 October 2011 (UTC)
 * Wary of blacklisting anything that isn't actually a) being actively spammed by it's owner or b) demonstrably useless or c) both. Rich Farmbrough, 00:25, 1 November 2011 (UTC).

Propose time spans and more precautions to Archiving
Recently (very recently) i was having a discussion which was archived way too quickly. I noticed WP:ARCHIVE doesn't give any examples of misuse of archiving. I propose we add a certain time span before any manual archives are done and to allow reverting certain archives.Bread Ninja (talk) 14:35, 28 October 2011 (UTC)
 * It would be hard to establish a minimum time before archiving that would work across all talk pages. An appropriate archiving delay on an obscure article talk page that can go months without comments may be 3 months, while the talk page of an article about a controversial news event, getting 50 comments a day on a variety of topics may justify very fast archiving with a delay of a week or less (sometimes 2 days). (the problem is when the topic cools down, the fast archiving may not be slowed down) Other then to call on editors to use good judgment, I don't know how one would word specific guidelines. Monty  845  18:31, 28 October 2011 (UTC)
 * wp:CREEP says no. Looking at the actual event it just seems to be a new user not understanding how our archiving works (and thinking the situation was resolved) and a somewhat unlucky revert from User:C.Fred. Just deal with the situation (look, I did!), no need to make up new rules for it. Or does this happen to you daily? Yoenit (talk) 19:46, 28 October 2011 (UTC)
 * Not exactly what i'm trying to say. Archiving can "easily" become vandalism. For articles that have 50 post a day, i can definitely understand as it gets so big it'll be difficult to handle. Anyways.....i still believe manual archiving should have more control. I was also thinking this would help control more situations where manual archiving isn't done properly. Anyways relying it on judgement alone is a bit difficult.Bread Ninja (talk) 19:04, 31 October 2011 (UTC)

Concern regarding mass page creation from other wiki
This is not a proposal so much as I would like to get the village pump opinion, and ensure compliance with Bot_policy which indicates the pump should be notified. Dr. Blofeld is mass creating literally hundreds of pages (5-7 per minute) of a stub of every river in germany, with no content except for a link to the german article saying it could be translated over. I am not super invested in the result, but it seems like a violation of policy, and almost spam to be creating hundreds of articles. If the consensus says its fine, I will go away to my corner :) Gaijin42 (talk) 20:29, 28 October 2011 (UTC)
 * stop spamming this everywhere, it is disruptive. Yoenit (talk) 20:31, 28 October 2011 (UTC)

Requests for various Δ tasks
Given a discussion at Wikipedia:Administrators' noticeboard/Incidents#Clarification needed, I am about to embark on posting a number of proposed tasks for $\delta$. There is no attempt on my part to overwhelm this board with such requests. I understand some of you may feel this way. Whatever the case, I would appreciate it if meta discussion about the appropriateness of these requests is kept in this thread, rather than in each specific task request thread. Please restrict your comments on those threads to those tasks only. Thank you, --Hammersoft (talk) 17:28, 24 October 2011 (UTC)
 * I support them all most of them, but I am not clear where do you want us to say so :) --Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:31, 24 October 2011 (UTC)
 * You don't need to. The restrictions are to query if there is opposition, and if so to allow for consensus to develop before undertaking further edits of the kind. --Hammersoft (talk) 18:32, 24 October 2011 (UTC)


 * Oppose all - there is no evidence of any change in the approach that gave rise to Beta's automated editing restrictions. The last thing we need is an end run around those restrictions via a flock of new proposals for automated editing.  It would be wonderful if beta would overcome all of the hang-ups that landed us here, but for now he apparently has not.  - Wikidemon (talk) 08:07, 25 October 2011 (UTC)
 * Oppose all for now. Delta needs to be answering questions about what he's planning and the proposals shouldn't be open-ended but rather a specific set of edits he's planning on making. As such this should _really_ be Delta making the proposals. Having a 3rd party do it is a recipe for disaster as the "telephone" game just gets worse.  What does _Delta_ mean by being able to prod articles as a "pattern?"  Does he think that gives permission to prod (or for a different proposal) redirect 100s of articles at a time? I think this whole section misunderstands the point of the editing restrictions. I agree with JohnFromPinckney's comments and he says it a lot better than I could.  Hobit (talk) 10:38, 25 October 2011 (UTC)
 * In any case, I think any "mass" permissions would have to come with the restriction of actually using meaningful edit summaries. Hobit (talk) 10:43, 25 October 2011 (UTC)
 * opppose all per my comment on #10, and honestly this entire process seems rather to be rather bad faith, pointy and almost a little gamey as John points out below--Crossmr (talk) 11:38, 25 October 2011 (UTC)
 * Ah, so he's required to make these requests but if they're made in accordance with requirements, it's bad faith, pointing, and gamey? If the requests aren't made, you slam him. If the requests are made, you slam him. I've known for a long time that you would oppose anything having to do with editing here, but you're really jumped the shark now. --Hammersoft (talk) 13:04, 25 October 2011 (UTC)
 * Actually I'm slamming you for being disruptive at this point. 20 proposals? Are you serious? This is beyond pointy at this point. Delta is required to propose specific tasks that he wants to undertake. These tasks should have a start and end point, like a normal proposed task. They aren't to propose blanket exceptions for any edits he wants to make from now until the end of time.--Crossmr (talk) 15:28, 25 October 2011 (UTC)
 * This is exactly what all the past restrictions and ANI threads have reduced this process down to - getting the community to approve every single action that Delta is allowed to take, one action at a time. And that's because of editors that aren't giving any good faith on Delta's ongoing attempts to improve his communication and stick to beneficial edits and instead focus on numbers and editing rates and anything that may end in a permaban from the project.  Editors want Delta to be operating under a microscope, so to prevent him from doing anything undocumented, we better be getting a writeoff on the community for every single step in the process.
 * This is what all the wikilawyering to try to bust Delta has come to. --M ASEM (t) 13:39, 26 October 2011 (UTC)
 * Because good faith is not a blind shield or an everfull well that one can go to again and again. Delta spent his good faith a long time and needs to earn it back. That's why he's under such heavy restrictions, and why people won't let him out from under the microscope. Because it never ends. It was only 4 months ago or so we had the whole NFCC drama due to his edit warring (technical or non-technical), poor communication with a little uncivil behaviour on the side. That is a problem that is still present despite being let back in and given that nth last chance a couple years ago.--Crossmr (talk) 23:03, 26 October 2011 (UTC)
 * That itself, I can't disagree with. The problem is the issue of complaining about what this specific process (Hammersoft proposing what tasks Delta is doing) is trying to accomplish. It's defining the stage that Delta should be operating on.  And yet you're complaining that this process is "pointy" despite the fact its trying to establish bounds.  The process being used is almost exactly the same as for many bots that operate indefinitely, fixing as corrections are needed, as opposed to a "task".  There's nothing wrong with that. Yes, I understand that many don't have good faith in Delta anymore, but its another thing to throw out any responsible presumption of someone trying to work within those bounds within good faith. If you can't support that, then, as Hammersoft has often said, you might as well start writing the proposal to permaban Delta from the project. If instead you think Delta can improve - even if there's a very long and hard road to reach that improvement, and that ban isn't needed, then let some good faith work here to let the process as already outlined by his restrictions work through instead of trying to stymie it. --M ASEM  (t) 23:20, 26 October 2011 (UTC)
 * As I've clarified multiple times, the issue is with how he's done it and it's not remotely in the spirit of Delta's current restrictions. Hence why I've taken issue with it and outlined the various guidelines and policies I think this entire process violates, and I'm not alone in that assessment. The point of this restriction was for specific focused tasks, not unlimited exemptions to his restrictions. The issue was further pushed when it was clear there was not really any support for the vast majority of his initial proposals (the only that gained it was a task bots already do) and then going back and putting in a whack more. That reaks of WP:IDIDNTHEARTHAT--Crossmr (talk) 10:16, 27 October 2011 (UTC)
 * There is no difference between a task that affects a finite number of pages and an ongoing task that potentially can affect all pages on a recurring basis; the issue is that both are "patterns of edits affecting more than 25 pages". There was nothing about having focused specific tasks; the restrictions are there to prevent Delta from using rapid-fire bots or user scripts like AWB to perform changes that he wasn't correcting.
 * Now, I will say that there is fair concern that you're worried that its an omnibus of tasks that are being proposed inside of one at a time. But that's why there is a push to get a proper edit summary and a page to outline what exactly has been approved for Delta to do, as well as what I suggested, a trial period with deep review to verify he's doing the tasks he's approved for.  And just because a bot can do a task doesn't mean Delta's prevented from doing that; there's no restriction on his or any editor from doing bot work on their own - if you feel that needs to be in place for Delta, then you need to go ahead and start proposing yet another restriction on his editing.  Instead, to me, I'm taking the fact that the tasks approved for Delta below are ones that since a bot can do it, that Delta's changes have little chance of harm even while throttled or the like - in other words, the community has no problem if Delta's wikignoming are simple to correct and impossible to screw-up tasks even though he's still required to manually check those edits.
 * Remember, that the community restrictions are indefinite - that means that unless you want to ban Delta now from the project, you have to give him the opportunity to work within them to demonstrate that he's capable of doing that. This process is part of that.  --M ASEM  (t) 13:01, 27 October 2011 (UTC)
 * They're indefinite but they're not permanent. If Delta can ever get it together for a long period of time he could probably start to have them removed. There is a difference between edits bots do and edits bots tend to do very quickly, like dating maintenance tags. These days I find it pretty uncommon to come across undated maintenance tags. As for the specific focus, we've heard from the person who drafted that restriction and he stated that that was indeed the purpose of that restriction, and some of those opposing seem to feel the same. And again this entire process was born of bad faith, VPP was brought up and discussed last may/june over Delta because he undertook a day and halfs worth of edits before that whole blow up and him going ahead and proposing them at VPP. it wasn't in his block log, but it has been out there at least 4 months and no one has been doing the things hammersoft and dirk claim were going to happen. --Crossmr (talk) 22:59, 27 October 2011 (UTC)
 * Before someone actually noted that this appeared to be a pattern of edits affecting more than 25 articles, Delta was going along and did 8000 edits like this with minimal drama; people did point out problems that Delta responded to to either stop doing or alter things. And no, this is not to wave away some of the problems that editors like Fram have identified in spot-checking these edits but at the same time, the end result is not a complete failure in the article presentation unlike the edits that led to the original restrictions being placed. The issue here was that this wasn't positively identified as a series of edits until now, and thus led to the current drama. Though if Delta wasn't blocked and he continued these types of edits I'm sure someone would have eventually done so, but at the same time while not on anyone's radar, they aren't tipping the boat or raising any issue that haven't be dealt with easily through communication. Exactly the aim of the original restrictions. The current problem is due to lack of clarity, and certainly doesn't seem like an intent for Delta to bypass them. --M ASEM  (t) 17:10, 28 October 2011 (UTC)
 * The problem is you're trying to sidestep the issue again. My main point is hammersoft violating: WP:POINT, WP:GAME, WP:BEAN and that the entire premise of this section is founded on an an assumption of bad faith. The bad faith is clearly demonstrated by the fact that Delta and the whole needing to submit things was raised in May. Hammer and Dirk were making all kinds of bad faith claims in the AN/I thread that people were going to be going back over 2 years, finding 26 like edits and then having Delta run out of Wikipedia. This section was born out of that bad faith theory. The earlier discussion from May demonstrates that that issue was on the forefront of our last big Delta discussion. I recall it coming up several times. And neither then, nor since then has anyone gone ahead and done that. Hammersoft has clearly wandered into WP:IDIDNTHEARTHAT territory below now, further amping up the disruption. The second point is that Delta doesn't need blanket exemptions for these kinds of tasks to go on indefinitely. He's done nothing to earn that.--Crossmr (talk) 23:17, 28 October 2011 (UTC)
 * From the ANI thread that led to this, it is clear that while the "26 edits in 2 years" was an exaggeration, it is clear that editors want Delta to not do more than 25-like edits in some time frame without prior approval, believing that was a pattern of edits the 1st restriction warned about. Whether it was or wasn't is immaterial here: the reason Hammersoft started this was to assume the answer would be yes (since it was far from a small minority that felt it was a pattern), and thus establish the VPR process laid out by that restriction. Basically, looking two steps ahead of where the ANI discussion was going to establish these tasks that Delta would work under. I cannot see how you're taking that in bad faith; yes, I realize Hammersoft is not soft-spoken, but I see nothing but trying to help Delta gain the good will of the community - even that community that is making sure Delta follows to the exact letter of the law - by making sure Delta's following the set process.  It is far far far from being pointy or in bad faith.
 * As for the second point, considering these as blanket exemptions, that's why I introduced the idea of trial periods, but I would have no problem if that further was extended into trial blocks. Maybe a first block of 100 articles, a second of 250, and so on, allowing the community to judge if the edits were all appropriate before asking for a larger block and/or adding a new task to his cleanup aspects. What you're trying to ask for, however, "This will affect X articles" is impossible to define for cleanup tasks since how many articles are actually affected is the size of the entire en.wiki. But again, if we restrict him to small blocks and give him more allowance as he shows the competency that the community is expecting of him, he can still be the productive wikignome he wants to be but within the limitations of the restrictions. --M ASEM  (t) 23:44, 28 October 2011 (UTC)
 * Yes, it is an exaggeration, but let's not mince words, it was repeated several times by the both of them and it's clearly a bad faith assumption which has no basis in reality. The VPR restriction as clarified is supposed to be targeting specific tasks. Not open ended exemptions as these indicate. If Hammersoft wants to help delta he should be helping him work within the restrictions laid out and not try and find a way to wriggle out of them. Disruptive side of this became obvious when despite there being a dozen or so proposals here already that didn't have any support, he went and added several more with an ominous message of "more to come". It doesn't need to target X articles. It could target articles in a specific project, category, etc. It could be limited to run for X edits, or X days. However, Delta needs to come up with that himself and actually show that he understands what is going on, because it is becoming increasingly clear that he doesn't seem to. I've got more, but gotta head out. His insistence below that Delta is not even allowed to edit is beyond absurd.--Crossmr (talk) 06:12, 29 October 2011 (UTC)
 * Even though you're already involved in that discussion, I've raised this entire proposal business at the AN/I thread on Delta.--Crossmr (talk) 15:43, 25 October 2011 (UTC)
 * Catch 22 on Wikipedia? Who would've thought... sigh. --Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 17:55, 25 October 2011 (UTC)
 * I asked for and received permission from to operate on his behalf in making these requests. He has helped in me conducting these requests. He's aware of them, and supports them. I am not acting independently. Given that, splitting hairs about who is making the proposals isn't going to gain traction. He is required to make these proposals. They are being made. If you have an alternate proposal (other than him being banned from the site), I'm all ears. --Hammersoft (talk) 16:18, 25 October 2011 (UTC)
 * The problem is that you've created a blanket set of generic exemptions when it seems very clear that the intention of the provision in the sanctions is so that Delta can make requests on specific tasks. The provision was not intended to indefinitely reduce the scope and effect of the sanctions, which is fundamentally what these proposals are about, and this is what makes it appear that you're trying to game the system. TechnoSymbiosis (talk) 22:48, 25 October 2011 (UTC)
 * So what's the solution then, if not to approve highly specific task descriptions short of getting approval for every single specific edit? The reason we're here now is because the idea of "pattern of edits" in his editing restrictions has been read very broadly, and leads to a grey area of what are patterns and what are not.  Because some are taking his most recent edits, regardless if beneficial or not, as a pattern, Hammersoft's gotten Delta to enumerate them all the propose each one per the editing restriction.  Ergo, it is not carving out exceptions, it is identifying tasks he is allowed to do within the confines of the editing restrictions.  This is exactly what the community was pushing towards. The fact that as I read the input back from the it now that some tasks are acceptable, some not, means this is working within the intent of the editing restrictions. --M ASEM  (t) 13:45, 26 October 2011 (UTC)
 * My reading of the restrictions was that when Delta has a specific task he wants to complete (eg. correcting link order on a specific set of 100 articles), he proposes that action here where it's reviewed and then approved or declined. It's not my reading that one can simply propose 'Delta can change the link order in an infinite number of articles', since that's a blanket reduction in his restrictions - he can now do exactly the things that caused his restrictions in the first place, without being in violation of those restrictions. I simply don't see that as the intent at all. These are strict restrictions, they're not meant to be reduced indefinitely as each of these proposals requests, they're meant to be waived temporarily for the completion of specific tasks. TechnoSymbiosis (talk) 22:01, 26 October 2011 (UTC)
 * I don't read it that way, but taking that point into consideration and a point I made below, it may be a very good idea for Delta (or Hammersoft) to define how the articles that Delta plans to work on will be selected so that we know what will be impacted. That said, that gives me another idea to add below in regards to a "test block" for community review so that we can have a limited task be extended to an ongoing task, just like we sometimes do with bots. --M ASEM  (t) 23:27, 26 October 2011 (UTC)


 * Oppose all (overriding my individual votes below) if these exemptions can in any way be interpreted to allow Delta to perform automated or semi-automated edits, or edits that appear automated, in contravention of his current restrictions. Some of the comments below, including by Delta himself, imply that he intends to use scripts to perform these tasks. My reading of the sanctions is that these exemption requests only allow Delta to exceed his 25 article limit. His restriction on automated edits is not within the scope of these requests to release, and any interpretation of these exemptions must strictly acknowledge that Delta may not perform such edits. TechnoSymbiosis (talk) 23:26, 25 October 2011 (UTC)
 * Don't kid yourself. Him and his supporters plainly admit he uses scripts, but that he is not barred from doing that as long as he manually reviews the edits. The difference between fully automated use of scripts and semi-automated use thereof but with occasional lapses is a matter of WP:AGF and essentially unverifiable within the confines of Wikipeda's operation; WP:PRIVACY, etc. I don't think he'd agree to type in a captcha with his every edit, and even that would not guarantee that the rest of the edit had human supervision. Uʔ (talk) 06:29, 26 October 2011 (UTC)
 * I'm not overly concerned with the verifiability of the restriction so much as the essence of it. I don't think it should be lifted, and people are often quite creative at finding ways to verify something I didn't think could be verified. TechnoSymbiosis (talk) 21:56, 26 October 2011 (UTC)
 * AFAIK, the community has said it is fine for to use supervised scripts - This is in no form a request overriding the speed limit, the civility restriction, or use full automation limit or whichever other restriction.  If it is clear that a script runs without him (e.g. that someone asks him to stop on the talkpage, and the edits continue without response) then yes, that is fully blockworthy, as are incivil remarks and too fast editing or other violations of restrictions.  It also does not allow other patterns to emerge which are not granted here, it does not allow to continue with patterns which are not granted here.  It strictly is, that any pattern of >25 edits is disallowed, except those for which here is consensus that they can proceed.
 * I still think the word 'pattern' is too ambiguous and unclearly defined at the moment - but there clearly is no support in trying to define it better, support is more that it is left to administrator discretion. I am sure we will be here soon (and/or AN/I and/or at 's blocklog) because someone will find a new pattern soon enough, but maybe that will go nicely through a fresh thread here.  --Dirk Beetstra T  C 14:16, 26 October 2011 (UTC)
 * Oppose most. The only exceptions are those that could be done by a bot, there in consensus as to exactly what the bot should do, and (unless fixing something that causes a broken view) be combined with a substantive edit, and with the provision that exactly what task is being done needs to be in the edit summary.  Among tasks 1-20 this is 4, 6 (only applying to visible whitespace, meaning not within references, as the examples indicate), 7 (only if the link is checked manually, as opposed to by a script), 8 (with the indicated restrictions), 9, 12 (and I might exempt this from the substantive edit requirement, but the references must be identical), 13, 18, 20 (and I might exempt this from the substantive edit requirement, as well.)  Strong oppose 10, 11, 15, and 19, and separately oppose 16 and 17, as not having a reasonable consensus for the action.  The example in 19 is not appropriate.  — Arthur Rubin  (talk) 22:33, 26 October 2011 (UTC)
 * Oppose all The restrictions are appropriate given this editor's long history of controversial behavior. (That he has been permitted to edit at all is quite astounding to me.) ElKevbo (talk) 17:30, 1 November 2011 (UTC)

Δ meta discussion

 * I have a broad concern with the phrasing of these tasks. They are situations where they are OK, but there are nevertheless exceptions or situations where they should not be applied. If a task is "authorized", that has to mean that exceptions will be recognized too. If a few days from now, people say the task shouldn't be applied in some circumstances, I don't want to see an argument claiming "it's authorized so it can be done". Gimmetoo (talk) 20:15, 24 October 2011 (UTC)
 * Likewise, in the other direction, there shouldn't be people using the restrictions as bludgeoning tool because they disagree with, despite approval here, and insist he must comply with their interpretation. There will always be differences of opinion between all editors. --Hammersoft (talk) 20:33, 24 October 2011 (UTC)
 * I support kittens and puppies and oppose running out of tea bags. --  fg T C  22:07, 24 October 2011 (UTC)
 * Comment. It's amusing that his friends are petitioning here for trivial tasks, when clearly these are not the ones that have caused the ruckus. Have mörser, will travel (talk) 04:57, 25 October 2011 (UTC)
 * I'm worried about the extremely persistent use of "Cleanup" as an edit summary -- if semi-automated tools are being used, they can be written to provide a more useful summary; if the changes are being made manually, it shouldn't be a problem to explain them. Given the nature of the sanctions, more specific edit summaries might be very helpful. – Luna Santin  (talk) 04:58, 25 October 2011 (UTC)
 * Agreed. Have mörser, will travel (talk) 05:00, 25 October 2011 (UTC)


 * Seeking clarification. Apparently, this thread is about a particular user, named Δ. That much I've figured out on my own. I've successfully avoided knowledge of the User:Δ, but since you, Hammersoft, have made his existence and problematic behavior so impossible to ignore, I feel compelled to ask for clarification of this huge thread (around 60K bytes so far).


 * It seems that Δ is a user so unable to get along with his fellow Wikipedians that he's been to AN/I and ArbCom, blocked and banned, and even needs his own personal template so we can even address or refer to him. Apparently, he has a penchant for making long series of edits with uninformative edit summaries; he seems to use a script to help him make many edits in a short space of time, whether the edits are seen as useful or desirable to the WP community or not. Often, I guess, they're not.


 * Now despite his egregious behavior he has a chance to avoid a complete ban, if (among other things), he gets approval for any pattern of edits to more than 25 pages. It seems an obvious oversight that the editing restrictions don't specify the timespan for the 25-page limit, but I assume that'll get cleared up somehow. But what I don't understand is what you're trying to accomplish here with all of these "Δ Task" threadlets. You seem to be pre-emptively seeking permission for all the kinds of behavior that got Δ into trouble in the first place (except using obscure edit summaries; you don't seem to have addressed that yet). That seems to go against how I see the editing restrictions.


 * The way I understand it, Δ is allowed to edit (or would be, if he hadn't gotten blocked again), but if he sees a particular set of articles he wants to make similar changes to (the "pattern of edits"), then he needs to then seek specific approval. So, if he says,"I just noticed the articles on Law & Order episodes, and I see that the last four seasons' pages all have X, when they should have Y," then he can come and seek permission to do X-to-Y changes on those articles (still observing the 4 edits/minute in 10 minute restriction when he gets consensus).


 * Instead, you want to get permission in advance to change X to Y on any article (all articles, in fact), just in case Δ gets the urge to perform that pattern of editing. Do I understand your objective correctly? Because if I do, it seems to be misinterpreting the intention of the editing restrictions and the allowance to avoid the ban. But maybe I'm the one misinterpreting things. &mdash; JohnFromPinckney (talk) 09:56, 25 October 2011 (UTC)
 * is required to ask permission to make repetitive edits. Since some people are construing that requirement very broadly, the situation now is one in which any edit of 's needs to have basis in there being a request here to perform that edit. He's already been doing these edits. So it's past and future. If he's done enough of them that the next one of a type will be some number above 24, some editor will cry foul when he does a similar edit if there's not a specific request here. This is the silliness that we are forced to contend with. Since he's required to make these requests, and he's authorized to make these requests on his behalf, the requests are being made to cover every possible kind of edit that he might do that someone could remotely construe as "pattern". --Hammersoft (talk) 13:02, 25 October 2011 (UTC)

I have suggested on AN/I that when someone construes something as a pattern - whether before the 25 or after the 25, that that person has to bring that to AN or AN/I, and notify. is at that moment stopping with that part which is construed as a pattern, and either awaits whether the construed pattern is not deemed a pattern, or asks for permission (latter wise anyway) - no blocks applied, even if there are already hundreds of edits that fit the pattern (but blocks can be applied when a significant number of edits with that pattern are after the notification). --Dirk Beetstra T C 13:07, 25 October 2011 (UTC)
 * No, that leaves the door open for Delta to, for instance, make 2000 rapid edits to articles in what very blatantly constitutes a pattern, have someone complain about it, have the community decide 'yes that's a pattern', then move on to another 2000 rapid edits different enough that he can claim they're not a continuation of the same pattern. Part of the problem with Delta's editing, from what I can see, is that he makes questionable edits in such numbers that it's almost impossible for someone to check his work afterwards, or worse to clean up a mess that is caused as a result. My reading of the sanctions is that the '25 articles' figure is a throttle, to slow him down so that others can review his edits more easily, and that if he wants to do more than that he needs prior approval so that people can review his intended changes beforehand. Giving him free reign only until such time as someone complains is effectively lifting the sanctions altogether, something I doubt will gain much traction. TechnoSymbiosis (talk) 23:34, 25 October 2011 (UTC)
 * Under his editing speed restriction, (40 edits in 10 minutes average), 2000 edits would take him 500 minutes - a bit more than 8 hr - to complete if he stayed within that speed. Someone will notice that first.  So he has a throttle already. The idea of the original 25 article piece was to prevent Delta from instituting a common set of changes that did not have community approval - eg, the equivalent of running an unauthorized bot without having gone through the bot request process.  The problem is that there is a grey line between a pattern of edits and making similar edits in several articles.  What one may consider a pattern will not be by another. Therefore, if Delta does start doing something that he himself doesn't consider a pattern but someone else does, he needs to be alerted to it and discussion needs to ensue to determine if that is a pattern of edits. Since he's already pointed to VPP to request patterns of edits, it makes the most sense that the discussion take place there.  But importantly, as soon as someone says to him directly (talk page) that they think it is a pattern and they're opening up discussion on it, Delta should be expected to stop that specific action. --M ASEM  (t) 13:29, 26 October 2011 (UTC)

I've been watching this set of proposals grow and am horrified. It now looks as if directed by a council of Vogons using an action plan devised at The Circumlocution Office.

No one editor should have special rights. If edits are good keep them. If intentions are good but edits aren't: undo and get over it. If intentions are bad: undo, warn, warn again, block. All these policies and/or guidelines are in place.

A continuation of discussing any change in policy or guidelines should be done without basing (more like debasing) them around one editor. The whole pattern of 25 edits business is also in place for seemingly good reason. Why should any one editor get a free pass? I hope this set of proposals is considered unacceptable under some other policy or guideline because they are outrageous. --  fg T C  06:05, 26 October 2011 (UTC)
 * Blocking doesn't work when someone has a vocal group of supporters endlessly arguing for unblock at ANI because they see the restrictions as unfair to begin with. Uʔ (talk) 06:32, 26 October 2011 (UTC)


 * Unfair? Who said that?  I think I would use the word 'ambiguous' to describe my concerns.  --Dirk Beetstra T  C 14:03, 26 October 2011 (UTC)

One question has come up repeatedly: should be performing edits which can be handled equivalently by current bots? Several of the proposals below have objections relating to this question. Some recent discussion at. – Luna Santin  (talk) 23:16, 26 October 2011 (UTC)
 * And since that question is likely to need its own sub-thread, here's another question: what about reverts? If someone (i.e. a regular editor of the article) disagrees with a set of changes, especially those approved only as accompanying some other substantive changes, what do they do? Is the onus on them to sort out only those changes they disagree with from among an a large set of separate changes in the diff, preserving the neutral changes and the one good bit of visible change? Or can they revert all of it? Can the whole thing be re-reverted as "community approved task, discuss specific problems on talk page". This will come up sooner or later. Not to obscure your own question, which does need separate consideration. Franamax (talk) 02:14, 27 October 2011 (UTC)
 * Well, you have to admit it's an insanely tangled mess we've got ourselves in, don't you think? The locus of all of this is, is it not? So let's take the easy road; let's just ban and be done with it. No more debate, no more worries, no more endless threads. Nice, neat, convenient. --Hammersoft (talk) 12:47, 27 October 2011 (UTC)
 * No, the locus is Beta's unrelenting desire to make code-assisted edits that cause the wiki to conform to their own idea of what it should be, as fast as possible. Is and always has been. A deficient style of communication only becomes a factor because the inevitable errors, times the fast pace, result in multiple and prolonged questions, which is where Beta inevitably snaps. Franamax (talk) 21:43, 27 October 2011 (UTC)
 * Actually I rarely rarely ever snap, if a user comes to my talk page to raise an issue. I only get short with someone after repeated cases where the person does not listen, will not read what I ask them to read and makes continuous personal attacks/and or insults against me. Anyone will snap if pushed too far. I do not snap unless pushed extremely far. ΔT The only constant 02:08, 28 October 2011 (UTC)
 * Which of course is all completely 's fault. So again, why not just ban him from the project and be done with it? --Hammersoft (talk) 02:04, 28 October 2011 (UTC)

Manual vs. automatic
Δ claims that all 8000 or so cleanup edits were checked before saving, and that they were not made in a bot-like fashion (i.e. not simply pushing "save" without checking). Anyone who has seen the speed of these edits, and the huge diffs they generate, may have doubts about this, but in the end the only thing we have to check is the actual result of these edits. At the end of september, I checked a number of these cleanup edits, and fould quite a few errors in them. These were mostly corrected in the script afterwards, but suggest to me that these edits weren't really checked manually. Looking at a small random sample of other cleanup edits show that e.g. here a bare url is given the description "Yasni-Ergebnis für http://northtexan.unt.edu/content/nathan-kelly". The fact that this is in German is due (probably) to some user preference of Δ, when I check the same link the title it is in Dutch, and for most of you it would be in English. Manual checking and editing would have seen and corrected this. One can also wonder whether bare links aren't better than promotional title pages like (from the same edit) "Books, Discount Books, Cheap Books, Australian Bookstore - Emporium Books". Perhaps something to take into account at proposed task 13? In this diff, for some unknown reason a cite web template is replaced by a bare link plus title, resulting in the loss of the accessdate and the gain of a promotional title, changing ^ See "photoquotations.com". Retrieved December 29, 2010. to ^ See photoquotations.com ⁄  world's largest photo quotation resource. Not really an improvement... This is an example of adding titles to bare links, even though titles are already present. A bot can't detect this, a human should (e.g. it changes . . to ).

Six edits checked, three with problems. All in all, these are not the signs of thorough human checks, and make all the comments of 8000 edits without problems, all checked by a human, a bit less convincing. Fram (talk) 08:05, 26 October 2011 (UTC)
 * So apparently there's a retrieval of what the page title is? That could be a definite problem if no verification is happening. But, it would be very hard to review and see what pages were viewed and which ones took the title directly, without modification. Without that, hard to ascertain an error rate. But, like I said, taking the bare title without review is a problem. By the way, the one edit of yours I checked (your posting in this section) contained an error. I don't think "fould" is word. Hmm. 1 edit checked, 1 error found. 100% failure rate? Wow. I'm sure there's no problem with my sample size, or at least no problem any different than your sample size :) (humor please, humor). --Hammersoft (talk) 17:41, 26 October 2011 (UTC)
 * No problem with humour, but errors in typing are normal (and I check my talk page posts less than my article edits), errors in scripts get repeated over many edits and pages. That doesn't mean that the occasional error shouldn't be expected, but the error rate should be very low. It isn't normal that I could identify many different types of errors when I checked a small number of cleanup edits at the end of September. Most of these errors shouldn't have been found when testing the script, and if not then when checking the affected pages. Fram (talk) 19:42, 26 October 2011 (UTC)
 * By the way; humans are prone to errors. Where do we set the bar for and how do we evaluate performance?  --Hammersoft (talk) 17:43, 26 October 2011 (UTC)
 * These issues don't exist in a vaccuum, one can't argue in one breath that Delta is experienced and careful enough to exceed his restrictions in 20 broad cases, and in the next breath say that he's so prone to mistake that "Books, Discount Books, Cheap Books, Australian Bookstore - Emporium Books" completely slipped his attention on a carefully and manually reviewed edit, as is required of him by his editing restrictions. Sure, humans make mistakes. But most humans haven't made so many mistakes that they're under strict editing restrictions. If Delta can't pick up his game and make error-free edits even when he's compelled to do so by mandatory, careful, manual review, what faith can the community have that he'll be able to apply a similar level of quality control if his restrictions are ever lifted? TechnoSymbiosis (talk) 22:13, 26 October 2011 (UTC)
 * Nobody can make error free edits in perpetuity. By the way, you spelled vacuum wrong. Can't you pick up your game? --Hammersoft (talk) 12:50, 27 October 2011 (UTC)
 * I certainly can. But then, I'm not under editing restrictions. Delta doesn't need to make error free edits in perpetuity, he needs to make error free edits until such time as he proves that his volume (not frequency) of errors is in line with community expectations. TechnoSymbiosis (talk) 22:19, 27 October 2011 (UTC)
 * Right, in perpetuity. You do know the history here, yes? By the way, you're perfect? Really? --Hammersoft (talk) 02:05, 28 October 2011 (UTC)
 * "Can't you pick up your game?" "I certainly can." doesn't strike me as overly confusing, Hammersoft. TechnoSymbiosis (talk) 03:00, 28 October 2011 (UTC)
 * The humorous point is that you're insisting pick up his game and be perfect, yet you can't spell vacuum correctly. Contrary to popular belief,  _IS_ human. Insisting that he be perfect in order to rehabilitate himself in the community's eye is completely unreasonable. --Hammersoft (talk) 13:13, 28 October 2011 (UTC)
 * Delta is human, but the edits he makes (or at least those under discussion) have no human input beyond saving them. When people type text, they will make speling errors once in a while. When bots or scripts make edits, they will make the same errors over and over again. The benefit of someone adding content generally far outweighs the occasional typo they make. The benefit of most of the cleanup tasks Delta (and other bots) does is so small that any error in it often actually makes the article worse than it was before. And that is why the bar is clearly higher for automated or semi-automated edits than it is for manual, content-adding editing. Fram (talk) 13:24, 28 October 2011 (UTC)
 * Bull. So the only error he is allowed to make is if he's typing something directly? Perhaps you're unaware of the range of possible human errors? You're still expecting perfection from a process that CAN'T be perfect by definition. What you're asking for is impossible and unreasonable. --Hammersoft (talk) 13:27, 28 October 2011 (UTC)

(note, funny to make a spelling error in the term spelling error, Fram). It keeps being said, and though I have to confess I have no proof to the opposite (I'll ask - well actually, going through the edits, there are edits there, where the edit summary is 'Cleanup' but which are clearly made by hand ), some statements here do have no proof in favour either. Here quoting Fram: "have no human input beyond saving them". Are you sure that these edits are 100% scripted? Do you have any proof that is not going through them, and adapting or removing certain things and then saving? Do you have any proof that does not here and there think 'hmm, that is not correct', and does not save, or that he thinks 'oh, I have to do that as well, I'll be back in a second'? I'm sorry, that if a script returns a name for a site, then what reason in beginning do you have to think that that name is wrong - if I type 'user:Fram' in the searchbox above, what reason do I have not to think that I get to the correct page. Yeah, funnily enough the toolserver is in Germany so in some rare cases it will return the localised German version (and not some strange user preference) - but that is not wrong (but, granted, not optimal either). But do realise that documents which are hosted in Germany and linked to in Germany but used as a reference on the en.wikipedia may not have an English version, they only have a German version and those documents do return a German title. And there will also be documents based in the US, which are written in German, and hence do return a German title. He could even have thought 'hmm, funny, a German title, well, apparently someone who can read German added the reference' (Note: it may even be that some en.wikipedian based in Germany actually used the German version to write the text in English and added the reference). So I do agree, this could have been, and maybe should have been detected .. but it is not an eternal mistake, something that is so blatantly wrong that it MUST be seen and adapted. So yes, there will always be suboptimal things in edits, and I agree, also avoidable outright mistakes, even cases where things go so wrong that they actually break pages. Yes, we should have high expectations - and I do have high expectations for as well - but not 100% error-free.

Same goes for the returning remarks that these edits are fully automated, and not checked. Although I do not have any proof that is not fully automating his edits - there is no proof to the opposite either - only a suggestion that it may be here and there. If there are 10 edits in a very short burst which all 10 give a 20-page diff then one could think - but that is still possible with tabbed browsing 'open 10 pages - check 10 pages - copy-paste ten edit summaries - save 10 pages' - then the saving will be in an extremely short burst while all 10 edits are thoroughly checked (and I edit that way as well sometimes). And as I said, there are actually edits which are clearly manual, even with the 'cleanup' edit summary. That, to me, suggests that ran the script to check if all was fine, nothing changed/all was fine, but saw something else which needed adding, which he subsequently did.

I do expect to solve problems which break pages immediately (or to strictly avoid saving them), and I do expect a reasonable answer/discussion when it gives mistakes which maybe are avoidable (link titles, null-edits). I also expect that if something throws suboptimal results that extra care is given (spammy link-titles, null-edits) after being alerted to it. --Dirk Beetstra T C 14:25, 28 October 2011 (UTC)


 * In reply to Hammersoft, your attempt to establish fallibility by drawing comparison between a spelling mistake I made and Delta's errors is disingenuous. I don't use automated or semi-automated processes so when I make a mistake, it affects one edit. When Delta makes a mistake, it tends to affect large numbers of edits, and requires a lot more effort by others to repair. There's no comparison between the two. And as I said, I'm not under editing restrictions. If I were, I would have no problem with people being strict about the kinds of edits I made, and I would have no problem doubling or tripling scrutiny of my own edits. If I can't show that I can raise the bar on my editing quality while under restrictions, I cannot reasonably expect that those restrictions would be lifted. I expect no more from Delta here than I would of myself. TechnoSymbiosis (talk) 23:32, 31 October 2011 (UTC)

Δ proposed task #1

 * Comment An edit summary more revealing than "(Cleanup)" would be useful if Delta is about to start doing very large numbers of edits like this. I'd also be more happy if Delta was making the request himself -- part of the process here is supposed to be reforming of Delta's attitudes, so he discusses with the community first -- and shows that he considers such discussions valuable, before he sets off on editing projects, which unfortunately the wheels have come off from too many times in the past. Jheald (talk) 17:57, 24 October 2011 (UTC)
 * Please keep meta discussion regarding these requests in the appropriate section above. Do you have an objection to this type of edit in particular? --Hammersoft (talk) 18:16, 24 October 2011 (UTC)
 * No! What evil will befall this project if Beta can remove those commented out dead links is impossible to imagine... Ok, sarcasm mode off. Obviously, I support this proposal, I am just aghast we have to waste our time discussing what should be a non-issue. --Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:30, 24 October 2011 (UTC)

Two questions. 1. Shouldn't this be done by a bot rather than by hand? 2. Why is it useful to have Beta (who has recently been prohibited from some other image-related work ) perform this task, rather than another bot operator who is less likely to draw criticism? &mdash; Carl (CBM · talk) 18:35, 24 October 2011 (UTC)
 * (1) Is there a reason a human shouldn't be allowed to do it? (2) The sanction you refer has to do with non-free images. This request has nothing to do with non-free images. I think it needs to be clarified that is not a bot, and this is not a request to operate a bot. --Hammersoft (talk) 18:38, 24 October 2011 (UTC)
 * It would be better for Beta to avoid image-related cleanup entirely, if he is trying to steer clear of further arbcom motions. Moreover, if an image is deleted for NFCC reasons and Beta then removes the link to the image, this task has an air of non-free image maintenance. I agree he is not a bot, but why should this be done by him in particular versus someone else or a bot? &mdash; Carl (CBM · talk) 18:43, 24 October 2011 (UTC)
 * So you're extending the ArbCom imposed sanctions to include anything to do with images then? Do you have ArbCom approval for such an extension? If you are objecting to the edit because would be doing the edit, then why don't you just make a request to have him banned from the project? Your opposition to all of these proposals is preventing him from editing anyway. --Hammersoft (talk) 18:45, 24 October 2011 (UTC)
 * The arbcom motion only covers non-free image enforcement "broadly construed". But it is in Beta's interest to avoid image-related work entirely, I believe. I support his ability to edit, I am not asking for a ban. But I do not see a compelling argument why he should receive special permission to perform this type of edit at this time, given his recent arbcom motion. &mdash; Carl (CBM · talk) 18:50, 24 October 2011 (UTC)
 * Do you see a compelling reason for him to edit? --Hammersoft (talk) 18:51, 24 October 2011 (UTC)


 * Support with modifications. Well, I do think Carl is right that it might be as well for Delta to stay away from images entirely (especially in the light of Requests for arbitration/Betacommand_2), but on the other hand I can think of no defensible reason why he should be unable to mass-remove images that have already been deleted. I think this would be the limiting factor, so I would like to suggest a reword to:
 *  may undertake non-controversial edits to articles to remove links to deleted images. This does not extend to NFCC enforcement activities or to removal of links to images currently under community discussion ("community discussion" being broadly construed). --Tristessa (talk) 02:22, 25 October 2011 (UTC)


 * Support modified version Fram (talk) 07:11, 25 October 2011 (UTC)
 * I think the modified version is asking for trouble. Delta is doing these in a fast, nearly automated, way and has shown little interest in changing.  It seems likely he'll not notice the exact issue and get blocked again.  I'm not big fan of Delta, but I see no reason to effectively "set a trap" for him either, especially wrt images.  Hammersoft, what do you think?  In any case I oppose the unmodified version as skating too close to his editing restrictions. Hobit (talk) 10:19, 25 October 2011 (UTC)
 * Non-controversial? There are people in these discussions that think anything does is controversial. That's a blatantly subjective term that will be used to bludgeon him if he does any edits of this type. --Hammersoft (talk) 13:46, 25 October 2011 (UTC)
 * Oppose. When viewing a diff, it is not apparent that the image has been deleted, and the edit summary does not explain why it was deleted. Further, in some cases, the name of the image file may help a subsequent editor figure out what the image was about and find a substitute image that improves the article. Jc3s5h (talk) 15:04, 25 October 2011 (UTC)


 * Support. --Dirk Beetstra T  C 15:09, 25 October 2011 (UTC)
 * Oppose unless checks to make sure there's no trivial replacement available. -- SarekOfVulcan (talk)  15:32, 25 October 2011 (UTC)
 * Conditional support for Tristessa's modified version, provided that checks for trivial replacements and provides a helpful edit summary. –  Luna Santin  (talk) 22:25, 25 October 2011 (UTC)
 * Waaaaay too close to the original nexus of all Beta-drama. The community simply does not trust Beta to remove links to images. Allowing him to do so en masse is simply asking for trouble. The sky will almost certainly not fall down if this has to be left to the rest of us. Chris Cunningham (user:thumperward) - talk 14:10, 26 October 2011 (UTC)
 * I see there are some separate ArbCom restrictions related to that (NFCC images). I'm not sure if the community may override those without consulting with the ArbCom—it's like firing them otherwise. So, I think you're right, the should be consulted before Δ is given approval for this particular task. Uʔ (talk) 16:56, 26 October 2011 (UTC)
 * Note: RFAR. Uʔ (talk) 18:08, 26 October 2011 (UTC)
 * Oppose per my arguments in task #3. These attempts to punch holes in Delta's editing restrictions are not in line with the intention of those restrictions and until Delta demonstrates he can work within his restrictions as they stand currently, I see no reason to relax them. TechnoSymbiosis (talk) 00:17, 1 November 2011 (UTC)
 * Oppose per TechnoSymbiosis. Besides, isn't there already a bot that does this? Kaldari (talk) 06:25, 1 November 2011 (UTC)

Δ proposed task #2

 * I don't see a problem if another valid edit needs to be made, and redirects are resolved in combination with the other edit, but resolving redirects doesn't usually seem worth doing as an edit of its own. Is there some other reason for resolving the redirects? Gimmetoo (talk) 17:39, 24 October 2011 (UTC)
 * Especially given WP:NOTBROKEN, why would it be appropriate for Beta to run a large scale task to do this? Note there is no requirement in your request that he has to do anything else, so you are asking for permission for him to do this and this alone to thousands of articles. &mdash; Carl (CBM · talk) 18:29, 24 October 2011 (UTC)
 * So what would you have me do, lump everything together in one giant request? As to WP:NOTBROKEN, what harm is being caused by the edit? Is there a reason to now allow it? --Hammersoft (talk) 18:34, 24 October 2011 (UTC)
 * We generally do not permit large-scale changes of this sort by bots, and AWB users are supposed to make a more significant edit before making this kind of "general fix". It is not clear why Beta would need to make this change to a large number of articles without making any other change to them. &mdash; Carl (CBM · talk) 18:40, 24 October 2011 (UTC)
 * Great! Could you please point out to me the guideline/policy that forbids people from performing this type of edit unless they are using AWB or are having a bot do it on their behalf? Do you have a specific objection to this task other than you think it should be done by a bot or an AWB user? --Hammersoft (talk) 18:44, 24 October 2011 (UTC)
 * Carl did link to the guideline: "Do not "fix" links to redirects that are not broken". This one is for everyone. Why do these redirects need to be resolved? If there is no reason other than "they are redirects", then it should not be done except in conjunction with another edit. Gimmetoo (talk) 18:49, 24 October 2011 (UTC)
 * Fair enough. So, are we agreed it's ok to do this sort of edit in conjunction with other approved edits? --Hammersoft (talk) 18:51, 24 October 2011 (UTC)
 * That seems fine, it is already done that way by AWB so there is a precedent. &mdash; Carl (CBM · talk) 18:57, 24 October 2011 (UTC)
 * Support as described in this thread, provided that provides a helpful edit summary. –  Luna Santin  (talk) 22:27, 25 October 2011 (UTC)

In general, so long as resolving a redirect to a template is done "in conjunction" with other non-trivial edits, I don't really object, but be aware that there may be some opposition to orphaning a redirect to a template in particular cases, and this task might draw criticism. Gimmetoo (talk) 19:04, 24 October 2011 (UTC)
 * Support - not at all controversial. --Tristessa (talk) 02:24, 25 October 2011 (UTC) Changed to Support modified version, taking the above comments into account (otherwise non-controversial I think):
 *  may undertake edits to articles to change links to templates where the original pointer was to a redirect, and the corrected pointer is to the template where the redirect was pointing, except in circumstances where community consensus may indicate that the alias should remain in use. --Tristessa (talk) 02:30, 25 October 2011 (UTC)


 * Oppose, no foreseeable benefit. Hammersoft, you asked 'what harm is being caused by the edit'. I would argue that the threshold for making an edit on Wikipedia is 'what good is caused by the edit'. If the answer is 'none', the edit shouldn't be done. TechnoSymbiosis (talk) 05:01, 25 October 2011 (UTC)
 * See also my arguments in task #3. These attempts to punch holes in Delta's editing restrictions are not in line with the intention of those restrictions and until Delta demonstrates he can work within his restrictions as they stand currently, I see no reason to relax them. TechnoSymbiosis (talk) 00:18, 1 November 2011 (UTC)


 * Oppose as it stands. Could support if only those replacements as agreed upon for AWB (see AutoWikiBrowser/Template redirects) would be done, if it is allowed for every AWB user, there is no point not allowing it here. Fram (talk) 07:11, 25 October 2011 (UTC)

Then change it into:
 *  may undertake edits to articles to change links to templates where the original pointer was to a redirect, and the corrected pointer is to the template where the redirect was pointing for templates which are also changed in the current version of AWB. (example, first line of diff)

Otherwise this is going to get to the point of 'you changed 26 templates in your last 100 edits', and if not, then 'you've removed 26 images during your last 100 edits' is also not a pattern - obviously support my version. --Dirk Beetstra T C 15:12, 25 October 2011 (UTC)


 * Oppose per NOTBROKEN and the fact that inspection of Beta's own comments will show that they see the benefit of doing this as tracking down templates which use non-free images. Beta is topic banned from non-free image work. Franamax (talk) 17:46, 25 October 2011 (UTC)
 * Im going to have to Fact that comment. Ive never used this task for NFC issues, its just used for simplifying the wikitext, and making templates easier to work with. ΔT The only constant


 * Support. This is beneficial for the project, EOT as far as I am concerned. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:00, 25 October 2011 (UTC)
 * WP:NOTBROKEN specifically addresses this. Should Hell freeze over and WP:NOTBROKEN be declared to no longer have community consensus, a real bot can easily do this. Chris Cunningham (user:thumperward) - talk 14:36, 26 October 2011 (UTC)
 * Oppose per NOTBROKEN. Karanacs (talk) 16:24, 28 October 2011 (UTC)
 * Oppose. This seems like a pointless task. If the redirect isn't broken, why fix it? Kaldari (talk) 06:27, 1 November 2011 (UTC)

Δ proposed task #3

 * In general, this is OK, but not optimal. Often these external links exist because someone tried to replace an acceptable image. Simply removing the external link leaves the page without an image. This sort of edit is really better done by a human who examines the edit history. Gimmetoo (talk) 19:11, 24 October 2011 (UTC)
 * Point of fact; contrary to popular belief is human :) --Hammersoft (talk) 19:39, 24 October 2011 (UTC)
 * Granted. Will delta look at the edit history, find the most-recently-used non-deleted image, and restore it? That could even be scripted. Gimmetoo (talk) 20:02, 24 October 2011 (UTC)


 * Support provided edits are fully reviewed. --Tristessa (talk) 02:31, 25 October 2011 (UTC)
 * Support provided Delta continues to follow his other restrictions (no automated edits or edits that appear automated; manual, careful, individual review of each edit). TechnoSymbiosis (talk) 05:03, 25 October 2011 (UTC)
 * Oppose per discussion elsewhere in this overall wall of text. Hammersoft has successfully convinced me that Delta has respect for neither the letter nor the spirit of his current editing restrictions, and that he has no intention of working within his restrictions to redeem himself in the eyes of the community. The entire process has instead attempted to undermine and chip away at his restrictions with no assurance whatsoever that he will be able to correct his past mistakes, nor even an acknowledgement that he made mistakes and that the community found this problematic. I oppose any increase in his editing privileges until such time as he demonstrates genuine understanding and genuine respect for the community, and takes steps to redeem himself, within his current limitations. TechnoSymbiosis (talk) 00:13, 1 November 2011 (UTC)


 * Support. Fram (talk) 07:11, 25 October 2011 (UTC)
 * I can imagine a case when a clueless newbie tries to update the infobox logo of a company after an official change, but instead of uploading the new picture the newbie puts an external link there. In that case it would preferable to revert. If the removal is a semi-automated task and does not check the recent history, perhaps a message should be automatically left on the talk page. Have mörser, will travel (talk) 14:19, 25 October 2011 (UTC)
 * Oppose unless checks to be sure the external link didn't replace a valid internal link.-- SarekOfVulcan (talk)  14:49, 25 October 2011 (UTC)
 * Conditionally support with same restriction as SarekOfVulcan suggested at 14:49 UTC. Jc3s5h (talk) 15:09, 25 October 2011 (UTC)
 * Support - but try to explain the editor how to actually get the image there. --Dirk Beetstra T  C 15:14, 25 October 2011 (UTC)
 * Support. This is beneficial for the project, EOT as far as I am concerned (agreed with SoV and DB though). --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:00, 25 October 2011 (UTC)
 * Conditional support with same restriction as SOV suggested at 14:49 UTC, otherwise oppose. As Gimmetoo notes, this is not amenable to script-based editing. Franamax (talk) 18:05, 25 October 2011 (UTC)
 * Conditional support per Franamax, Sarek, Gimmetoo, provided that provides a helpful edit summary. –  Luna Santin  (talk) 22:28, 25 October 2011 (UTC)

Δ proposed task #4

 * Does "content" exclusively mean templates? Gimmetoo (talk) 17:42, 24 October 2011 (UTC)
 * Construe it as in compliance with the directive linked above. --Hammersoft (talk) 17:46, 24 October 2011 (UTC)
 * I don't see how the sample diffs follow from the guidelines, nor how this task could be automated without more specification. Why should templates be moved? Which templates? Without more details I really don't know what's being proposed here. Gimmetoo (talk) 17:58, 24 October 2011 (UTC)
 * The appropriate line from CAT is "By convention, category declarations are placed at the end of the wikitext, but before any stub templates (which themselves transclude categories) and interlanguage links." The before and after links above demonstrate that. I didn't indicate the task or any of the proposed tasks should be automated. --Hammersoft (talk) 18:17, 24 October 2011 (UTC)
 * We generally do not allow AWB users or bots to make this sort of edit en masse. Why would it be appropriate for Beta to do it automatically when they cannot? Usually we say that these things should only be done if there is some more significant reason to edit the page. &mdash; Carl (CBM · talk) 18:27, 24 October 2011 (UTC)
 * If you would be so kind, could you please indicate where I said "automatically" or even implied "automatically"? Thank you. As to performing the edit, it is asked for by the CAT. Should we remove the above quoted line from this guideline? --Hammersoft (talk) 18:35, 24 October 2011 (UTC)
 * If Beta is given permission to do this, then he will have permission to do it on a large-scale basis. I don't see your argument for why it is necessary, nor why he should be authorized to do it. Even if it was necessary, I would think AWB could handle it. &mdash; Carl (CBM · talk) 18:37, 24 October 2011 (UTC)
 * Is there a reason he can't do it? Nothing on Wikipedia is "necessary". People edit according to their interests. Nobody is required to edit anything. The fact he is finding such errors shows me at least that all the various AWB users aren't finding all instances of this error. By performing the edit, he is helping the project and doing so in accordance with guidelines. Is there some reason he can't do it? --Hammersoft (talk) 18:41, 24 October 2011 (UTC)
 * Presumably, if Beta is asking for special permission to do a large-scale maintenance task, there should be a compelling reason why he needs to do it. This particular task would not be approved for a bot to do, because requests to perfrom only trivial maintenance like re-arranging the bottom of the article are not approves. It isn't clear to me how this proposal is different enough at different standards would apply. Is there a special standard that would be used to select articles to edit? &mdash; Carl (CBM · talk) 18:47, 24 October 2011 (UTC)
 * There is no compelling reason needs to edit here at all. Why not just permanently block him? I note you haven't opposed #3 yet. Do you support #3? --Hammersoft (talk) 18:49, 24 October 2011 (UTC)


 * Oppose - as per Carl I'm not convinced that this should be done on a large scale without wider, specific consensus for such a mass change; this task is also prone to mistakes and, without adequate edit review, is something of a Pandora's box. --Tristessa (talk) 02:34, 25 October 2011 (UTC)
 * Oppose, this is the kind of thing that needs to be done one a case-by-case basis, often text added below the cats is vandalism, or comments that belong on the talk page. Fram (talk) 07:11, 25 October 2011 (UTC)


 * Support - we are not talking about automated edits per sé here, we are talking about patterns of edits. Of course, if it is vandalism, it needs reverting, but if { would follow the AbuseFilter and get to 25 articles which are not vandalism and move the text up then for sure, { should be able to do that.  --Dirk Beetstra T  C 15:16, 25 October 2011 (UTC)
 * Oppose per "we are not talking about automated edits per sé here". We are. Have mörser, will travel (talk) 16:01, 25 October 2011 (UTC)
 * No .. this can also be done fully manually - scripted, maybe, but not automated.  is still obliged to check.  --Dirk Beetstra T  C 14:19, 26 October 2011 (UTC)
 * Comment. Most of that is vandalism, not all... should be done on case by case basis, automated move on likely vandalized text into main article would not be helpful. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:00, 25 October 2011 (UTC)
 * Not only that. I've seen mis-formatted categories using ";" instead of ":" and what not at AfC. Generally one needs to take a look at what the heck is the stuff at the end trying to do. Have mörser, will travel (talk) 18:12, 25 October 2011 (UTC)

Oppose per Chris Cunningham. Karanacs (talk) 16:28, 28 October 2011 (UTC)
 * comment All of my edits are manually reviewed before saving and I check for many issues, I often see reference sections added below interwiki stubs and categories. the correct layout is categories, stub templates, and finally interwiki links. ΔT The only constant 19:15, 25 October 2011 (UTC)
 * You say that, but what evidence do we have to support it? In the past you reportedly provided screenshots which just showed you hammering "Y" to approve edits without actually verifying them (I didn't see them, but I'm going off an old AN/I thread on that), and a few months ago you verified that you weren't actually viewing the pages when you reverting, simply looking at the contents of the diffs (in relation to you reverting someone who put a link to an image and not the actual image on a talk or project page). WP:AGF is not a blind shield.--Crossmr (talk) 07:33, 26 October 2011 (UTC)
 * Support seems sensible and is good cleanup. -- Eraserhead1 &lt;talk&gt; 19:48, 25 October 2011 (UTC)
 * This task is not suited to rapid editing, per Carl, and the community does not have enough faith in Beta to accept his vouching for personal inspection of each case, per Crossmr. Chris Cunningham (user:thumperward) - talk 14:17, 26 October 2011 (UTC)
 * Rapid? Still less than 40 edits in 10 minutes .. and certainly every edit should be checked ( is not allowed to run a bot, scripted edits alone).  --Dirk Beetstra T  C 14:20, 26 October 2011 (UTC)
 * One edit every fifteen seconds for ten minutes is blazingly fast. The specific speed limit is codified so he has a bright line, rather than because we've decided that four edits a minute is scientifically the right value. If we do not allow regular AWB users to carry out this "task" then there is certainly no rational for making an exception for BetaCommand. Chris Cunningham (user:thumperward) - talk 14:46, 26 October 2011 (UTC)
 * Oppose per my arguments in task #1 and #3. TechnoSymbiosis (talk) 00:20, 1 November 2011 (UTC)
 * Oppose per Chris Cunningham; all kinds of text ends up below the categories (including templates and other valid edits; vandalism; attempts at discussion; various unhelpful stuff from inexperienced users, &c) and each case therefore requires a little thought rather than rapid-fire repetition of a single change with little regard to the end result. I lack confidence that this would be done properly. bobrayner (talk) 20:57, 2 November 2011 (UTC)
 * Also: The strict sequence of things at the bottom of an article (categories, interwikis, stub templates, &c) is just a matter of convention and does not make a great deal of difference to the average reader. Making a great effort to fix these without actually fixing real content in an article strikes me as pointless busywork; but if conscript Δ is actually volunteering to dig a trench from the fencepost until lunchtime, that's no reason for me to stop them. bobrayner (talk) 21:11, 2 November 2011 (UTC)

Δ proposed task #5

 * See WP:CITEVAR. It wouldn't be good for someone to change large numbers of articles automatically in this way. &mdash; Carl (CBM · talk) 18:25, 24 October 2011 (UTC)
 * If you would be so kind, would you please point out where I said "automatically"? Thank you, --Hammersoft (talk) 18:35, 24 October 2011 (UTC)
 * The only reason Beta would need to request this is if he was planning to do it on a large-scale basis, presumably using automated or semi-automated tools like his "cleanup" script. Even AWB does not do this task, so it is not clear why it would be appropriate for Beta to do it. &mdash; Carl (CBM · talk) 18:38, 24 October 2011 (UTC)
 * Carl, are you going to oppose every request? I'm sensing a pattern here and growing increasingly unsettled that this is the case. To this request specifically, is there some reason he can't do it? Or is this just a global exception to editing, period? --Hammersoft (talk) 18:42, 24 October 2011 (UTC)
 * I support Beta editing, but there is no reason why this is the sort of editing he should be doing. &mdash; Carl (CBM · talk) 18:44, 24 October 2011 (UTC)
 * Do you have a reason why he shouldn't; do this type of edit or are you just opposing because it's him? --Hammersoft (talk) 18:46, 24 October 2011 (UTC)
 * This particular edit should not be done because of WP:CITEVAR. Even AWB does not perform this type of edit (changing the number of columns in the reference list). &mdash; Carl (CBM · talk) 18:48, 24 October 2011 (UTC)
 * RefLinks does automatically add columns if it detects a large number of references. Alpha_Quadrant    (talk)  19:00, 24 October 2011 (UTC)


 * Oppose - sorry, this particular one must be done by hand as there is a tendency for an automated/semi-automated application of this to result in all sorts of errors and unforeseen consequences; not least, however, is the objection that this should not be changed wholesale per WP:CITEVAR. --Tristessa (talk) 02:38, 25 October 2011 (UTC)
 * Oppose per Tristessa. Fram (talk) 07:11, 25 October 2011 (UTC)
 * Oppose, this should not be automated. -- SarekOfVulcan (talk) 14:53, 25 October 2011 (UTC)


 * Support - we are not talking about automated edits per sé here, this should be applied with the mentioned common sense. May get to 25 in a row, don't see any reason to disallow the common sense, manual, improvement even when it does get over 25 in a row.  --Dirk Beetstra T  C 15:18, 25 October 2011 (UTC)
 * Oppose per "we are not talking about automated edits per sé here". Gimme a break with the hypocrisy. Have mörser, will travel (talk) 15:57, 25 October 2011 (UTC)
 * Hypocrisy? Thank you, Have mörser, will travel.  --Dirk Beetstra T  C 14:21, 26 October 2011 (UTC)
 * Oppose – even the before/after example is lame. Someone subsequently fixed it by hand.  Dicklyon (talk) 17:21, 25 October 2011 (UTC)
 * Support. This is beneficial for the project, and my experience with Beta and ref fixing has been quite positive. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:03, 25 October 2011 (UTC)
 * Oppose per Tristessa. Franamax (talk) 18:24, 25 October 2011 (UTC)


 * Comment this isnt done too often. I only remove multi columns if there are less than 8 references (its pointless at that few references) and I only add multi columns if there are more than 30 references (where mulit-columns really become effective.) So please take that into consideration. ΔT The only constant 19:18, 25 October 2011 (UTC)
 * Which articles do you plan to apply it to? Do you have a list, or are you proposing to apply it to all articles that meet those criteria? If so, why can't a bot do it instead, if there is consensus? &mdash; Carl (CBM · talk) 19:23, 25 October 2011 (UTC)
 * A bot could do it, however no such bot currently does it, and it probably wouldnt get approval as it is a very trivial edit that I do in conjuncture with other edits, and I do it on an article by article basis as needed. Im just seeking approval so that this part of my edit cannot be considered a block-able pattern down the road. ΔT The only constant 19:31, 25 October 2011 (UTC)
 * Support 's description right here, provided a helpful edit summary is used. Opppose description above (too vague). – Luna Santin  (talk) 22:33, 25 October 2011 (UTC)
 * Oppose per WP:CITEVAR. This is bound to cause problems for some editor somewhere and there are editors out there who are deeply attached to their citation style, regardless of how idiosyncratic when compared to Wikipedia as a whole. You are in for the fight of your Wikipedia career if you mess with them.


 * Also, the example you gave added a citation in a format that is not documented in WP:CITE and is actually kind of idiosyncratic itself, so I'm concerned that the bot would move articles in the wrong direction. Study WP:CITE and related pages (such as WP:FOOTNOTE, citation, harvnb, etc.) before suggesting an automated edit that effects citations. CharlesGillingham (talk) 23:17, 25 October 2011 (UTC)
 * One Im not a bot, two Ive made over 8,000 edits with this gen fix enabled without a single complaint or issue raised about this item. ΔT The only constant 00:34, 26 October 2011 (UTC)
 * I'm sorry, I misread the diff the first time out. The change was not nearly as large as I thought at first glance. Is this request just to change/add the col in reflist? I think you should ask specifically about that, if that's the only change you will be making. CharlesGillingham (talk) 02:43, 26 October 2011 (UTC)


 * Oppose per WP:CITEVAR specifically, and per my arguments in task #1 and #3 broadly. TechnoSymbiosis (talk) 00:22, 1 November 2011 (UTC)

Δ proposed task #6

 * Of course Delta can fix the sort of whitespace issues described in Help:Whitespace, but the issues are varied and wouldn't seem likely to me to form a "pattern". Am I missing something here? The diff in question, and your explanation, seems to suggest removing linebreaks, which is a separate issue; in that diff they are not actually producing visible whitespace. Gimmetoo (talk) 22:26, 24 October 2011 (UTC)
 * was previously accused of conducting patternistic edits in removing white spaces. Thus, this request. --Hammersoft (talk) 22:42, 24 October 2011 (UTC)
 * But that was referring to the removal of spaces inside the wikicode, rather than to removing whitespace from the rendered article. There is no reason for him to go around doing the former, while Help:Whitespace is entirely about the latter. &mdash; Carl (CBM · talk) 01:18, 25 October 2011 (UTC)
 * Splitting hairs about white space? Is that was this has devolved to? So now I have to make a request about different types of white space? First ANY white space is a pattern, and now we have to delineate what kind of white space? That blade has two edges. --Hammersoft (talk) 01:43, 25 October 2011 (UTC)


 * Conditional support if in accordance with Help:Whitespace (that is, article whitespace) is interpreted strictly, or else proposes a change to those guidelines and obtains consensus for this change to be implemented at scale. --Tristessa (talk) 02:43, 25 October 2011 (UTC)
 * Conditional support per Tristessa. Help:Whitespace is specifically about article whitespace, which is a bad thing that should be fixed where possible. The linked diff seems to relate more to source whitespace, which is often harmless and in many cases can improve readability. Since part of the sanctions relate to Delta making mass changes indiscriminately, I'm not sure that it would be in the project's best interests to approve something as broad as the diff suggests, but if his edits are in strict accordance with Help:Whitespace then it seems acceptable. As with any of these requests, I'll gently remind that Delta is still prohibited from performing automated edits, or edits that appear to be automated, and approval of this proposal will not release Delta of that prohibition. TechnoSymbiosis (talk) 04:27, 25 October 2011 (UTC)
 * Oppose per my arguments in task #1 and #3. TechnoSymbiosis (talk) 00:23, 1 November 2011 (UTC)


 * Oppose until actual examples of this are given, and not the example above which doesn't remove any whitespace. Fram (talk) 07:11, 25 October 2011 (UTC)
 * Again, as above, we've devolved into splitting hairs about white space? I can't even believe we're discussing this. --Hammersoft (talk) 12:56, 25 October 2011 (UTC)


 * Believe whatever you want to believe, but if you give an example of a requested task, make sure that the description of the task and the given example match. I don't want this task to be read as if he can remove spaces from inside section headers, or something similar. Edits which don't change the rendered page and only remove a few bytes of space (but take up a lot more for being one extra revision) shouldn't be made. Edits which impose one preferred style over another (e.g. spaces in section headers, or refs on one line instead of refs with one line per parameter, or adding spaces between an asterisk and an item) shouldn't be made at all. Fram (talk) 13:12, 25 October 2011 (UTC)
 * Procedural oppose because request doesn't match diff.-- SarekOfVulcan (talk) 14:59, 25 October 2011 (UTC)
 * Support if it is part of an edit where other changes have a significant effect on the final display of the page. --Dirk Beetstra T  C 15:08, 25 October 2011 (UTC)
 * Oppose because whitespace changes are difficult to interpret in the diff display and the edit summary does not explain what is going on. Also, to change my opinion, I would require assurance the changes will be limited to changing excess whitespace in articles as they are displayed, not in wiki source. Jc3s5h (talk) 15:20, 25 October 2011 (UTC)
 * Actually, I like whitespace improvements in wikisource, it makes things easier for the next editor to come along. -- SarekOfVulcan (talk) 16:28, 25 October 2011 (UTC)
 * I like whitespace improvements in wikisource too, but I don't think they can be automated, and they certainly shouldn't be done without talk page consensus if there is any discernible pattern for the existing whitespace. Jc3s5h (talk) 18:18, 25 October 2011 (UTC)

~
 * Support. This is beneficial for the project, and I think it is done by some other bots/script out there anyway. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:04, 25 October 2011 (UTC)
 * Oppose. No clear benefit and editors may choose to leave spaces between groups of related options etc. Have mörser, will travel (talk) 18:09, 25 October 2011 (UTC)
 * Comment I only remove excessive whitespace, and its only done in conjunction with other edits. ΔT The only constant 19:21, 25 October 2011 (UTC)
 * What type of whitespace are you talking about? If you mean the type within the source code, what is the reason to remove it? &mdash; Carl (CBM · talk) 19:36, 25 October 2011 (UTC)
 * In general Ill remove whitespace where there are excessive breaks, or add it where needed to improve readability of the wikicode, and other times Ill remove excessive line breaks that add too much whitespace to articles. ΔT The only constant 19:39, 25 October 2011 (UTC)
 * Support per Tristessa. Be wary of breaking anything, though. – Luna Santin  (talk) 22:35, 25 October 2011 (UTC)
 * Ive made over 8k of these edits without issue. ΔT The only constant 00:32, 26 October 2011 (UTC)


 * I've read Help:Whitespace in its entirety, and I have no idea what task is being defined here. "Very often, when you have undesirable whitespace, the only way to solve the problem is to expand the article." seem to be the only firm recommendation there. I don't think anyone would object to that, nor do I think that process is likely to be a computer-produced pattern, so it's unlikely that anyone would object to that. Uʔ (talk) 16:48, 26 October 2011 (UTC)
 * I will have to oppose this as written. Here is the problem with this blanket set of proposals by someone not the owner of the code or intent. Fixing whitespace problems when you come across an article that has too much of it? Absolutely fine, I often do that, usually by re-jigging around the image placement, sometimes in the text. It's important to drag your browser window around to different sizes to see how it might look to other readers, and I really should test different font sizes too I guess. If Beta wants to do that case-by-case, even if they use a predictive algorithm to identify where there could be problems, if they are fixing stuff in a visible way, no problem. As part of a set of "genfix"-es, I would need to have much better understanding of what the automatic fix was. For changes visible only in wikicode, I see no particular necessity or desirability. Franamax (talk) 01:46, 27 October 2011 (UTC)

Δ proposed task #7
This should be done by a bot, there is no reason for him to do it manually. &mdash; Carl (CBM · talk) 21:09, 24 October 2011 (UTC)
 * Is there a reason he can not do it? --Hammersoft (talk) 21:11, 24 October 2011 (UTC)
 * You have presented no argument why he should receive a special permission to perform these edits, and there is no reason to think he is in a special position compared to all the editors who are not under restrictions. This sort of task is better done by a bot than by Beta. &mdash; Carl (CBM · talk) 01:16, 25 October 2011 (UTC)
 * You have presented no argument why he shouldn't. He is an editor here. Either he can edit or he can not. If he can, then he can perform this edit. The question isn't whether he has permission to perform the edit. You can't deny him that. The question is whether him conducting more than 24 of these over any time period is permissible. --Hammersoft (talk) 01:44, 25 October 2011 (UTC)
 * He can not make a pattern of 25 or more edits without obtaining approval. Part of obtaining approval is making an actual case for why the edits are worthwhile. If there is no justification for making a large number of these edits, why ask for permission to do it? That seems like wikilawyering. &mdash; Carl (CBM · talk) 01:54, 25 October 2011 (UTC)


 * Would you mind clarifying why would want to do this? --Tristessa (talk) 02:49, 25 October 2011 (UTC)
 * Support, see no reason why not. Fram (talk) 07:11, 25 October 2011 (UTC)
 * Support, seems like a reasonable task to semi-automate. Have mörser, will travel (talk) 07:37, 25 October 2011 (UTC)
 * Support other than objections listed above assuming he's manually checking each for being rational. I don't want to see deadlink pop up for nyt articles because they are down for 5 minutes. Hobit (talk) 10:26, 25 October 2011 (UTC)
 * Support when applied with common sense. --Dirk Beetstra T  C 15:19, 25 October 2011 (UTC)
 * Conditional support if edit summary is made meaningful. Jc3s5h (talk) 15:21, 25 October 2011 (UTC)
 * Support. This is beneficial for the project, EOT as far as I am concerned. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:04, 25 October 2011 (UTC)
 * Support as long as the articles are offline for a reasonable period of time. -- Eraserhead1 &lt;talk&gt; 19:46, 25 October 2011 (UTC)
 * Conditional support provided that, as per Hobit, the links are genuinely dead and not likely to come alive. --Tristessa (talk) 21:27, 25 October 2011 (UTC)
 * Support, simple enough. – Luna Santin  (talk) 22:36, 25 October 2011 (UTC)
 * dead link is for dumb bots which haven't the cogence to try to fix things. Human editors should do better. This is not a task which will imporve the encyclopedia if performed by human editors. Chris Cunningham (user:thumperward) - talk 14:22, 26 October 2011 (UTC)
 * Unless the human editor knows what the original text of the dead link said, it cannot be expected for a human editor to find a suitable replacement, and tagging with "dead link" is acceptable.  (It's not impossible, if the title is descriptive enough, but more often than not, if a title is too short, or we're talking a bare URL w/o indication of a title, it is impossible to search on that)  --M ASEM  (t) 14:26, 26 October 2011 (UTC)
 * WP:DEADREF provides a number of tasks for human editors. The value in tagging a link as dead without any other action is negligible. I would consider it okay for Beta to add dead link to articles under the guise of a Reflinks run (Reflinks does it automatically if it can't access a link), but not as a separate task. Chris Cunningham (user:thumperward) - talk 14:51, 26 October 2011 (UTC)


 * Support. These edits would be useful to readers. Karanacs (talk) 16:34, 28 October 2011 (UTC)
 * Oppose per Chris Cunningham. If these are indeed manually handled edits then there are changes that Delta can make that are actually beneficial. There's no point in a human making bot-like edits that are performed only because the bot is incapable of making better, human-written edits. Broadly, see also my argument in tasks #1 and #3. TechnoSymbiosis (talk) 00:27, 1 November 2011 (UTC)

Δ proposed task #8

 * Falls in the class of "trivial edits" - OK if making another non-trivial edit to the article, but not generally worth doing on their own. Gimmetoo (talk) 22:10, 24 October 2011 (UTC)


 * Oppose - can at best make the HTML look extremely odd, or at worst possibly break HTML, where the  tag is used in circumstances other than inline within article prose (e.g. infoboxes). It's also of questionable value. Have any discussions taken place elsewhere to give consensus that this HTML to template replacement should be done wherever possible? --Tristessa (talk) 02:53, 25 October 2011 (UTC)
 * Comment: Contrary to popular belief, Wikipedia isn't actually being served in standards-compliant XHTML and every time I see XHTML formatted tags being served in text/html I shudder a little. Replacing the raw linebreak HTML with a template may actually improve Wikipedia's ability to move away from the broken XHTML standard to something more useful in the future, like HTML5, by allowing us to change the linebreak tag format in one place, instead of the millions of places across the database where it's used directly. TechnoSymbiosis (talk) 04:36, 25 October 2011 (UTC)
 * Oppose until the need for this is explained more clearly. We already have a problem with some pages with too many template transclusions, adding more templates for no apparent benefit won't make this better. Fram (talk) 07:11, 25 October 2011 (UTC)
 * Support per TechnoSymbiosis. -- SarekOfVulcan (talk) 15:06, 25 October 2011 (UTC)
 * Support - with the caveat that the result should not break further template transclusion (if so, subst them all so they are at least correct). --Dirk Beetstra T  C 15:20, 25 October 2011 (UTC)
 * Support if the result doesn't break template transclusion. -- Eraserhead1 &lt;talk&gt; 19:46, 25 October 2011 (UTC)
 * Support replacing in-line use, but should be extremely careful about mucking around in templates or template calls. Should avoid use in situations Fram describes, but I'm not sure how common that is. – Luna Santin  (talk) 22:37, 25 October 2011 (UTC)
 * Trivial search-replace edits like this can be actioned by real bots. They do not improve the encyclopedia one whit. Chris Cunningham (user:thumperward) - talk 14:25, 26 October 2011 (UTC)
 * Oppose. I would guess most editors have no idea what that template means, while many of us do know what the HTML code is.  This is a potentially confusing edit.  Also, there are pages where I've done my best to get rid of templates because the pages are slow to load.  I would not want templates added back. Karanacs (talk) 16:36, 28 October 2011 (UTC)

Δ proposed task #9
There is no reason to do this, they are completely equivalent. &mdash; Carl (CBM · talk) 21:08, 24 October 2011 (UTC)
 * Is there a reason he can not do it? --Hammersoft (talk) 21:12, 24 October 2011 (UTC)

Falls in the class of "trivial edits" - OK if making another non-trivial edit to the article, but not generally worth doing on their own. Gimmetoo (talk) 22:11, 24 October 2011 (UTC)
 * Support - trivial, yes, but no real reason why he shouldn't. --Tristessa (talk) 02:54, 25 October 2011 (UTC)
 * Oppose as unnecessary, given that both are aliases for the same thing. We wouldn't have someone run through changing fact to citation needed, is there a reason why this situation is any different? This seems like wasted effort for no net benefit. TechnoSymbiosis (talk) 04:39, 25 October 2011 (UTC)
 * Yes, actually, someone should be replacing fact with citation needed because the former redirects to the later. It saves a few CPU cycles if that change is made.  That said, I believe file: and image: are different (that's not a redirect thing, that's a wikimedia namespace part) and the change only serves to nomralize the use of any media under the file: ns. --M ASEM  (t) 10:42, 25 October 2011 (UTC)
 * We have pages that explicitly tell us not to worry about performance issues, and that redirects are perfectly acceptable. CPU cycles aren't our concern, there's no reason for that kind of change, or on the namespace change. TechnoSymbiosis (talk) 22:57, 25 October 2011 (UTC)
 * But we still have bots that run around to fix double redirects for article space. And while yes, we shouldn't worry too much about the CPU cycles, such fixes do help in the long run.  But again, that's off track from this specific request. --M ASEM  (t) 13:52, 26 October 2011 (UTC)
 * Double  redirects, yes, because these don't get automatically resolved. Fixing a double redirect helps the reader; fixing a simple redirect doesn't (or not noticeably). Fram (talk) 14:00, 26 October 2011 (UTC)
 * Conditional support, only in edits where something more substantial is done (like adding "deadlink" or removing deleted images or whetever substantial task gets approval). On its own, it's an unnecessary edit. Fram (talk) 07:11, 25 October 2011 (UTC)
 * Oppose unneeded and serves no purpose. Has the negative effect of either A) being an unneeded edit or B) making it harder to see what actual changes were made. Hobit (talk) 10:28, 25 October 2011 (UTC)
 * Oppose I thought doing this is a perennial proposal, anyways I don't see why this is a needed change --Guerillero &#124; My Talk  14:58, 25 October 2011 (UTC)


 * Don't see much benefit, nor harm. Only support if part of an edit where there are other parts edited which do have a significant effect on the display of the page.  --Dirk Beetstra T  C 15:21, 25 October 2011 (UTC)
 * Comment. I never understood the need to retire Image and replace it with a less meaningful file... --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:07, 25 October 2011 (UTC)
 * Because the "Image:" space has sound files as well and apparently this was overwhelmingly confusing for someone or other and/or to break a whole bunch of external tools that used hard-coded project space names, e.g. wannabekate's edit counter. Franamax (talk) 18:55, 25 October 2011 (UTC)


 * Conditional support per Gimme, Beetstra. Franamax (talk) 18:57, 25 October 2011 (UTC)
 * Support per Gimme, Beetstra. – Luna Santin  (talk) 22:38, 25 October 2011 (UTC)
 * Question: Does anyone know if there are any long term plans by the Foundation to depreciate the "Image:" namespace?  If this is known to happen at some point, then this task starts to become important. --M ASEM  (t) 13:53, 26 October 2011 (UTC)
 * That'd be "deprecate", and no it wouldn't. This "task" can, when the time comes, be handled perfectly well by a real bot, which doesn't have friends who go running to ANI when you block it for misbehaving. That's the case for several of these other "tasks" as well. Chris Cunningham (user:thumperward) - talk 13:59, 26 October 2011 (UTC)
 * The name is already deprecated, it is kept as an alias for File: - |namespaces|namespacealiases, so there's no particular reason it will ever need to be removed completely. Franamax (talk) 17:11, 26 October 2011 (UTC)
 * There is absolutely no difference between File: and Image:. Regardless of which is used, the software still looks up the namespace ID and the canonical namespace name. There's no additional database lookups like with a redirect, it just checks some PHP variables. Trivial. Removing the Image alias would break wikis for no reason, so the developers aren't going to do that. Keeping Image: links in articles is absolutely harmless, and time would be better spent doing anything else. If Image: breaks external tools, the tools should be fixed. Reach Out to the Truth 19:04, 1 November 2011 (UTC)

Δ proposed task #10
Of course Delta can prod articles, but I think a "pattern" of 25 or more prods would be rarely needed, and should relate to a specific reason or situation. Why would this be needed in general? Gimmetoo (talk) 22:17, 24 October 2011 (UTC)
 * Because it is likely will be taken to task if he prods more than 24 articles. "Hey, you prodded 25 articles. Did you get permission?". Thus, the request. --Hammersoft (talk) 22:43, 24 October 2011 (UTC)
 * If you are proposing that he will PROD 25 articles, you should give their names. This proposal process is not for all possible edits that could in principle be made, it is for specific tasks that Beta is planning to perform. &mdash; Carl (CBM · talk) 01:20, 25 October 2011 (UTC)
 * I'm looking at the future. Apparently now to gain your approval we have to stare into the crystal ball to foretell what articles might be proded? You can't be serious. --Hammersoft (talk) 01:45, 25 October 2011 (UTC)
 * The point of making a proposal is that it needs to be concrete enough to let people tell what is being proposed. Which articles are going to be prodded? Why would there be 25 of them in a row? If there are no actual plans to prod 25 articles, there's no need for some sort of speculative approval. &mdash; Carl (CBM · talk) 01:56, 25 October 2011 (UTC)


 * Support non-automated PRODs only - amend to include: "...where he has carefully reviewed those articles manually, and has provided a rationale for each article resulting from a review of the specific article being PRODed". --Tristessa (talk) 02:58, 25 October 2011 (UTC)
 * Second that. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:08, 25 October 2011 (UTC)
 * Oppose, this one just isn't specific enough. 'Fixing redirects' is one thing, 'prodding articles' is something entirely different, and Delta will cop significantly more flak for the latter than the former. As Carl said, prodding 25 articles is no small thing, it's not something I think the community should be giving blanket permission for as an exception to Delta's restrictions. TechnoSymbiosis (talk) 04:43, 25 October 2011 (UTC)
 * Conditional support. Of course he can prod articles, but prodding large groups of articles can better be discussed beforehand and seen on a case-by-case basis. And a prod like in the example was fast overturned, so making many of these is probably not a good idea. Fram (talk) 07:11, 25 October 2011 (UTC)
 * oppose See this permission as a get-out-of-jail free card for walking a (say) all the House articles and prodding them. He's free to prod IMO, just not in an automatic way or with a pattern. Hobit (talk) 10:30, 25 October 2011 (UTC)
 * oppose and honestly these proposals are wandering into bad faith territory, and bordering on pointy. If Delta were to suddenly go out and in the next hour prod 25 articles that would be a focused editing task. If he prods a couple today, a couple tomorrow, 4 or 5 a week from now, I don't think anyone is going to start trying to add those up and claim he's violating that restriction. I haven't seen anyone doing that. The Clean-ups are entirely different and he often does a lot of those together from time to time. The entire purpose of this restriction is to ensure Delta has consensus for changes he's making on a large scale to articles as in the past he's sometimes broken things and suddenly done it on a lot of articles as he sometimes like to just suddenly change a few hundred articles.--Crossmr (talk) 11:29, 25 October 2011 (UTC)

Then change it into (reasonable, but random numbers):
 *  may prod article (but not more than 10 in a sequence, and not more than 50 a day). (example)

Otherwise this is going to get to the point of 'you prodded 26 articles in your last 100 edits', and if not, then 'you've removed 26 images during your last 100 edits' is also not a pattern - obviously support my version. --Dirk Beetstra T C 15:07, 25 October 2011 (UTC)
 * We should not give him blanket permission to prod 1,500 articles in a month. If he has a long list of articles that need to be prodded, he should come back witha concrete proposal, or let someone else do it. &mdash; Carl (CBM · talk) 15:23, 25 October 2011 (UTC)
 * The point, apparently being lost, is that him prodding articles can be construed as a pattern. Therefore, requesting specific permission to prod. Nobody is suggesting he's going to prod a million articles in a day. --Hammersoft (talk) 15:26, 25 October 2011 (UTC)
 * The proposal I was responding to was exactly to allow him to prod 1,500 articles per month with no further review. History shows that Beta has a tendency to interpret permissions in the broadest manner possible. Without a concrete list of the articles to be affected, there is no way to tell whether it is appropriate for him to do so. &mdash; Carl (CBM · talk) 16:15, 25 October 2011 (UTC)
 * What's it going to be Carl? You opposed just about everything to do with out of the box. Then you come outright here and effectively say you don't trust him. Why don't you just start a proposal to ban him and be done with it?!?!?!? --Hammersoft (talk) 18:00, 25 October 2011 (UTC)


 * Oppose If Beta wants to prod a large number of articles, they need to obtain separate approval on a case-by-case basis. Franamax (talk) 18:59, 25 October 2011 (UTC)
 * Oppose unlikely to be legitimate to prod 25 articles at a time. -- Eraserhead1 &lt;talk&gt; 19:44, 25 October 2011 (UTC)
 * Ive got a tool that lets me review excessively short pages, when going over those results its not uncommon to tag 5-10 a day, if I do that say once a week thats 40 articles a month, which is over the 25 limit. Someone will come along and complain, resulting in another block ΔT The only constant 19:51, 25 October 2011 (UTC)
 * Oppose. You know you should let other people worry about tagging large numbers of short pages for deletion. It is not possible for you to do this without causing controversy. &mdash; Carl (CBM · talk) 19:53, 25 October 2011 (UTC)
 * So now I can't even prod articles that I think need it? ludicrous, Im not going to be tagging en-mass, however If I do tag more than 25 over any period it will be considered a pattern and I will be blocked for it. Will your next step be that I cant edit articles starting in A or ending in D? or some other asinine rule? ΔT The only constant 20:07, 25 October 2011 (UTC)
 * You just said you were going to do 10 per day, or maybe it was 40 per month? In any event you should let other people take care of reviewing articles for deletion. You have very recently been banned from NFCC enforcement - it would be foolhardy to move into a different sort of controversial deletion tagging as a result. Let someone else do it, and stick to things that are not controversial. &mdash; Carl (CBM · talk) 20:17, 25 October 2011 (UTC)
 * Please dont place words in my mouth, I am not planning on mass tagging, and normal deletion processes are not controversial. take a look at Articles for deletion/AirCare (medevac system) (2nd nomination) which is a one example of a prod, that I ended up escalating to an AfD when the author objected. In October I tagged 11 pages, two of them where improved as to make the prod invalid, one was redirected, and the rest where deleted. Fairly standard and non-controversial. ΔT The only constant 20:26, 25 October 2011 (UTC)
 * This request is for approval to prod an arbitrary number of articles (" may prod articles."). If you are not actually planning to prod a large number of articles, a more limited request might be more reasonable. But this request is not limited in any way. &mdash; Carl (CBM · talk) 20:49, 25 October 2011 (UTC)
 * Why? if I tag more than 25 Ill be blocked no questions asked, as it would be a "pattern", regardless of the time frame. ΔT The only constant 20:53, 25 October 2011 (UTC)


 * Oppose, far too vague. Open to discussing clearer wording. – Luna Santin  (talk) 22:39, 25 October 2011 (UTC)


 * Some clarification in how Delta normally proceeds through articles may be helpful: I don't know know how articles enter his queue, but alphabetical order appears to be part of it. Bascially, what it comes down to is that if Delta has a list of articles that he plans on working on, that list is a random draw from all articles on WP.  Some may be appropriate PROD targets, but the likeliness that any of the PROD targets are interrelated is very low, meaning that asking Delta to have to make a special step to make a list of articles he wants to PROD simply excessive and with no place to go.  I would be more concerned if the PRODs were being made on equivalent related articles (eg House episode articles example from Hobit).  Maybe the step here is to make sure that how Delta fills is queue is understood - and that we all agree this is effectively close enough to a random draw, meaning that any PRODing is non-targetted. I would add that if he wants to PROD a series (more than 3?) of highly related, equivalent articles within, say, a day or more, that needs to be done in a different venues and approval first to do it.  --M ASEM  (t) 14:05, 26 October 2011 (UTC)
 * I would be open to supporting a more clearly-defined wording on how candidates are selected, how they are evaluated and how often this will be done. As I think Carl is suggesting, it would be far from desirable if Beta switched their "list-processing" focus to page deletions. And just to note the elephant in the room, yaknow, past examples of "here I decided it would be better to expand the article myself and researched the topic [21 improvement diffs]" (and yes, I do know, no-one is ever forced to add content) - would go so vastly far toward quelling the general concerns... Franamax (talk) 17:30, 26 October 2011 (UTC)
 * It might also be good to have a specific list of what type of articles that Delta plans on PRODing or blacklisting reasons for PRODing. The example given by Hammersoft is, IMO, a completely fair PROD (it's a dictionary def, and common sense reasoning its not going to go anywhere - that is, it is an objective measure).  PRODs based on non-objective and more subjective measures, like lack of notability, should be avoided in this cleanup process Delta does.  Thus, it may be easier for Delta to list out the only reasons that in this regular pattern of editing that he would consider adding a PROD, and leaving anything else outside of it for others to do.  I would argue he can be free to maintain a list of articles that he feels may be problematic but fall outside his allowed PRODable reasons, letting others process that list. --M ASEM  (t) 17:39, 26 October 2011 (UTC)

Δ proposed task #11

 * Of course Delta can create redirects "as appropriate", but I think a "pattern" of 25 or more would be rarely needed, and should relate to a specific reason or situation. (Eg after a bunch of articles are merged together.) Why would this be needed in general? Gimmetoo (talk) 22:18, 24 October 2011 (UTC)


 * Same problem as #10: without any detail, it is impossible to review the request. What set of articles will be changed? What are the criteria to decide? Etc. There is not enough information here for anyone to tell what is being proposed. &mdash; Carl (CBM · talk) 01:21, 25 October 2011 (UTC)
 * And again we can't foretell the future. The problem you are creating (and yes, YOU are creating it) is that if he creates a redirect form an article in October of 2011, does another 5 in November, and 5 in December and so on, then around February either you or someone else is going to cry foul for there being an unapproved pattern. I'm asking for specific permission for him to be able to change articles into redirects as appropriate, since you feel that doing so constitutes a pattern. It's your bed of nails you created. --Hammersoft (talk) 01:47, 25 October 2011 (UTC)
 * I feel you are wikilawyering by suggesting that people would complain about edits spread in that way. The recent complaints were for 2,000 edits in 2 months, not for 25 edits in one year. If there are no immediate plans to turn large numbers of articles into redirects, there is no need for immediate approval either. &mdash; Carl (CBM · talk) 02:01, 25 October 2011 (UTC)
 * People have been counting Delta's edits within periods meticulously to try to find points where he has violated his restrictions even when the edits are beneficial. When it's spelled out (the 40 edits in 10 minutes), that's at least something he can work under. If you say 25 edits but without a time period, someone *will* complain if he does 26 without VPR approval, even if the 26th is a year after the other 25.  Sure, that claim will likely be thrown out, but it will be there. --M ASEM  (t) 10:39, 25 October 2011 (UTC)
 * It's Indubitable that that situation currently exists. Do you see anyone doing that? Unless you can actually point to an existing case of that, that's an unfounded assumption of bad faith.--Crossmr (talk) 12:12, 26 October 2011 (UTC)
 * This (from his recent block) is the first time that the 25 limit has been brought up. Given that he has been blocked for doing 43 edits in a 10 minute period (when the limit is 40) several days after doing so, despite the fact he admitted he mistimed on his throttle, Delta's going to be under the same microscope for these "25 edits" in some arbitrary period.  Defining now avoids having Yet Another Delta ANI thread in the future. --M ASEM  (t) 14:12, 26 October 2011 (UTC)
 * No, that's false. The whole NFCC thing in May/June contained a meta discussion about the VPP proposals because Delta had performed a significant amount of edits for about a day and a half before taking it to VPP. It may not have been entered in his block log, but this is not the first time its been brought up. That was over 4 months ago and in that time I've seen no one doing as you claim.--Crossmr (talk) 23:09, 26 October 2011 (UTC)


 * In which context/under what circumstances? If he is creating redirects in the usual way, there is no need for this to be a proposal here. --Tristessa (talk) 02:59, 25 October 2011 (UTC)
 * Oppose due to potential trouble arising lack of specific information under what circumstances he would be turning articles into redirects and how frequently; I'd like to know precisely what sort of cleanup operation this would be used in, since even the most well-approved of bots would likely have difficulty asking for a total blanket permission on this. --Tristessa (talk) 21:32, 25 October 2011 (UTC)
 * Its on a case by case basis where needed, Its not that common but does arise. Please note I am NOT a bot and this isnt a bot request. ΔT The only constant 21:36, 25 October 2011 (UTC)


 * Oppose, not specific enough. Turning 25 articles into redirects strikes me as far from common editing behaviour. I'd be inclined to support a specific instance of 'resetting' Delta's 'article to redirect' count if a request was made here demonstrating the last 24 examples, showing that they were good and requesting an extension, but I don't see a benefit in simply issuing an exemption from his restrictions preemptively. TechnoSymbiosis (talk) 04:47, 25 October 2011 (UTC)
 * Agree. Might as well add: "Δ can edit articles". Have mörser, will travel (talk) 05:01, 25 October 2011 (UTC)
 * Oppose as well, Delta may obviously redirect articles, but redirecting large numbers rapidly may well be disruptive. Get approval for specific large scales redirecting efforts if needed. Fram (talk) 07:11, 25 October 2011 (UTC)
 * oppose as my comments above. Really bad idea in general. Hobit (talk) 10:31, 25 October 2011 (UTC)
 * Support The above comments miss the point, eventually Beta is going to have corrected 25 redirects, therefore allowing further controversy. These proposals are intended to allow Beta to do something without CBM or others, from stepping in and saying that there is a "pattern", getting Beta reblocked. Alpha_Quadrant    (talk)  14:47, 25 October 2011 (UTC)

Then change it into (reasonable, but random numbers):
 *  may change articles into redirects as appropriate (but not more than 10 in a sequence, and not more than 50 a day). (example)

Otherwise this is going to get to the point of 'you redirected 26 articles in your last 100 edits', and if not, then 'you've removed 26 images during your last 100 edits' is also not a pattern - obviously support my version. --Dirk Beetstra T C 15:06, 25 October 2011 (UTC)


 * If he needs to do 50 in a single day he should come back here with a concrete list for people to review. We should not give him blanket permission to change 1,500 each moth without further review. &mdash; Carl (CBM · talk) 15:20, 25 October 2011 (UTC)


 * I can agree to lower numbers - 5 in a row, 10 per day, 100 per month? --Dirk Beetstra T  C 15:23, 25 October 2011 (UTC)
 * @Carl; Right, so even if he has approval he has to get approval. --Hammersoft (talk) 15:25, 25 October 2011 (UTC)

My idea of properly changing an article to a redirect includes So I would consider rapid-fire changes of this type inappropriate. But if due care is taken with each change, fine. Jc3s5h (talk) 15:35, 25 October 2011 (UTC)
 * checking for citations, in case proof is required that the two terms really are synonymous
 * checking to see if there is a talk page with any useful material that should be merged to the target talk page
 * checking the article history to see if the current version of the article has consensus, or was snuck in when no one was looking.
 * Comment / weak oppose. This should never be automated, as it requires a manual merge (has all categories been merged? all text? sometimes even one sentence is beneficial). At the same time, Beta can of course prod, merge, redirect and so on manually at will, just like anybody else should be able to. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:09, 25 October 2011 (UTC)
 * Oppose If Beta wants to redirect a large number of pages, they need to obtain separate approval on a case-by-case basis. The suggestion that at some point in the far future someone will count back 26 wholly separate redirects and call that a pattern is nonsensical. Franamax (talk) 19:04, 25 October 2011 (UTC)
 * Oppose I don't see why you'd need to do this with 25 or more articles over any reasonable time period. -- Eraserhead1 &lt;talk&gt; 19:44, 25 October 2011 (UTC)
 * Ive got a tool that lets me review excessively short pages, when going over those results its not uncommon to tag 5-10 a day, if I do that say once a week thats 40 articles a month, which is over the 25 limit. Someone will come along and complain, resulting in another block. ΔT The only constant 19:47, 25 October 2011 (UTC)


 * Oppose far too vague. – Luna Santin  (talk) 22:40, 25 October 2011 (UTC)
 * Oppose. This doesn't seem like a task that would need to be done en masse. If there are many such cases, they should probably be handled on a case-by-case basis. Kaldari (talk) 06:37, 1 November 2011 (UTC)

Δ proposed task #12

 * This is a WP:CITEVAR issue, Beta should not be doing large-scale changes from one reference style to another. There is no requirement for articles to use named references, it is in principle acceptable to repeat the references each time. &mdash; Carl (CBM · talk) 14:33, 25 October 2011 (UTC)


 * Support, named references make the article easier to read and easier to edit. Duplicated info is a vector for disaster.-- SarekOfVulcan (talk) 15:18, 25 October 2011 (UTC)
 * Support --Dirk Beetstra T C 15:23, 25 October 2011 (UTC)
 * Conditional support if edit summary is made more descriptive. --Jc3s5h (talk) 15:40, 25 October 2011 (UTC)
 * Support. This is beneficial for the project, Beta seems to be doing good job on references in my experience, EOT as far as I am concerned. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:10, 25 October 2011 (UTC)
 * Support definitely useful. -- Eraserhead1 &lt;talk&gt; 19:43, 25 October 2011 (UTC)
 * Oppose. In violation of standing guidelines that apply to everyone. Gimmetoo (talk) 21:12, 25 October 2011 (UTC)
 * Oppose unless more specific, unfortunately - I'm opposing not because fixing duplicate references on a large scale per se is undesirable -- but we may have difficulty in getting to agree to a definition of "duplicate" that matches editing logic; he is likely to look at it from the standpoint of appearing to be a duplicate in a pattern-matching sense, most probably by title/ISBN as opposed to doing it based on individual judgement. He can of course make manual edits in this area without any sort of approval. If this were worded something like, " may fix references that are not deliberately duplicated in articles by grouping them together, but only when those citations are at least virtually identical in bibliographic content", I would support. --Tristessa (talk) 21:39, 25 October 2011 (UTC)
 * When I refer to duplicate references I refer to exact dupes. and ΔT The only constant 21:51, 25 October 2011 (UTC)


 * Conditional support for exact duplicates only, and provided that a helpful summary is used. – Luna Santin  (talk) 22:41, 25 October 2011 (UTC)
 * Support for exact duplicates. Note that support for this doesn't imply support for the opposite, splitting a named ref into two different ones because the text after the ref tag is slightly different (I have seen this being done, that's why I add this caveat). Note: ref names should not be placed inside double quotes unless necessary. Fram (talk) 14:04, 26 October 2011 (UTC)
 * Oppose. As CBM says, the use of named references is optional and this is a CITEVAR issue; depending on the article this may be entirely inappropriate. Christopher Parham (talk) 00:45, 27 October 2011 (UTC)
 * Oppose per CITEVAR. Also, in many articles the writers have a naming system for refs (mine is "name =authornamePageNum") - adding a totally different naming system in may confuse those editing that article. Karanacs (talk) 16:45, 28 October 2011 (UTC)
 * Oppose standardizing references takes a whole ton of work. It can't be done quickly or with a script. Per Karanacs I often use a name="Lastname(Year)Pagenumber" standard. --Guerillero &#124; My Talk  21:49, 29 October 2011 (UTC)
 * Oppose per WP:CITEVAR specifically, and per my arguments in tasks #1 and #3 broadly. TechnoSymbiosis (talk) 00:30, 1 November 2011 (UTC)

Δ proposed task #13

 * Support, no reason not to. -- SarekOfVulcan (talk) 15:19, 25 October 2011 (UTC)
 * Support --Dirk Beetstra T C 15:24, 25 October 2011 (UTC)
 * Appears non-controversial as long as there aren't automation mistakes in the "where needed" part (external links section, infoboxes etc.) Have mörser, will travel (talk) 16:22, 25 October 2011 (UTC)
 * Comment. But I think WP:REFLINKS does it better than whatever script he employed, so conditional support is his script is as good as REFLINKS, conditional oppose if not. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:13, 25 October 2011 (UTC)
 * The script he uses is technically the RefLinks general fixes feature, only in script form. The only difference is his script doesn't automatically fill in full references. Alpha_Quadrant    (talk)  18:58, 25 October 2011 (UTC)


 * Support useful work. -- Eraserhead1 &lt;talk&gt; 19:42, 25 October 2011 (UTC)
 * Support. If done carefully, I can't see any potential problem with this. --Tristessa (talk) 21:42, 25 October 2011 (UTC)
 * Conditional support per Piotr. – Luna Santin  (talk) 22:43, 25 October 2011 (UTC)
 * Very conditional support, leaning oppose. This should be done with a few precautions. Something like this should be avoided. Furthermore, what was done until now was taking the webpage title automatically, and placing that as the url title. However, while this is often fine, in other cases this results in rather promotional language, like "Nathan Kelley, ISBN 9786135356892 - Books, Discount Books, Cheap Books, Australian Bookstore - Emporium Books". We don't want that kind of url titles, I suppose... Fram (talk) 14:10, 26 October 2011 (UTC)
 * Golly-gosh, this one actually improves the encyclopedia! Sure: if Beta can be trusted to do this responsibly, checking the output the ensure no GIGO problems, he can do it 10,000 times a minute if he wants. Chris Cunningham (user:thumperward) - talk 14:27, 26 October 2011 (UTC)
 * Oppose per problems raised by Fram. If Delta can't get this right within his 25 article restriction, I have no faith that he'll somehow get it more right with that restriction lifted. TechnoSymbiosis (talk) 22:22, 26 October 2011 (UTC)

Didn't there used to be a bot that did this? Karanacs (talk) 16:49, 28 October 2011 (UTC)


 * User:DumZiBoT. The implication here is that Reflinks is imperfect and really needs human supervision; bots mess up too often. Ideally, Beta could be trusted to do this task, and it's far more useful than most of the proposals in the present list. Chris Cunningham (user:thumperward) - talk 08:47, 29 October 2011 (UTC)

Δ proposed task #14

 * Support, no reason not to. -- SarekOfVulcan (talk) 15:20, 25 October 2011 (UTC)
 * Support, when part of an edit where there is a significant effect on the displayed result. --Dirk Beetstra T  C 15:24, 25 October 2011 (UTC)
 * Oppose as presented in example. The example places a hard space between numerals and a spelled-out unit name, while WP:NBSP only specifically mentions placing them between numerals and abbreviations. Also, the edit summary is not descriptive. [The example also messes up a citation to the New York Times, and changes "accessed" to "retrieved". The effort spent changing words within citations where the article has no consistent citation style would be better spent making the citations consistent.] Jc3s5h (talk) 15:50, 25 October 2011 (UTC)
 * Citation issues aside (separate task), the issue of using the non-breaking spaces is described at WP:NBSP and relevant. Keep the units and labels together; that's the point, and asked for by WP:NBSP. --Hammersoft (talk) 15:58, 25 October 2011 (UTC)
 * Yes, but the line has to break somewhere. A hard space between a numeral and an abbreviation will probably produce a good result, but it isn't so obvious when a long numeral is next to a long word, and WP:NBSP implicitly acknowledges that by only mentioning numerals and abbreviations. Jc3s5h (talk) 18:14, 25 October 2011 (UTC)
 * I don't believe is suggesting otherwise. --Hammersoft (talk) 19:03, 25 October 2011 (UTC)
 * Support between a number and an abbreviation. -- Eraserhead1 &lt;talk&gt; 19:40, 25 October 2011 (UTC)


 * Support provided that accordance with WP:NBSP is narrowly construed. --Tristessa (talk) 21:49, 25 October 2011 (UTC)
 * Support so long as Jc3s5h's concerns are addressed. – Luna Santin  (talk) 22:45, 25 October 2011 (UTC)

Δ proposed task #15

 * Support --Dirk Beetstra T C 15:26, 25 October 2011 (UTC)


 * Caution. The sample shows a citation which does not use a citation template being changed. Archiving could be done to these, but little or no automation could be used because when templates are not used, it is just about impossible for automation to parse citations. It is necessary to determine if any recognized citation style (such as Chicago Manual of Style is in use and if so, conform to it. Also, a more accurate edit summary should be provided. Jc3s5h (talk) 15:57, 25 October 2011 (UTC)
 * Seems fine in principle. I assume the request refers to URLs used as references/citations. Have mörser, will travel (talk) 16:27, 25 October 2011 (UTC)
 * Oppose based on the shining merits of the specific example provided. We shouldn't condone this edit being made singularly by an attentive, communicative editor in a one-off case, we shouldn't give blanket approval to a troublesome editor to make such edits in a manual 20-per-year case, and we certainly shouldn't give Δ blanket permission in advance to do automated edits of this kind to any and all articles on Wikipedia. It wouldn't pass at WP:BRFA (I hope) and so shouldn't be automated by somebody with such a history of problems with just this kind of edit (and there's that uninformative Cleanup summary again). &mdash; JohnFromPinckney (talk) 16:55, 25 October 2011 (UTC)
 * Oppose per example given.-- SarekOfVulcan (talk) 17:19, 25 October 2011 (UTC)
 * Still oppose -- the point isn't that he sometimes does it right, it's that he sometimes does it wrong, and having to check every link in every diff to figure out which is which is painful. -- SarekOfVulcan (talk) 18:59, 25 October 2011 (UTC)
 * Support. This is beneficial for the project, EOT as far as I am concerned. I reviewed the second example and it seems very helpful. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:14, 25 October 2011 (UTC)
 * Oppose. As per Sarek; this would necessitate having to check all of 's work in this regard when done as a mass operation. In any case, this sort of modification is problematic even when done by hand, let alone by a scripted cleanup operation (be it automated or semi-automated) and I don't think, regardless, there's any editorial consensus for this to be done wholesale. If there is future, clear consensus for this operation as a general editing guideline later on, this should be reconsidered. --Tristessa (talk) 21:56, 25 October 2011 (UTC)
 * oppose isn't there a bot that already does this? You seem to be proposing several tasks already covered by bots.--Crossmr (talk) 23:02, 25 October 2011 (UTC)
 * Oppose per Sarek. One of the reasons for the 25 article figure is to allow people time to review Delta's work to ensure mistakes haven't been made. If Delta is given an exemption to do this beyond that limit, checking his work becomes significantly more difficult. When Delta can demonstrate that he consistently and accurately applies these changes, it could be reconsidered. TechnoSymbiosis (talk) 23:08, 25 October 2011 (UTC)
 * Oppose, sadly. I checked the page archived in the first example, and it is devoid on meaningful content. . Yes, this is probably a corner case, but it's clear that scaling up this task is best left to someone other than Δ. Uʔ (talk) 04:46, 26 October 2011 (UTC)
 * Oppose per the "not-better" example. Also I've come across enough Wayback Machine archived pages that are (archived images of] 404 errors to know this is a task that needs to be done manually. And for Wayback, which archived version would be used anyway? You have to find the version specifically relied on by the editor who added the text the ref supports. Franamax (talk) 17:48, 26 October 2011 (UTC)

Δ proposed task #16

 * In general, Beta should stop changing the whitespace within the wikicode of articles. It makes the diffs muich harder to read, and has no effect on the rendered page. Neither of the linked help pages establishes any rule about how to format the parameters of the infobox (and in general Help: pages are not a very authoritative reference, as they are mostly ignored by everyone). &mdash; Carl (CBM · talk) 14:36, 25 October 2011 (UTC)


 * Support per Perl Best Practices. Increasing understandability is always a good thing. -- SarekOfVulcan (talk) 15:22, 25 October 2011 (UTC)
 * Support if the rest of the edit has a significant effect on the displayed result. --Dirk Beetstra T  C 15:25, 25 October 2011 (UTC)
 * Suspend judgement until the proposal is clarified as to whether it only applies to infoboxes, or could be applied to other kinds of templates too. Changes to citation templates have raised objections in the past. Jc3s5h (talk) 16:00, 25 October 2011 (UTC)
 * Oppose. I don't see what Perl has to do with this, and if editors of some article prefer it another way, I don't see a reason to force this change. Have mörser, will travel (talk) 16:28, 25 October 2011 (UTC)
 * Perl Best Practices, p.27-28 -- "Most of the semantic hints in a program...appear on the left side of the code....A cleaner solution is to break long lines before an operator. That approach insures that each line of the continued expression will begin with an operator...it's immediately obvious that an indented line is merely the continuation of the previous line..."-- SarekOfVulcan (talk) 17:16, 25 October 2011 (UTC)
 * Wikipedia is not Perl. If some editors want to think of | as ; in C, which seems to be the case in the example before the change, that's their prerogative. Have mörser, will travel (talk) 17:32, 25 October 2011 (UTC)
 * Support white-space improvements only if there are NO OTHER CHANGES in the same diff, because white-space changes make it hard to see other changes. The edit summary must indicate white-space changes only.  Dicklyon (talk) 17:35, 25 October 2011 (UTC)
 * Conditional support as separated edits stating "Wikicode whitespace fixes only" in summary for review usability. I can't see any good reason why not to support when done like this, though admittedly I also can't see any burning reason why this should be done. --Tristessa (talk) 21:59, 25 October 2011 (UTC)
 * Conditional support if and only if only whitespace changes are made. -- Eraserhead1 &lt;talk&gt; 22:45, 25 October 2011 (UTC)
 * Conditional support per Tristessa, and provided that this is only applied to infoboxes. Open to discussing other templates on an "opt-in" basis. – Luna Santin  (talk) 22:47, 25 October 2011 (UTC)
 * The issue is that these whitespace edits by themselves are too trivial to do in a stand alone edit, which is why I combine them in my general fixes, and right now it is limited to infoboxes and templates starting with football (which for some reason do not use the infobox template prefix). ΔT The only constant 00:29, 26 October 2011 (UTC)
 * As far as whether these should be standalone edits, I'd follow whatever consensus is established here. If those football templates are in practice infoboxes (sounds like yes?), I'm fine with you tweaking those. – Luna Santin  (talk) 00:49, 26 October 2011 (UTC)
 * The issue is that for the most part it as already been determined in other parts of the wiki that these minor edits shouldnt be standalone. And yes those football templates are used like infoboxes. ΔT The only constant 00:52, 26 October 2011 (UTC)


 * Oppose, 'correcting' code style is like 'correcting' engvar. There's no net benefit, there are as many people who prefer one style as the next so it can't be said that a change is made to suit the majority. I may have missed it but neither of the help pages mention putting the pipe on a newline, they simply include that particular style in their examples. TechnoSymbiosis (talk) 23:13, 25 October 2011 (UTC)
 * Definite oppose. When I code C programs, I put the closing brace on a separate ;ine under the code it closes, then undent the next line. Other people undent the closing brace. If we're going to work on the code together, we can go one way or the other, or observe each others' cnventions in different code blocks. If your sole contribution though is just to come along and change my indenting "because it's better" and never ever touch the code again, no effin' way. This is an analogous situation. Also, help pages set no standards whatsoever. Franamax (talk) 17:56, 26 October 2011 (UTC)
 * Oppose; as far as I can tell there is no established convention - this is just whitespace churn. Christopher Parham (talk) 00:50, 27 October 2011 (UTC)
 * Oppose without a really good reason why this should be done. Different programmers prefer different formatting. Karanacs (talk) 16:52, 28 October 2011 (UTC)
 * Oppose its up to the programmer which way the closing pipe. Unless he is standardizing the code because its a jumbled mess of different styles, it shouldn't be messed with. Each person has their own style of coding. --Guerillero &#124; My Talk  21:45, 29 October 2011 (UTC)
 * Oppose. This is a waste of edits. Kaldari (talk) 06:40, 1 November 2011 (UTC)

Δ proposed task #17

 * Another WP:CITEVAR. In general there is no rule that reference numbers must be sequential, and if an article has established a different style it should not be changed solely based on Beta's preference. &mdash; Carl (CBM · talk) 14:37, 25 October 2011 (UTC)


 * Support I would assume that in most cases, this is a result of carelessness rather than deliberate choice, so no reason not to fix. -- SarekOfVulcan (talk) 15:24, 25 October 2011 (UTC)
 * Support, if the rest of the edit also has a significant effect on the display of the page. --Dirk Beetstra T  C 15:26, 25 October 2011 (UTC)
 * Do we really want to split those hairs in this case? It does have the effect of making the article look more professional, so why should we worry about whether the other changes are sufficient? -- SarekOfVulcan (talk) 15:36, 25 October 2011 (UTC)
 * 'Do we really want to split those hairs in this case?' Yes.  As I said elsewhere, the WP:BEANS have been planted, it is waiting for another pattern to emerge.  --Dirk Beetstra T  C 07:29, 26 October 2011 (UTC)
 * Edit summary required. The nature of the edit is not at all evident from the diff, so a meaningful edit summary is essential. Jc3s5h
 * Support. Trivial, but why not - if part of a larger edit, in particular. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:15, 25 October 2011 (UTC) (talk) 16:04, 25 October 2011 (UTC)
 * Support definitely positively useful. -- Eraserhead1 &lt;talk&gt; 19:38, 25 October 2011 (UTC)
 * No. This should not be done in general. Gimmetoo (talk) 21:29, 25 October 2011 (UTC)
 * Support, fair enough. --Tristessa (talk) 22:00, 25 October 2011 (UTC)
 * I can't imagine that Δ is the first person to consider doing this cleanup. Has there been some other discussion about it? Why is no bot doing it? Uʔ (talk) 22:26, 25 October 2011 (UTC)
 * Support provided a helpful summary is used. I'm thinking this edit should actually stand alone, as doing so will make it easier to review a page's history. – Luna Santin  (talk) 22:48, 25 October 2011 (UTC)
 * comment in addition to my blanket oppose above, this is an extreme trivial and unnecessary change.--Crossmr (talk) 22:59, 25 October 2011 (UTC)
 * This task provides very little demonstrable gain to the project. Chris Cunningham (user:thumperward) - talk 14:30, 26 October 2011 (UTC)
 * Oppose; generally, this should not be done blindly per CBM. Christopher Parham (talk) 00:53, 27 October 2011 (UTC)
 * Oppose as I'm not convinced on editorial grounds this should be done at all. To me, the supporting footnotes should be ordered by scope and relevance. If ref-5 is the most directly relevant to the whole of the text cited to the source (whole paragraph or sentence), ref-1 additionally supports a few different parts of it, and ref-3 supports the better wording in the last sentence or phrase, then the correct ordering is [5][1][3], as it allows the reader to check the sources in the order which the reader might find most useful. Pretty-looking articles come second to knowledge, not to mention how futile it would be to clean up every time the first cited source in an article is moved farther down. I occasionally reorder refs myself when I am changing a paragraph, according to that scope-and-relevancy rule - but that's very much an editorial decision. Franamax (talk) 00:55, 27 October 2011 (UTC)
 * Oppose per Franamax. There's no current standard governing the order of inline references, and ordering them by importance seems a perfectly valid style that shouldn't be arbitrarily 'corrected'. TechnoSymbiosis (talk) 22:32, 27 October 2011 (UTC)
 * Oppose per Franamax --Guerillero &#124; My Talk  16:47, 28 October 2011 (UTC)


 * Oppose. I'll be quite disappointed if I'm in the middle of rearranging article text and someone comes in and reorders the sources before I'm done - thus putting them out of order.  (I do this a lot.)  This is something that really needs to be left up to the editors of the article who are familiar with the text and the sourcing.  Karanacs (talk) 16:57, 28 October 2011 (UTC)

Δ proposed task #18
There are already bots that do this automatically, so there is no reason for Beta to start doing this on a large scale as well. &mdash; Carl (CBM · talk) 15:18, 25 October 2011 (UTC)


 * Support, provided that there are other edits to the page that have a significant effect on the display of the page. No need to make 2 edits if { can do it in the same one.  --Dirk Beetstra T  C 15:28, 25 October 2011 (UTC)
 * Support per Beestra-- SarekOfVulcan (talk) 15:38, 25 October 2011 (UTC)
 * Support per Beestra. This is sufficiently obvious while viewing the diff that I would consider it sufficient to only document the other reason(s) for the edit in the edit summary. Jc3s5h (talk) 16:06, 25 October 2011 (UTC)
 * There are some bots that do this practically right after an edit; I suppose they are triggered somehow. I don't see any harm in letting Δ compete with them though. Support . Have mörser, will travel (talk) 16:38, 25 October 2011 (UTC) [Edit: not uncoditionally now that Chris Cunningham has registered an objection I didn't think of before. 16:34, 26 October 2011 (UTC)]
 * Support. Sure, why not? --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:15, 25 October 2011 (UTC)
 * Support why not? -- Eraserhead1 &lt;talk&gt; 19:35, 25 October 2011 (UTC)
 * Support. He might as well. --Tristessa (talk) 22:03, 25 October 2011 (UTC)
 * Support Simple enough. – Luna Santin  (talk) 22:48, 25 October 2011 (UTC)
 * This will seriously mess with my workflow. If I see that Helpful Pixie Bot was the last editor to edit my article I will not bother to inspect the edit as I trust that Helpful Pixie Bot carried out only trivial and well-tested work. I can also trust that for a finite set of human editors. BetaCommand is not one of them. This should be left to trusted bots. Chris Cunningham (user:thumperward) - talk 14:32, 26 October 2011 (UTC)
 * Um, I had not thought of that. Perhaps it would be uncontroversial if Δ does it only in conjunction with another change to the article in the same edit? Uʔ (talk) 16:34, 26 October 2011 (UTC)
 * I think the concern is precisely that he will make other changes at the same time, so that it is necessary to review the edit to see what changed. At the same time, there is no reason for him to do this as the only change in an edit, since two bots already do it. &mdash; Carl (CBM · talk) 16:40, 26 October 2011 (UTC)
 * Do you seriously anticipate that will mis-date a template? Why? Perhaps I'm misunderstanding. –  Luna Santin  (talk) 20:51, 26 October 2011 (UTC)
 * Carl nailed it. There is absolutely no point in Beta making edits which solely consist of dating tags as we already have at least two very reliable true bots which do this. So if he's doing it anyway, it'll be as part of the bag-o-tools that Hammersoft wishes to re-grant him against strong community consensus, and there are tools in there that I trust Beta with far less than I trust the likes of AnomieBot. The end result is that I'll potentially have to double-check many more last edits to pages on my watchlist than I currently do. Simply put, there is no reason whatsoever to grant Beta the right to perform edits that bots already do well, and this is an especially bad example as I strongly expect a known good bot to follow my edits around right now without any drama at all. Chris Cunningham (user:thumperward) - talk 21:51, 26 October 2011 (UTC)
 * This might be a good point to hammer out in the meta discussion, then: in general, should make edits which can be equivalently handled by current bots? I note that editors in general aren't prohibited from making such changes, but if I might paraphrase your point a bit: repeatedly seeing  in your watchlist disrupts your workflow, many other users may feel the same way, and we might therefore consider ways to mitigate that disruption. Similar concerns might be shared by anyone hoping to double check 's edits on any regular basis. Is that a fair summary? –  Luna Santin  (talk) 22:54, 26 October 2011 (UTC)
 * Give Δ the bot flag? Uʔ (talk) 23:37, 26 October 2011 (UTC)
 * Close enough. Editors in general are not banned from making bot-like edits because editors in general have not repeatedly, over a period of years, caused an ungodly amount of drama by doing so. At this point, I trust BetaCommand significantly less than I trust most bots, which I can at least block if they misbehave without having someone running to ANI and screaming about vendettas. The project gains nothing by having Beta duplicating work that we know real bots can do. On the other hand, "known good edits" of this type act as filler for Beta's contributions list; that both makes it harder for interested parties to scrutinise his work, and gives his supporters a piece of impressive-looking but ultimately worthless evidence of do-gooding when next they spring up to defend him. Chris Cunningham (user:thumperward) - talk 07:25, 27 October 2011 (UTC)
 * Oppose per Chris Cunningham iff this task is being carried out by itself --Guerillero &#124;  My Talk  16:51, 28 October 2011 (UTC)
 * Oppose. This is already being done by a bot and is the sole task being done in those edits so it is much easier for other editors to figure out what is going on. Karanacs (talk) 16:59, 28 October 2011 (UTC)
 * Oppose, the bot that does this is single-purpose and easily identifiable in page histories and edit summaries, and can be trusted to contain a specific edit without the need to view the diff directly. Having Delta do this in bulk as well will significantly increase the amount of time editors spend reviewing edits and serves little benefit other than to 'get in before the bot'. Broadly, see also my comments in tasks #1 and #3. TechnoSymbiosis (talk) 00:36, 1 November 2011 (UTC)

Δ proposed task #19

 * Support --Dirk Beetstra T C 15:28, 25 October 2011 (UTC)


 * Support Jc3s5h (talk) 16:07, 25 October 2011 (UTC)
 * Oppose. Too vague. Have mörser, will travel (talk) 16:32, 25 October 2011 (UTC)
 * this is mainly used for templates like dead links, and Failed verification, that should be included in references but for some reason are placed outside the reference that they are referring to. (and similar cases). ΔT The only constant 19:25, 25 October 2011 (UTC)
 * I think failed verification should normally be placed outside the ref, not included in it. The point of that template is to alert the reader of the text that the statement may not be as reliable as usual. So, unless the list of templates and direction of proposed movement is made explicit, I can't support this blanket proposal. [I just changed my user name, by the way.] ʔ (talk) 20:37, 25 October 2011 (UTC)


 * Support. This is beneficial for the project, EOT as far as I am concerned. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:16, 25 October 2011 (UTC)
 * Support seems perfectly reasonable and non-controversial. -- Eraserhead1 &lt;talk&gt; 19:31, 25 October 2011 (UTC)
 * Oppose as too broad - suggest rewording to more specific scope, " may move templates within article wikicode to their proper hierarchical places, provided those templates are unambiguously misplaced and the results are reviewed." --Tristessa (talk) 22:07, 25 October 2011 (UTC)
 * Oppose, too vague. Open to discussing specifics. – Luna Santin  (talk) 22:49, 25 October 2011 (UTC)
 * Oppose as too vague. These requests are not intended to provide Delta with blanket exemptions, they're intended to give the community a chance to review specific changes he intends to make. TechnoSymbiosis (talk) 23:16, 25 October 2011 (UTC)
 * Far far too vague. Specific cases (hatnotes under cleanup tags, for instance) could be exempted, however. Chris Cunningham (user:thumperward) - talk 14:35, 26 October 2011 (UTC)

Δ proposed task #20

 * Done by other bots as well, I think. Support if it is part of an edit which has an significant effect on the display of the page.  No need for 2 edits if  can do it in the same edit.  --Dirk Beetstra T  C 15:29, 25 October 2011 (UTC)
 * So, we're finally admitting he is doing bot-like tasks. Actually, I support this one. Non-controversial, and I think it's hard to make mistakes on a task like this. Have mörser, will travel (talk) 16:35, 25 October 2011 (UTC)
 * Support. This is beneficial for the project, EOT as far as I am concerned. --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; talk to me 18:16, 25 October 2011 (UTC)
 * Support definitely useful. -- Eraserhead1 &lt;talk&gt; 19:34, 25 October 2011 (UTC)
 * Support, nothing wrong with that. --Tristessa (talk) 22:08, 25 October 2011 (UTC)
 * Support – Luna Santin  (talk) 22:49, 25 October 2011 (UTC)
 * Support, useful. Fram (talk) 14:39, 26 October 2011 (UTC)


 * Oppose if a bot already does this as its single task, let the bot keep doing it. That makes it much easier for me as an editor to see at a quick glance what is going on. Karanacs (talk) 17:01, 28 October 2011 (UTC)
 * Oppose per my argument in task #18. If a bot does this already, it has the established trust of the community already to know what change has been made without spending time reviewing its diffs. Delta does not have this trust, and will greatly increase the amount of time editors spend reviewing his edits if he performs these tasks instead of leaving them for the bot. See also my comments in tasks #1 and #3. TechnoSymbiosis (talk) 00:39, 1 November 2011 (UTC)

More proposals forthcoming
Some of them are substantive and are among those that have caused actual controversy during his "cleanup", unlike the above. A draft list containing about 25 tasks is on his talk page; I think his current block prevents him from posting here. Have mörser, will travel (talk) 10:17, 25 October 2011 (UTC)

Edit summary proposal

 * Proposed - I think this might go a long way to resolving the issue of "pattern" editing. --Tristessa (talk) 22:30, 25 October 2011 (UTC)
 * I think that's a really good idea - I think it will help a lot. -- Eraserhead1 &lt;talk&gt; 22:32, 25 October 2011 (UTC)
 * I don't think this will solve the issue. The issue isn't the edit summaries, it is the fact that there is no clear definition of what a pattern is. Alpha_Quadrant    (talk)  22:36, 25 October 2011 (UTC)
 * Problems aren't ever entirely about one thing. The world is complex. This will help - at least a bit. -- Eraserhead1 &lt;talk&gt; 22:42, 25 October 2011 (UTC)
 * Any specific task or theme of edits (like clean-up) run on at least 25 articles in a reasonably close time frame should cover that.--Crossmr (talk) 22:47, 25 October 2011 (UTC)
 * Comment aren't editors really already required to do that anyway?--Crossmr (talk) 22:47, 25 October 2011 (UTC)

I agree with the proposal. Based on the edit summary abuse (2,000 with the same summary "cleanup") this appears to be necessary. If there is consensus for it, it should be appended to the edit restriction so that it is well publicized. &mdash; Carl (CBM · talk) 23:10, 25 October 2011 (UTC)
 * Strong support --Guerillero &#124; My Talk  23:12, 25 October 2011 (UTC)
 * Comment There's a recurrent theme regarding edit summaries, and something needs to be suggested. But, this isn't it. Required? We still haven't figured out what "pattern" means in this context, but now he's required to identify it? That doesn't make sense. --Hammersoft (talk) 23:56, 25 October 2011 (UTC)
 * What would be best would be a link to a page describing most of these requests as they fall into a category of "General Fixes" like what AWB uses and my main edit is something separate. Otherwise the edit summaries become to cumbersome and meaningless ΔT The only constant 00:25, 26 October 2011 (UTC)
 * If I'm following your meaning; perhaps a subpage in your userspace that details the types of actions being undertaken in edits classified by you as "cleanup", and linking to that subpage in the edit summary? --Hammersoft (talk) 00:30, 26 October 2011 (UTC)
 * Correct. ΔT The only constant 00:40, 26 October 2011 (UTC)
 * That would basically be a blanket edit summary, though, skirting the point of my proposal; whilst it would be better than the previous state of affairs (i.e. no information at all), it's still not I feel enough to make review/oversight of the edits straightforward. Your suggestion doesn't specify exactly which of the task(s) each one of your edits are actually making. If you are, as you say, a human editor, there should be no issue in providing a summary describing what you've changed in each edit -- this is all my proposal effectively suggests, and it's by no means something you're being singled out for. --Tristessa (talk) 02:08, 26 October 2011 (UTC)
 * If Delta's using a helping program (with human oversight), an edit summary of the form: "User:Δ/Cleanup tasks #1 (2x), #4 (3x)" could easily be generated, presuming that the Cleanup page does enumerate them. If there's room to spell out the tasks in the edit summary that would be better but with the number of tasks proposed, I don't think there will be room. --M ASEM (t) 14:17, 26 October 2011 (UTC)
 * I think that would suffice for semi-automated edits; anything done by hand can be explained by hand. Works? – Luna Santin  (talk) 20:55, 26 October 2011 (UTC)
 * I don't remember where, but I've seen that done somewhere else. I support that method. The edit summary doesn't have to be self-contained as long as there's an appropriate link to a page like that explaining the numbers/abbreviations used to identify the tasks. Uʔ (talk) 22:51, 26 October 2011 (UTC)


 * Support. Clearly helpful in avoiding incidents like the current one on ANI. Uʔ (talk) 04:39, 26 October 2011 (UTC)
 * Oppose as proposed. I think the idea of having a page being linked to in the edit summary, perhaps with some variation as Masem suggested, is a reasonable compromise. I'm also uncomfortable with the 'required' aspect of this. That will become a bludgeoning tool as soon as misses an edit summary, or makes some minor error. --Hammersoft (talk) 15:00, 26 October 2011 (UTC)
 * Hmm... would it be simpler to just say, " should strive to use descriptive edit summaries, and is prohibited from using blanket edit summaries to describe edits which vary in task, nature or automation."? I like the idea of encouraging useful summaries, but I'd rather not be draconian about it. – Luna Santin  (talk) 20:59, 26 October 2011 (UTC)
 * Um, I can imagine the argument: "but he only uses one script for all the cleanup, so they don't differ in task, nature or automation." Given that we're still having protracted arguments about the definition of "pattern", we'd better not create more ambiguity. Uʔ (talk) 22:47, 26 October 2011 (UTC)
 * I think that's more or less the complaint, though: if it's all one script, it'd be great if it could provide more descriptive summaries. Page after page of "Cleanup" doesn't say much. – Luna Santin  (talk) 22:58, 26 October 2011 (UTC)
 * I believe the spirit of the editing restriction is that Delta is to be asking permission to handle a specific task on a defined set of articles rather than asking for blanket permission. Assuming that view doesn't carry the day, this proposal has my 2nd choice support.  First choice is Luna's proposal (just above). Hobit (talk) 22:29, 26 October 2011 (UTC)
 * What if there isn't a defined set? Let's say finds 16 articles where category tags are placed at the top of the article. Let's say this was on 23 October 2011. A week later, he finds another 11 articles with the same problem. He had no idea there were another 11 out there, but a week later he found them. Now it's 27 articles. Is that a pattern? What if instead of a week, it's a month? Six months? A year? When does it stop being a pattern and become typical editing habits (which all of us have)? --Hammersoft (talk) 12:54, 27 October 2011 (UTC)
 * He should get approval before doing the 11. Or, better, he should simply avoid doing this sort of thing if he finds the approval process burdensome. The point of the editing restrictions is not to make it more convenient for him to do semi-automated editing. &mdash; Carl (CBM · talk) 13:40, 27 October 2011 (UTC)
 * Could you be more specific in your answer? What if the 16 and 11 are separated by a month, six months, a year? --Hammersoft (talk) 14:08, 27 October 2011 (UTC)

Trial period
Based on some comments above, I would like to suggest the idea that any of the above proposals that are approved or those that are on the bubble to speak, that we ask Delta to run a trial period of, say, 500 articles, with the list to be set before Delta begins this task. Assuming Delta works at his max throttle, that'll take him about 2 hrs to complete, but let's work from there. After completing that preset group of articles under this "cleanup", the community would have a period of 1 or 2 weeks to review the edits and assure they are following the approved steps.

At this point, the community can decide which tasks that Delta can be approved of to do indefinitely (because they were executed exactly as expected).

The reason 500 is a nice number is that if all the editors involved in this current convo participated equally in the review, its completley within reason that each edit can be reviewed. 500 edits is also managable if these edits all had to be reverted.

Mind you, I realize Delta claims to have made 8000 edits before this point, but here we're talking a trimmed down list and supposedly a new version of his editing assistance tool to only do those tasks and/or reflect the additional info this proposal has asked for (eg edit summaries).

If you believe this is a good idea but have opposed any of the above tasks, I do recommend that you reconsider that oppose in light of a trail period. That is, if the description that Hammersoft's not provided is clear enough or the examples too vague, this process can help establish the changes that Delta was planning on doing at a larger scale.

Thus, in the future, should Delta want to add more tasks to this cleanup process, he would have to undergo a similar trial period for that new feature. --M ASEM (t) 23:39, 26 October 2011 (UTC)


 * This is much closer to the intention of the current restrictions, but I think 500 is excessive. I'm of the view that before Delta can be allowed an increase or exception to his multi-article restriction, he needs to prove that he can first edit appropriately within that restriction. Delta isn't like a bot requesting approval that might screw up, he already has screwed up in the past and this has caused people to lose faith. I think that trial number needs to be significantly reduced, 100 would be more reasonable. In all cases, Delta's other editing restrictions must be respected and if he breaches one of his other restrictions in any given trial then it ends as failed. TechnoSymbiosis (talk) 00:05, 27 October 2011 (UTC)
 * I'll admit that one of my concerns is giving Delta a point at which he can say 'whew, don't need to be so stringent in my edit reviews anymore'. He may 'tighten up' his checking during a trial and then relax it (or drop it altogether) once he's approved for limitless editing. Is there a way that this trial process can reinforce that he needs to be careful at all times, not just when he's under scrutiny? TechnoSymbiosis (talk) 00:10, 27 October 2011 (UTC)
 * Well, a further option is that, as part of this specific process, that an assigned, uninvolved editor should spot-check his edits that are listed under this Cleanup task. And of course, if one happens to spot a problem (whether being this editor or not), they should be discussing it on Delta's page or some other central location (and making sure that this suggested user page that outlines the cleanup tasks has a pointer to where to report possible violations).  Given the above attitudes, Delta must presume he's always operating under the microscope, but the point of the trial period is to assure that what he's doing is exactly as stated, nothing more nothing less. --M ASEM  (t) 00:20, 27 October 2011 (UTC)
 * On the edits within the trial itself, should these be exclusive to the task being trialled? For instance, if he's trialling deadlink fixes, his 100 trial edits should only contain deadlink fixes? I'm inclined to think this should be the case, but it may not accurately represent how Delta will perform once the task is approved and is mixed in with others simultaneously. His ability to manually review his edits may be complicated when the number of different tasks being performed in any given edit are beyond a certain threshold. TechnoSymbiosis (talk) 00:38, 27 October 2011 (UTC)
 * It should be all the tasks at the same time - in case of code conflicts or the like, and as well that he wants to do all these edits at the same time so this would assure his competency to do that (And if not, then he's free to repropose each task as solitary edits as necessary). As I've implied, all edits from this trial should be evaluated and tabluated per each task (I can envision some table to count all success and failed tasks and a boatload of stats resulting from that). --M ASEM  (t) 02:10, 27 October 2011 (UTC)

The only significant support I've seen on the proposals above are ones that bots already do. don't see the point of that at all.--Crossmr (talk) 10:09, 27 October 2011 (UTC)
 * It might be a good idea to ban all editors from doing anything bots do. The simple reality is humans are prone to error. If the bot does something correctly, as certified by WP:BAG, then we know there's no error rate to worry about. Far better to have a bot do it than an editor, yes? --Hammersoft (talk) 12:55, 27 October 2011 (UTC)
 * The question is not all editors, but simply Beta. Why should he be given special permission to do large-scale edits that would already be done by a bot? Surely there are other things he can do. &mdash; Carl (CBM · talk) 13:43, 27 October 2011 (UTC)
 * But there's nothing preventing any editor (including Delta) from doing the work bots already do at a large scale, and this isn't part of Delta's restrictions (that he can't do work that bots already do). Delta clearly wants to do this type of work, and do it under the current restrictions, and its work (At least, of those approved tasks) that are necessary to improve WP.  --M ASEM  (t) 13:54, 27 October 2011 (UTC)
 * The restrictions do say that Beta's large-scale edits have to be approved by other editors. The restrictions intentionally do not lay out the criteria that those editors will use in evaluating the request: we are free to take into account the entire circumstances of the request. "Other people can do it" is not a criterion I give much weight to, because the goal of editing restrictions is that Beta is not in general permitted to do what other editors are permitted to do. Personally, I do not see an argument in favor of giving him special approval to do what bots already do. &mdash; Carl (CBM · talk) 13:59, 27 October 2011 (UTC)
 * The point of course is there is an assertion that if a bot can do it, shouldn't. There's no such sanction in place, and I fail to see a reason why, for example,  couldn't date a maintenance tag such as npov. You want him to focus on creating articles and adding content. Yet, you don't trust him to date a maintenance tag. I think the reality is you don't trust him to do anything. --Hammersoft (talk) 14:07, 27 October 2011 (UTC)
 * Nor does the community at large. If he cannot be trusted with anything more complicated than is already handled by a bundle of Python modules then the benefit to the project of allowing him to make them is practically nil. Possibly negative, in fact, as the bundle of Python modules does not get into edit wars, make personal attacks, or have friends badgering anyone who shuts it off. Chris Cunningham (user:thumperward) - talk 14:11, 27 October 2011 (UTC)
 * No, it wasn't. My point was that the only couple of tasks that have any significant support with no issues raised were tasks that are done often very quickly by bots. To a scenario in which Delta would be racing with bots to do the tasks, like dating maintenance tags. in about 90% of cases where I forget a date, it's done very quickly or almost instantly after I've done it. What's the point of making a big deal out of a trial of Delta doing those kinds of edits?--Crossmr (talk) 22:49, 27 October 2011 (UTC)
 * Granted, you're right - its your opinion that Delta shouldn't be doing tasks that a bot can otherwise do. But I will point out that the reasons we have the restrictions is that we want Delta to be acting like a normal editor, but highlighted with caution in specific areas (editing speed, civility, etc.); that's the only thing that makes Delta "special".  It is not the case that Delta is not permitted to do certain things; in fact, I'd argue that given the "rights" as an editor, the restrictions do little to curtail what Delta can do as a regular editor.  My concern is that those blanket opposing are giving Delta no chance at redemption on indefinite restriction in an area he wants to work and demonstrate his capability in. --M ASEM  (t) 14:16, 27 October 2011 (UTC)

When other editors exhibit an inability to operate in a particular area of the project without causing drama and disruption we ban them from editing there, regardless of their enthusiasm, level of expertise and so on. BetaCommand is somewhat unique in that his problematic area is not the Israel-Palestine situation, or Transformers characters, or astrology, but wikignoming: this presents a unique challenge when it comes to wording restrictions. With other editors, we expect them to redeem themselves through working in other parts of the project, while in this case we have somehow gotten into a situation where people are proposing that Beta can redeem himself by showing that he can carry out mass edits so long as they're only of the most literally mindless variety. I don't see how this is supposed to work. He needs to show that he can work with others, and dating maintenance tags for six months is not going to prove that. Chris Cunningham (user:thumperward) - talk 14:29, 27 October 2011 (UTC)
 * Agreed. The community has created a situation where can't redeem himself, no matter what he does or how well he does it. --Hammersoft (talk) 15:24, 27 October 2011 (UTC)
 * Again this is false. If Delta chooses to stay within his restrictions, stay problem free for a significant period of time, he could build up some good will. But he seems incapable of doing that. That is why he cannot redeem himself. No one has ever forced him to make the bad edits he makes.--Crossmr (talk) 22:49, 27 October 2011 (UTC)
 * Given that the community restriction were designed around the likelihood of Delta wanting to continue to perform repetitive edits as his gnoming work entails, it is not the case that the community wanted him to work elsewhere, only that to continue, he would have to show that he's doing it in a human fashion. If the community wanted him to stop gnoming, the restrictions would have been far different. Sure, I'm sure that some of the community hoped that Delta would turn to mainspace article improvement via addition of sourced material and the like, but that wasn't a requirement or a facet of any of these restrictions. --M ASEM  (t) 15:37, 27 October 2011 (UTC)
 * It is not the task of the community to force him into making productive edits. The task of the community is to prevent him from disrupting the project, which is what the restrictions are designed to do. There are plenty of "gnomish" tasks other than rapid-fire bot-type edits. In the end, Beta is not going to get his restrictions removed by showing he is roughly as competent as a bot, which is basically all these proposals are asking for (excepting the likes of "can prod articles", which there appears to be little support for). Chris Cunningham (user:thumperward) - talk 17:38, 27 October 2011 (UTC)
 * Then make it simple; ban him from the project. If the community can't develop a construct in which can prove himself, then the community has failed. Since the community won't acknowledge that, the next worse alternative is to ban him completely. --Hammersoft (talk) 18:03, 27 October 2011 (UTC)
 * If he is unwilling or unable to demonstrate that he can still be of benefit to the project outwith the very limited scope of mass-edits of a trivial and largely robotic nature then that's what it'll come down to. Indeed, that's largely what it has come down to. Had the project known in 2008, when the first solid proposals for a complete ban were mooted, that we'd still be here three years later, it's likely we wouldn't be spending time on this right now. Chris Cunningham (user:thumperward) - talk 19:25, 27 October 2011 (UTC)
 * He's quite willing. The problem is the community has created a situation where it is impossible for him to meet requirements and not generate controversy, no matter what he does. But, that's all 's fault, right? The community's got a shiny halo wrapped around their head and can do no wrong. Nope, the community's perfect. --Hammersoft (talk) 19:36, 27 October 2011 (UTC)
 * This gainsaying is convincing nobody. "The requirements" are that Betacommand find something uncontroversial (and of obvious benefit to the project above that which we could trust a computer with) to edit until he can be trusted to work on his pet area of the project without causing drama. There is no shortage of tasks which would fit that bill. He has chosen instead to repeatedly circumvent or otherwise chip away at the restrictions he's under, to what appears to be the complete exclusion of other work. Your snotty and obstinate attacks on the consensus which both led to the current restrictions and sustain them do nothing other than damage whatever standing you may have had amongst your peers yourself. What you gain from this is beyond me. Chris Cunningham (user:thumperward) - talk 20:16, 27 October 2011 (UTC)
 * Delta has plenty of room to redeem himself, this is a constant strawman throughout all of these proposals. The problem is that he wants more wriggle room than the community has allowed him, and that's simply a matter of comfort, nothing more. The constant assertion that someone may come along one day, find 26 edits in the last 2 years that Delta has performed that might constitute a pattern and then try to have him banned for it is both ridiculous and irrelevant. If we're talking about what may happen, then someone may come along, not like Delta's triangular username and ban him with the reason given as 'cheese monkey'. Arguments based on 'what may', entirely devoid of supporting evidence, are entirely without merit.


 * If, as you say, Delta is 'quite willing' to demonstrate his benefit, he should have no problem doing so within his existing restrictions. In what way does tagging deadlinks on 100 articles show he has solved his problems in a way that 25 can't do? He may want to work on more than 25 articles in that way, but frankly that's too bad. He had that chance before, blew it and now has this restriction. If he can't even show he can work within that restriction, there is zero reason to loosen it.


 * As someone mentioned above, AGF isn't an eternal wellspring and it's not a free ticket to act badly and then point back at AGF whenever someone gripes. The more I read these proposals, the more I read your comments, Hammersoft, and some of Delta's own replies here, the more I am convinced that you both see this situation as a game, with wording to be attacked, undermined and discredited, to be lawyered and filibustered, to fabricate doubt and uncertainty until the restrictions no longer seen tenable, regardless of whether they actually are or not. There appears to be no genuine and honest desire to comply with the spirit and intention of the restrictions and use the opportunity to show redemption. Instead, you seek to destroy them. Quite frankly, the more this line of conduct goes on, the more inclined I am to revise my support votes on various proposals above to opposes. Delta needs to abide by his restrictions before they are reduced. If he can't even do that, then you're right - banning him may be the only remaining option. I was neutral on that eventuality before, but this has progressively inclined me towards favouring it, should it come up. If this is your idea of helping Delta, I personally think you should seriously reconsider your approach. TechnoSymbiosis (talk) 22:56, 27 October 2011 (UTC)


 * Oppose all. Delta has long used up all the good faith many community members, including myself, are prepared to assume. When Delta demonstrates good faith in abiding by the letter and spirit of his restrictions for a sustained period of time (at least a year), demonstrates an understand of why he is restricted (which I've never seen) and himself requests permission for specific tasks, not general possibilities, then I will be prepared to consider the requests. Until such time, I have to oppose for the health of the community. Thryduulf (talk) 18:05, 28 October 2011 (UTC)
 * ? He has to demonstrate good faith, but he's not permitted to edit until he does? Wow. --Hammersoft (talk) 22:07, 28 October 2011 (UTC)
 * He's permitted to edit within his restrictions, he's always been allowed to. This false persecuted rhetoric you're using at this point really isn't helping your case at all. You've got a serious case of WP:IDIDNTHEARTHAT right now.--Crossmr (talk) 23:07, 28 October 2011 (UTC)
 * Quite wrong actually, Doctor. I've got a serious case of identifying contradictory messages. I wish I didn't. Life would be a lot easier. But, seeing things like demands for perfection from people who can't spell vacuum, people who demand proof of good faith but won't approve him editing,...the community's really growing it's sanctions. --Hammersoft (talk) 02:48, 29 October 2011 (UTC)
 * And yet further assumptions of bad faith and uncivil comments. So what if someone makes a typo? They're no longer to speak against Delta? Wow. that's certainly a position to take that'll gain you lots of community support. Is Delta permitted to edit right now? Can he go to an article, push the edit button, add or delete text and save it? Yes or no. If you can't honestly answer that and see how you're coming off the rails then I'd suggest a serious step back for you because you're headed down a bad road.--Crossmr (talk) 06:04, 29 October 2011 (UTC)
 * Uncivil? For what, attacking myself? Unreal. What is real is your opposition to anything and everything that does, no matter what it is. If anything's coming off the rails, it's the community's train wreck management of these sanctions. --Hammersoft (talk) 12:58, 29 October 2011 (UTC)
 * demands for perfection from people who can't spell vacuum was written about yourself? No one demands perfection. They demand reasonableness which Delta hasn't shown. people who demand proof of good faith but won't approve him editing Once again: Is Delta permitted to edit right now? Can he go to an article, push the edit button, add or delete text and save it? These are uncivil because they're flat-out lies. Ones you're repeated, ones you refuse to listen to anyone over.--Crossmr (talk) 22:30, 29 October 2011 (UTC)
 * I do hope you have a pleasant day. --Hammersoft (talk) 00:38, 30 October 2011 (UTC)
 * Please answer Crossmr's question. TechnoSymbiosis (talk) 00:00, 1 November 2011 (UTC)

Altering the editing restriction #1 imposed on Δ (Betacommand)
Per the discussion at ANI (and the above discussion) on Betacommand's editing restrictions, I would like to propose a change to the current restrictions, to avoid future problems. Currently the first restriction reads as follows: Restriction #1: Before undertaking any pattern of edits (such as a single task carried out on multiple pages) that affects more than 25 pages, Betacommand must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand must wait for a consensus supporting the request before he may begin. The first restriction is quite vague, and is open to interpretation as to what constitutes a "pattern". As the restriction is unreasonably vague, no editor can reasonable be expected to follow the restriction. There is no time definition, or clear definition of what constitutes as a pattern. He has therefore been sent through numerous AN and AN/I discussions due to an inability to keep within the exact wording of this restriction. Therefore, I would like to propose that the restriction #1 be reworded. The proposed wording is as follows: Before undertaking a task that will affect more than 100 (25?) articles, Betacommand must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a month, where the edits are exactly the same, or almost exactly the same. Edits clearly within policy (i.e. Manual of Style fixes) do not need prior discussion. The suggested changes will address the vagueness of the current restrictions, as well as lessen the likelihood of future problems. Alpha_Quadrant   (talk)  19:11, 24 October 2011 (UTC)
 * I think that restriction #1 needs to be more clearly defined. As is, it's being interpreted many different ways, resulting in a huge amount of consternation. I don't know that integrating the edit throttle as part of the change is needed right now, and including it may muddy the waters of the debate. --Hammersoft (talk) 19:46, 24 October 2011 (UTC)
 * Removed the suggestion of combining restrictions #1 and #3. Alpha_Quadrant    (talk)  19:57, 24 October 2011 (UTC)

I don't agree with raising the number of articles to 100. The motivation for the 25-edit exception was to allow Beta to do some very minimal multi-article editing without breaking the restriction. But the underlying point is that he needs to avoid these large-scale maintenance jobs entirely, and focus on other sorts of editing instead. It is difficult to find a tightly-worded restriction to say that (what is "maintenance" work?) but this is the sort of change that is needed to avoid this sort of problem in the future. &mdash; Carl (CBM · talk) 20:06, 24 October 2011 (UTC)
 * Shouldn't be at AN? Well, anyways, I support, but for 25 articles.    Ebe 123   <span title="This is a special signature.">(+) $<small style="color:#0000FF">talk Contribs$ 20:10, 24 October 2011 (UTC)
 * Maybe, but I think not. This is a community restriction not an administrator imposed one. Administrators are asked to enforce as needed, but placing the restrictions is a community decision. It might be a good idea to place pointers to this discussion in appropriate places. The original restriction page hasn't been edited in three years, so that's not a good place to place one. --Hammersoft (talk) 20:36, 24 October 2011 (UTC)


 * Question "A task is defined as any group of edits within a month, where the edits are exactly the same, or almost exactly the same. " I do not understand this formulation. Take for example the following two edits:  . These two edits look quite similar, but they are obviously not the same, as they 1. are to two different pages and 2. have different diff numbers and ids. So at least for me the aforementioned definition is not entirely clear. Toshio Yamaguchi (talk) 22:52, 24 October 2011 (UTC)
 * Perhaps it should be worded as "A task is defined as any group of edits within a month to multiple pages, where the changes made to the article are extremely similar." Alpha_Quadrant    (talk)  23:35, 24 October 2011 (UTC)
 * A difficulty with "extremely similar" is that it leaves us in the same position we are already in. On the other hand, it would not work to require the changes to be exactly the same, because that would permit the running of maintenance scripts that do slightly different things depending on the contents of the page. I think we have to rely on admins to identify patterns in the editing. &mdash; Carl (CBM · talk) 02:03, 25 October 2011 (UTC)
 * I believe the phrase you are looking for is "substantively the same." See http://en.wiktionary.org/wiki/substantive Guy Macon (talk) 02:35, 25 October 2011 (UTC)
 * We could use something like
 * "A task is defined as any group of edits within a month, where any two edits differ only by the pages they affect and their diff number and id."
 * This would at least make that part unambiguous. Toshio Yamaguchi (talk) 08:33, 25 October 2011 (UTC)


 * Oppose - I think it's a bad idea to increase of number of articles to 100 (which can only exacerbate this scenario), and the Edits clearly within policy (i.e. Manual of Style fixes) do not need prior discussion clause is even more vague than the original. Indeed, this latter is open to serious issues - whilst edits may individually be within policy where executed individually by an editor, they may not be within policy when applied automatically or semi-automatically across a range of articles. Regrettably, I cannot therefore support this proposal. I also believe this particular sub-discussion probably belongs at AN/I rather than here at VPP. --Tristessa (talk) 03:04, 25 October 2011 (UTC)
 * 100 struck and downed to 25. There is little evidence that Betacommand is applying his edits semi-automatically or automatically. Alpha_Quadrant    (talk)  03:32, 25 October 2011 (UTC)
 * There is plenty actually. See for instance User talk:Δ/20110901. Have mörser, will travel (talk) 04:25, 25 October 2011 (UTC)


 * Mixed: I support the '25 articles per month' throttle. I oppose the sentence 'edits clearly within policy (i.e. Manual of Style fixes) do not need prior discussion'. Firstly, the MOS is a guideline and not a policy. The distinction may seem pedantic but it isn't - guidelines can be overruled by local consensus, and Delta's edits most certainly should not be made in situations where they may violate local consensus without discussion. TechnoSymbiosis (talk) 04:54, 25 October 2011 (UTC)
 * The current "pattern" wording seems more reasonable in this light: was one step away from a community ban, and these sanctions are effectively a last-ditch effort to avoid that outcome. The sanction is worded broadly because it is meant to be interpreted broadly. I do, however, agree that some sense of time might be helpful -- a task affecting 25 pages over the course of ten minutes is very different from one lasting two years. I worry, however, that any such wording would be treated as an allowance, where the sanction seems intended as more of a third rail. –  Luna Santin  (talk) 05:23, 25 October 2011 (UTC)
 * I think that 25 per month is a bit too low - if you want to keep it at 25, I'd recommend shortenning the time frame to 2 weeks or similar. עוד מישהו Od Mishehu 07:37, 25 October 2011 (UTC)
 * Strong I do not know and I really do not care, after 4 years (!) of arguments since 2007, with a multitude of blocks, bans, restrictions, sanctions, tasks, ... I just hope sometime soon this will stop. - Nabla (talk) 08:18, 25 October 2011 (UTC)
 * Question "A task is defined as any group of edits within a month...". Does "month" here refer to what is listed in the box at Month or does it refer to a period of time (eg. 30 days)? Say he starts a group edits on the 15th of April that will have affected 25 articles at the 30th of April. Would he be required to make a new proposal to continue on the 1st of May? Or is this not the case, as he only edited for 15 days and he can edit for 15 more days until 15th of May? Toshio Yamaguchi (talk) 08:50, 25 October 2011 (UTC)
 * Hobit (talk) 14:21, 25 October 2011 (UTC)
 * This is not an answer to my question, Hobit. Please reply specifically to my question. As it stands, it is not clear what is meant here and this must be clarified for Δ to have any chance of staying within the restrictions. Toshio Yamaguchi (talk) 11:48, 25 October 2011 (UTC)
 * Sorry, formatting error there (left out a space). Never meant that to be a response to you.  Sorry about the confusion. Moved text to below. Hobit (talk) 14:21, 25 October 2011 (UTC)


 * oppose The exemption of edits "being within policy" only give Delta further rope with which to hang himself and create drama. His problem before was the "I'm right and within policy revert revert" approach and the enablers who allowed that. That behaviour further compounded by the errors that would sometimes creep into what he was doing caused further issues. Delta being unable to follow the restrictions is not an excuse to move the goal posts. It's a reason to enforce the consequences.--Crossmr (talk) 11:25, 25 October 2011 (UTC)
 * Require meaningful edit summaries. I would suggest that the 25 edits be regarded as the same if their edit summary is the same. I would further suggest that in order to be considered different, it must be apparent from the edit summary they are different, and the edit summaries must accurately describe the edit. Accurate edit summaries are an expectation from any human editor (as opposed to a bot, or bot-like behavior, which is what Betacommand is not to do). In the case of an editor with questionable edits in the past, enhanced enforcement of the edit summary requirement is appropriate. Jc3s5h (talk) 13:02, 25 October 2011 (UTC)
 * #1 I don't think VP is the right place to do this. #2 I think if we need to hem in an editor in such a detailed way, we are better off banning or letting them free.  In any case, I'm opposed to the changes as being too bureaucratic.  Hobit (talk) 10:35, 25 October 2011 (UTC)
 * Oppose. MOS has far too much stuff in it to allow a bot-like editor to enforce every aspect of it without prior approval for specific tasks. Δ clearly doesn't follow WP:CITEVAR for instance. Have mörser, will travel (talk) 17:28, 25 October 2011 (UTC)
 * Oppose many of the following proposals, specifically all the ones which attempt to define "task" in terms of the word "function" and a word count, per WP:CREEP. -- N  Y  Kevin  @125, i.e. 02:00, 29 October 2011 (UTC)

Proposal n+1
I propose the following wording for the restriction:


 * Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where any two edits differ only by the pages they affect and their diff number and id. Edits clearly within policy (i.e. Manual of Style fixes) do not need prior discussion.

Toshio Yamaguchi (talk) 16:05, 25 October 2011 (UTC)


 * Support I believe that wording is much better. Alpha_Quadrant    (talk)  16:41, 25 October 2011 (UTC)


 * This would allow him to do almost any automated or semi-automated task in which the change is not identical in every article. For example, reformatting dates, removing different images from each article, etc. He has shown an chronic inability to handle that sort of thing without community review, and it would be unwise to allow him to try to do so again. &mdash; Carl (CBM · talk) 17:19, 25 October 2011 (UTC)
 * If the changes are not clearly within policy he has to come here. Mass reformatting dates is discouraged by policy, so he would need to come here before doing it. If an image violates policy, he has every right to remove it. If the removal is not based on policy, then he has to come here. Most of the above requested changes pointed out by Hammersoft are already in the Reflinks general fixes. These edits are clearly non-controversial. I (and many others) often use RefLinks, and no one would think to come and tell us the changes are against policy. Your arguments above are simply based on the fact that Δ is Δ, and you think he shouldn't be doing any editing. Regards, Alpha_Quadrant    (talk)  17:31, 25 October 2011 (UTC)
 * Beta has demonstrated a chronic inability or unwillingness to distinguish between controversial and uncontroversial tasks, accompanied by chronic communication problems when people raise the issue with him. This is why he is currently under both a strong edit restriction and an a arbcom motion. The proposal immediately above would weaken the edit restriction and allow Beta to perform automated or semi-automated tasks without review if they did not make exactly the same change to each article. Experience shows that the result of that would only be more controversial editing. &mdash; Carl (CBM · talk) 17:53, 25 October 2011 (UTC)
 * Under the current restriction Δ cannot do anything because they let you define at your will what is and what is not a pattern. The proposed wording for the restriction makes them objectively checkable by anyone. By the way please show me the policy which classifies the tasks Δ performs as controversial. Controversial means that people have different opinions regarding a specific matter. If that is what you mean, this and previous discussions obviously show that not anybody agrees with you, so your classification of Δs editing is itself quite controversial. Do you therefore imply you should be placed under editing restrictions because not doing so would result in more controversial classifications of peoples edits? Toshio Yamaguchi (talk) 18:12, 25 October 2011 (UTC)
 * The proposed wording is indeed objective, but it is too weak to prevent the chronic disruption that Beta has caused in the past. There is a reason that Beta is under such tight restrictions. At the time the restrictions were made, it was a difficult argument for me and others to get people to agree to the restrictions instead of banning Beta outright. See Administrators' noticeboard/Incidents/I have blocked Betacommand. &mdash; Carl (CBM · talk) 20:54, 25 October 2011 (UTC)
 * "...but it is too weak to prevent the chronic disruption that Beta has caused in the past." Perhaps I didn't check Δs history enough, but would you be so kind to provide some diffs to the past edits you consider disruptive and briefly explain how these edits disrupt the project? Toshio Yamaguchi (talk) 21:38, 25 October 2011 (UTC)
 * CBM is probably going to cite one of Betacommand's actions that resulted in the enforcement of the NFCC policy. Betacommand's actions led to the deletion of several thousand unfree images without fair use rationale. For what I have read, that upset quite a few users. Alpha_Quadrant    (talk)  21:54, 25 October 2011 (UTC)
 * The editing restrictions already specifically state that Δ is indefinitely topic banned from enforcing NFCC.
 * @CBM: Are you suggesting that the purpose of this restriction is to prevent his mass removals of non-free media from articles? Toshio Yamaguchi (talk) 22:09, 25 October 2011 (UTC)


 * Oppose. MOS has far too much stuff in it to allow a bot-like editor to enforce every aspect of it without prior approval for specific tasks. Δ clearly doesn't follow WP:CITEVAR for instance. Have mörser, will travel (talk) 17:28, 25 October 2011 (UTC)
 * If there is no clear citation style in an article, any editor is permitted (and encouraged) to standardize the article to one style or another. See Template:Citation style. Alpha_Quadrant    (talk)  17:33, 25 October 2011 (UTC)
 * You were complaining before that the sanction is difficult to follow; imagine how difficult it will be when all patterns require discussion, except for a vague and subjective category that are magically acceptable (until some admin decides they're not). It seems to me that it will be much safer and clearer to require discussion of all patterns. An exception for "obvious" MOS edits seems destined to cause trouble and confusion. – Luna Santin  (talk) 22:55, 25 October 2011 (UTC)


 * Oppose per my rationale above. MOS is a guideline, not a policy, and can be overridden by local consensus. Delta should never be allowed to override local consensus without discussion and approval. TechnoSymbiosis (talk) 23:22, 25 October 2011 (UTC)
 * What does this have to do with this proposal? What this proposal does is allowing him to edit like anyone else as long as his editing does not constitute a task affecting more than 25 articles. What this proposal does is prohibiting him from making similar edits to more than 25 articles if there is any opposition or this editing has not been supported by consensus. Can you please show me how this proposal allows him to override local consensus without discussion and approval? As far as I know Δ is not prohibited from editing in general. Toshio Yamaguchi (talk) 00:36, 26 October 2011 (UTC)
 * I'd think that would be fairly clear. Your proposal says 'edits clearly within policy (i.e. Manual of Style fixes) do not need prior discussion'. I don't consider that as acceptable. The MOS is not a policy, firstly, and because of that it can be overridden locally. Delta's restrictions stem in part from acting in an automated (or with the appearance of automated) fashion without giving due diligence to the circumstances, nuances or prior consensus. He has already demonstrated in the past that he can't make these changes en masse without problems, which is why the restriction was imposed. Your proposal seeks to relax that restriction with no justification. When Delta shows that he is capable of making appropriate changes within his 25 article limit, then we may consider relaxing the restriction. Not before. TechnoSymbiosis (talk) 00:55, 26 October 2011 (UTC)

Proposal n+2
Reformulated; removed the part regarding MOS edits. The proposed wording of the restriction is now as follows:
 * Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where any two edits differ only by the pages they affect and their diff number and id.

This should address the concerns regarding MOS edits. Toshio Yamaguchi (talk) 00:47, 26 October 2011 (UTC)
 * That did seem to be a major sticking point. Thanks. I'm still a bit concerned that (25 pages/30 days) will be seen as an allowance, where I'd rather see it as a third rail, but all things being equal I think I'd prefer this to the currently enforced wording. – Luna Santin  (talk) 00:51, 26 October 2011 (UTC)
 * I still oppose this formulation on the basis that 'where any two edits differ only by the pages they affect and their diff number and id' is too narrow a definition. Under this terminology, Delta could (erroneously) rename all articles with titles in title case (eg. Halley's Comet) to sentence case (eg. Halley's comet) and despite this being a clear pattern, the terminology allows it because the content of each change is different (C->c, D->d, etc). I'm of the opinion that there is no terminology that will satisfy everyone - someone will always think it's too strict or too lenient. I would personally prefer the wording 'where each edit performs the same substantive change'. TechnoSymbiosis (talk) 01:06, 26 October 2011 (UTC)


 * I oppose this as well. Removing deleted images is clearly a pattern/task to me, and this wording does not define it as such because the image deleted can be different on each page. Uʔ (talk) 05:55, 26 October 2011 (UTC)

Proposal n+3: If a bot could be programmed to do it, it's a pattern
Reformulated to avoid requiring exact diff matches:
 * Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where the differences between any two edits can be explained as the implementation of a common computer programming task, such as, but not restricted to, pattern matching by regular expressions.

Fell free to tweak as desired, but I think the idea is clear enough. Basically if a programmer could write a bot/script to do the edits with the effort normally employed in writing Wikipedia bots and semi-automated scripts, then they should be considered a pattern for the purpose of this restriction. Don't ask me to support any narrower idea than this. There's a reason why ArbCom adds "broadly construed" to their sanctions: to avoid lame wiki-lawywering. Uʔ (talk) 06:10, 26 October 2011 (UTC)


 * This was the intention behind the current restrictions, as well. If something looks like a semi-automated or automated task, it requires approval. &mdash; Carl (CBM · talk) 15:28, 26 October 2011 (UTC)


 * Let me provide a hypothetical situation. Some major reliable third-party source provides a list of the 50 top grossing movies of all time. Delta wants to add this information to each of the 50 film articles here on WP; they would all use the same reference/cite, and require him to simply place pre-formatted text from a script into the article at, let's say, as a new paragraph at the end of a specific section that appears in each of the 50 articles.  Is this is semi-automated/automatic task or a pattern of edits that we would be worried about?
 * If not, then I would argue that the issue is more on Delta's cleanup and maintenance aspect, and from that, identifying patterns is actually much easier. If you clearly outline that edits that neither add or remove article text but are to clean up the wiki-code, things that may or may not be possible with bots, then we have a start of what can consider as "pattern of edits" that should be under the 25 article or seek VPP restrictions.   --M ASEM  (t) 17:26, 26 October 2011 (UTC)
 * The more I read about this, the more I think this should be sent to ArbCom as well. It doesn't appear to me that the community will ever agree on what "pattern" means in Δ's edits. (Dirk Beetstra who complains a lot about this above, has yet to make his opinion known on any of these concrete proposals, by the way.) As for "Delta wants to add this information to each of the 50 film articles here on WP" — if this involves infobox-editing, like adding review stars (which some albums or video games have), then I can imagine a programmed task doing it, so it should require approval. If he's going to add a paragraph of text to each page, each paragraph containing a summary or even just quotation from the hypothetical source that pertains to the topic of the page, then I think it's unlikely that anyone would program a bot for that, so I don't see a need for requesting approval. Uʔ (talk) 18:00, 26 October 2011 (UTC)
 * I think it is useful to remember that people are not complaining because of some hard-to-see pattern involving 25 article edits spread over a year. The recent issue concerns 2,000 edits with the same edit summary. So although it might be nice in an ideal world to know exactly what is a "pattern", in practice the patterns are completely obvious so that even a vague definition is sufficient. &mdash; Carl (CBM · talk) 18:36, 26 October 2011 (UTC)
 * Echoing Carl (including that the statement above very closely matches the otiginal community intent of the sanctions), there is no evidence at all that arcane definitions of "pattern" will be invoked in some future scenario for the purpose of sheer hatred or even genuine confusion. That is an invention of a very small (2 or 3) subset of editors here. People are pretty good at identifying and classifying patterns. Many independent editors have confirmed that the recent edit history constitutes a pattern, namely, using an identical edit summary when making a large set of disparate changes to articles, each enacted according to an individual "rule", but only enacted when the target article has an actual instance of violating that "rule". It's really quite clear when inspecting the edits, but a useful test would be to look for cases where a "rule-violation" was not corrected. That would be compelling evidence that a human was working through the article, improving it one thing at a time but in one edit, occasionally missing something on their list - however, I doubt such evidence exists. The overarching pattern is quite clear. No-one has ever objected to Beta making a series of positive sourced visible-text contributions to articles, either 2 or 200, and if they do, I'll be right there to shout the onjector down. Franamax (talk) 02:49, 27 October 2011 (UTC)
 * Seems reasonable to me, if we also consider edits with the same (or essentially the same) edit summary as being part of a pattern, whether or not the actual edits form the pattern described (see my proposal n+6). — Arthur Rubin  (talk) 02:16, 28 October 2011 (UTC)

Proposal n+4

 * Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where all edits of the task (ie all changes between the last revision unaffected by the edit and the first revision containing the changes of the edit) are expressible as a simple function. A function (for the purposes of this restriction) is simple, if it can be expressed through written text consisting of no more than 20 words (Example: Change all occurrences of + in the article markup to -); (Example: Change all cases of Example occuring in a group of article titles to example).

I revised the text to address the concerns regarding patterns of edits, where the content changed with each edit is different. Toshio Yamaguchi (talk) 14:41, 26 October 2011 (UTC)
 * Comment; The more attempts are made to make everyone happy, the more everyone will be unhappy. The longer this gets, the more like Windows Vista it looks, the more like a beer can and bailing wire it becomes. More troubling; the longer it gets the more opportunity there is for wikilawyers to exploit loopholes. "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away" --Antoine de Saint-Exupéry --Hammersoft (talk) 15:04, 26 October 2011 (UTC)
 * The problem in my opinion is that if the restriction does not nail everything down to the point, the discussions and accusations that Δ has violated his restrictions will continue. My hope is (and I don't know whether this is possible) to create an unambiguous formulation for the restrictions and perhaps include something that those who accuse him of having violated the restrictions must provide proof that his editing actually and clearly violates the restriction. The current formulation at WP:RESTRICT obviously does not achieve this and therefore anybody can simply claim some of Δs editing to constitute a pattern and nobody can reasonably tell if that is actually the case or not. If the text can be revised enough we can perhaps achieve that people will be required to say "Δ has done so and so here and here (diff) (diff) (diff). This violates the restriction because it was done over time period XY and amounted to Z edits in that period." That would be absolutely objective. Toshio Yamaguchi (talk) 15:24, 26 October 2011 (UTC)
 * It's an excellent goal. --Hammersoft (talk) 15:31, 26 October 2011 (UTC)


 * Proposal; I would like to include a statement in the above proposed formulation of the restriction. I think of something along the lines of
 * "The burden of proof that Δ has violated this restriction is on those who claim there is a violation. This proof should take the form of providing diffs to edits so that the violation is obvious from the timestamps of the diffs. This evidence of violation should be reported at WP:AN/I."
 * Toshio Yamaguchi (talk) 15:44, 27 October 2011 (UTC)
 * The complete text of the proposed formulation of the restriction can be seens below.

Proposal n+5

 * Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where all edits of the task (ie all changes between the last revision unaffected by the edit and the first revision containing the changes of the edit) are expressible as a simple function. A function (for the purposes of this restriction) is simple, if it can be expressed through written text consisting of no more than 20 words (Example: Change all occurrences of + in the article markup to -); (Example: Change all cases of Example occuring in a group of article titles to example). Note: The burden of proof that Δ has violated this restriction is on those who claim there is a violation. This proof should take the form of providing diffs to edits so that the violation is obvious from the timestamps of the diffs. This evidence of violation should be reported at WP:AN/I.


 * Toshio Yamaguchi (talk) 16:33, 27 October 2011 (UTC)


 * Oppose as absurd. For example, an appropriate rule for the "Example" example would be "change capitalization".  2 words.  Furthermore, if Δ uses the same edit summary, it should also count as the same task without dealing with ANI.  In other words, if Δ says his task is "cleanup" we should take him at his word, and consider it to be a "task". — Arthur Rubin  (talk) 17:06, 27 October 2011 (UTC)
 * This is not a reason to oppose this as absurd but to require Δ to provide correct and meaningful edit summaries. Toshio Yamaguchi (talk) 17:13, 27 October 2011 (UTC)

Mostly I think this is clear, and the 30 day thing would resolve some quibbles. But I don't understand the "burden of proof" language. In the latest example, there was no question that we could give a list of far more than 25 articles in which Beta removed a link to a deleted image, so it would have been easy to meet this burden of proof. What is the motivation of this? &mdash; Carl (CBM · talk) 17:51, 27 October 2011 (UTC)
 * Say Δ gets blocked for having violated the restriction. Then I think it is unreasonable to require Δ or someone else contesting the block to prove that he did not in fact violate the restriction. In my opinion, the person blocking him should provide evidence (via diffs) that Δ in fact violated his restriction. Toshio Yamaguchi (talk) 18:06, 27 October 2011 (UTC)
 * That is not unreasonable, but if the evidence is "look at the last 100 edits and 75 of them all involve the same task", it seems odd to require someone to manually copy all those diffs when they are already available in the contribs page. If the edits are less obvious, then it seems more reasonable. &mdash; Carl (CBM · talk) 18:10, 27 October 2011 (UTC)
 * The "burden of proof" part is in my opinion inline with WP:AGF (and as far as I know Δ is not excempt from having AGF applied to himself). Note that the purpose of this is not to give Δ additional leeway with respect to this restriction, but to prevent him for example from being blocked prematurely before the evidence has been provided. If the evidence of violation is there, then applying sanctions (such as blocks) should be mostly uncontroversial. Toshio Yamaguchi (talk) 18:34, 27 October 2011 (UTC)
 * The proposed text does not say he cannot be blocked before evidence is provided, though; it seems consistent with the text to block and then put the evidence on ANI immediately. But I don't see why the simple phrase "look at the last 50 edits in his contribs" is much worse than a list of diffs for the last 50 edits would be. Also, although we should assume some good faith with Beta, his history and his editing restriction mean that it would be foolish to treat him as if he was a new editor who did not know the site yet. &mdash; Carl (CBM · talk) 18:49, 27 October 2011 (UTC)
 * The text is not meant to imply he cannot be blocked before evidence is provided. Sorry, what I said in my previous reply is clearly incorrect. It is meant to reduce the amount of drama that surrounds this user. And I believe if he is blocked and clear evidence for violation of the restriction is provided, then this block should be mostly uncontroversial. Toshio Yamaguchi (talk) 19:03, 27 October 2011 (UTC)
 * Thanks, and I completely agree with your last sentence there. &mdash; Carl (CBM · talk) 22:06, 27 October 2011 (UTC)

I added a requirement regarding edit summaries in proposal n+7 below. Toshio Yamaguchi (talk) 23:09, 27 October 2011 (UTC)

Proposal n+6 (same edit summary, same task)

 * Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where the edit summaries are essentially the same (e.g., "Cleanup" "Removing deleted image (Filename)", "correct capitalization", "move tags"), unless the edit summary points to an approved task. This does not remove the existing restrictions, but is a clarification that Wikipedia should assume that edits with the same edit summary are the same task.


 * — Arthur Rubin (talk) 17:06, 27 October 2011 (UTC)


 * A good clarification. ASCIIn2Bme (talk) 18:01, 28 October 2011 (UTC)

Proposal n+7
Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where all edits of the task (ie all changes between the last revision unaffected by the edit and the first revision containing the changes of the edit) are expressible as a simple function. A function (for the purposes of this restriction) is simple, if it can be expressed through written text consisting of no more than 20 words (Example: Change all occurrences of + in the article markup to -); (Example: Change all cases of Example occuring in a group of article titles to example). In connection with this, Δ is required to provide edit summaries exactly describing the changes made (Example: "Replace all underscores between words of article titles in wikilinks with spaces" for this edit). Note: The burden of proof that Δ has violated this restriction is on those who claim there is a violation. This proof should take the form of providing diffs to edits so that the violation is obvious from the timestamps of the diffs. This evidence of violation should be reported at WP:AN/I.

I added a requirement for the edit summaries. Toshio Yamaguchi (talk) 22:30, 27 October 2011 (UTC)
 * Oppose as introducing arbitrary hoops that would make even the most egregious editing on 's part capable of being argued away, and endlessly, by his supporters. The whole definition of a "function", and the addition of a "burden of proof" element of claims of a violation, provides an endless means by which almost any misadventure on his part could be debated into the ground by means of semantics and judgement of the proof being incomplete, or splitting hairs that the edit is too complex to be defined in a 20-word algorithmic description. I cannot possibly see how this is an improvement. --Tristessa (talk) 00:21, 28 October 2011 (UTC)
 * I don't think that's adequate. I think "change capitalization" or "remove (or comment out) deleted images" would be sufficient to identify a pattern, although not necessarily sufficient for the description.  Given that, the burden of proof could rationally be on the accuser, except that for obvious violations, the block could be legitimately made before the proof is posted.  But, even then, you're putting too much of a burden on Δ, as he would be required to place detailed edit summaries on each of his edits, including each of his AWB-like edits.  I don't know if he can do that, so he might be accidentally in violation, as opposed to his usual intentional violations.  — Arthur Rubin  (talk) 01:29, 28 October 2011 (UTC)
 * I would suggest that if Delta's editing tools can't comply with Wikipedia's standards generally, and with his editing conditions specifically, then he should avoid using them. The terminology of his restrictions should be built around what kind of behaviour we expect from Delta, not around what his problematic editing tools are or aren't capable of doing. TechnoSymbiosis (talk) 01:36, 28 October 2011 (UTC)
 * This. We are going about this all wrong - corkscrewing down into editing restrictions that control the tools, but don't address the problem. A bad driver with a powerful car needs driving lessons, not restrictions on where the car can go.  Scrap this 'pattern' nonsense - just have something that says "this user must edit within policy and within consensus. He must use clear edit summaries.  He must not do things that consensus is against (which wipes out about half the proposals above). If a mistake or an edit against consensus is pointed out to him, he must be civil and investigate the problem.  If he again makes the same mistake or edit without consensus - without stopping, acknowledging that it has been pointed out to him, and discussing the matter civilly, he will be blocked.  If he is incivil when someone points out a mistake or other wise objects, he will be blocked." Elen of the Roads (talk) 16:01, 28 October 2011 (UTC)
 * I'm with Elen. This level of detail in the restrictions is ridiculous.  Either Betacommand can edit while meeting WP policies or guidelines or he can't. Either he is editing with consensus or not.   If he has consensus and is following guidelines and policies, who cares how many words it takes to describe what he's doing? Karanacs (talk) 16:12, 28 October 2011 (UTC)
 * I agree we should cut to the main point: Beta should not be performing any sort of large-scale maintenance edits, and should limit himself to content editing until he has a good track record of collegial and successful editing. &mdash; Carl (CBM · talk) 00:19, 29 October 2011 (UTC)

Proposal n+8
Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. A task is defined as any group of edits within a period of 30 days (counted from the time of the first edit of the group to the same time 30 days later), where all edits of the task (ie all changes between the last revision unaffected by the edit and the first revision containing the changes of the edit) are expressible as a simple function. A function (for the purposes of this restriction) is simple, if it can be expressed through written text and if that function were applied to the same basic markup as prior to the changes made by Betacommand / Δ by a bot programmed with that written text as executable instruction in pseudocode would result in the same page markup after being run over the markup as the markup after the task in question performed by Betacommand / Δ. (Example: Change all occurrences of + in the article markup to -); (Example: Change all cases of Example occuring in a group of article titles to example). In connection with this, Betacommand / Δ is required to provide edit summaries exactly describing the changes made (Example: "Replace all underscores between words of article titles in wikilinks with spaces" for this edit). Note: The burden of proof that Betacommand / Δ has violated this restriction is on those who claim there is a violation. This proof should take the form of providing diffs to edits so that the violation is obvious from the timestamps of the diffs. Those claiming a violation must show that a simple function as defined above exists for the edits in question. For violations of Betacommand's / Δ's requirement to provide accurate edit summaries, it suffices to show via a diff of the edit that the edit summary is inaccurate or does not match the change made in the edit. The evidence of violation should be reported at WP:AN/I.

I further revised the wording of the restriction to address some of the concerns raised. A point that probably needs to be more precisely defined is the requirement for Δs edit summaries which to some reasonable degree should match the changes he made. The restriction should also define the basic wording sheme these edit summaries are supposed to follow. Toshio Yamaguchi (talk) 09:02, 28 October 2011 (UTC)
 * Restrictions shouldn't look like congressional bills --Guerillero &#124; My Talk  17:00, 28 October 2011 (UTC)
 * I agree, this one is definitely too complex to be practical. ASCIIn2Bme (talk) 17:02, 28 October 2011 (UTC)

Simplifying
As noted, this is getting insane, bordering on wikilaywering.

To me, the current restriction is in place to slow down Delta's actions in "maintenance" of articles, loosely defined as neither adding or deleting article plaintext content but modifying the backing wikicode to make it easier to read, to improve WP's performance, or manage other processes like adding dead link templates or dating cleanup templates. These are actions that Delta has been criticized for in the past for making gross mistakes that a human would catch, and not being responsive if they go wrong.

Thus, maybe the point here is to modify the first restriction to be about maintenance tasks, with any maintenance tasks being broadly construded to meet the 25 edit number. With that, the above process about approving Delta for these tasks falls right in line here; if Delta wants to take on another maintenance task, he must seek approval on VPR first.

This also means that if Delta adds to article text, he should not conflate any maintenance tasks (otherwise that would be normally part of adding the text) to the article, but instead do separate edits. For example, if he adds a reference, putting it in the right order then and there isn't a problem. But adding a reference, and then elsewhere, fixing whitespace shouldn't be done in the same edit.

As for if he should delete text content, we should assume good faith here, and given that even normal editing is under the 40 edits/10 minutes rule, if Delta does take questionable deletion actions, it can be caught and handled just like any other editor. --M ASEM (t) 16:31, 28 October 2011 (UTC)


 * Support Second choice after my proposal (n+10). -- N  Y  Kevin  @753, i.e. 17:04, 28 October 2011 (UTC)
 * Support. This makes much more sense to me. Karanacs (talk) 17:39, 28 October 2011 (UTC)
 * I've read the proposal twice, and I still have no clue what is actually being proposed here. ASCIIn2Bme (talk) 17:59, 28 October 2011 (UTC)
 * I didnt mean to take it as a proposal, but to be more specific, I am simply saying that the first community restriction be specifically targeted at any "maintenance tasks" - broadly interpreted that do not touch the actual text of an article but instead fix the wiki-code behind it.  This leaves Delta still free to do any "true editing" (modification of article text) which generally never falls into a pattern, still throttled at 4/minute, which is what the community seems to want to push him towards. He still can maintain but just needs to make what maintenance he's doing very specific and descriptive. --M ASEM  (t) 20:03, 28 October 2011 (UTC)

Proposal n+9: lift all community-imposed restrictions
Simply lift all community-imposed restrictions. See Elen of the Roads' comment at n+7. WP:MEATBOT is policy, so if Δ wants to test the [unspecified] speed limit, he can, but he is under erhöhte Betriebsgefahr if he goes against consensus. ASCIIn2Bme (talk) 16:35, 28 October 2011 (UTC)


 * Beta has demonstrated time and time again the need for the editing restrictions. If anything, we need to move to a tighter set of restrictions. &mdash; Carl (CBM · talk) 00:17, 29 October 2011 (UTC)
 * ...on the community beating the living crap out of him every time anyone even mentions "", yes. On himself? Not so much, if only because this sub-thread with n+infinity proposals for writing a replacement restriction for a horribly written restriction proves the absurdity of the community's actions. --Hammersoft (talk) 13:20, 29 October 2011 (UTC)
 * Only if, even involved admins, can block if any apparently automated edit does anything wrong, including his idea, contrary to WP:MOS, that dead link tags should be within tags. — Arthur Rubin  (talk) 20:31, 29 October 2011 (UTC)
 * I think you need to update the documentation on dead link then. as it is currently it says If the article uses clickable footnotes, then this tag should be placed just before the that contains the dead link. The notice will then correctly appear in the reference section (instead of in the body of the text, which is not recommended). ΔT The only constant 20:37, 29 October 2011 (UTC)
 * I don't think this proposal is a good idea, judging by Δ's history. Kaldari (talk) 06:43, 1 November 2011 (UTC)

Proposal n+10: Common sense
Before undertaking a task that will affect more than 25 articles, Betacommand / Δ must propose the task on WP:VPR and wait at least 24 hours for community discussion. If there is any opposition, Betacommand / Δ must wait for a consensus supporting the request before he may begin. The definition of "task" is to be interpreted broadly, except that it shall be limited to 30 day periods unless Betacommand / Δ specifically requests a longer task on WP:VPR; for the purposes of blocking unauthorized tasks, no task shall be broader than 30 days. It is the sole responsibility of Betacommand / Δ to avoid anything that might reasonably be interpreted as a "task", or to get permission first. However, blocking administrators are expected to provide evidence of Betacommand / Δ's transgressions. Any block must be reported to WP:AN or WP:ANI promptly. Administrators and others involved, including Betacommand / Δ are expected to use common sense in applying these restrictions.

This is absurd. The "function" idea is never going to work. It is Betacommand / Δ's job to avoid breaking his restrictions. The "function" idea is a gateway to wikilawyering and madness. Also I don't think removal of the sanctions entirely is a good idea. -- N Y  Kevin  @728, i.e. 16:28, 28 October 2011 (UTC)


 * Erm, who proposed the above (n+10)? I assume NYKevin didn't propose it just to disagree with it... ASCIIn2Bme (talk) 16:39, 28 October 2011 (UTC)
 * I proposed the above (n+10). Where did I disagree with it?  I can see that it disagrees with (n+9), but that's not mine.  -- N  Y  Kevin  @739, i.e. 16:44, 28 October 2011 (UTC)


 * According to this diff NYKevin proposed n+10. Toshio Yamaguchi (talk) 16:45, 28 October 2011 (UTC)
 * Ok, thanks for the clarification. Writing "This is absurd." right under it and prefixing it with confused me. ASCIIn2Bme (talk) 16:48, 28 October 2011 (UTC)
 * Sorry, I was talking about (n+8) and all the other ones mentioning "function"s. -- N  Y  Kevin  @745, i.e. 16:53, 28 October 2011 (UTC)
 * I'm now trying to understand what's the difference between n+10 and n+3... ASCIIn2Bme (talk) 16:58, 28 October 2011 (UTC)

n+3 mentions regular expressions and other specific criteria. This one goes for a common sense approach and puts the onus on Betacommand / Δ to avoid breaking the rules. -- N Y  Kevin  @751, i.e. 17:01, 28 October 2011 (UTC)
 * Just as an example. The only specific criteria is that a computer programmer could potentially code something very similar. Which is indeed more specfic than just saying "user common sense", but as we have seen on ANI, plainly interpreting "pattern" in that sense did not work for some, so maybe WP:There is no common sense in this case, only "common programmer sense" if you like. ASCIIn2Bme (talk) 17:07, 28 October 2011 (UTC)
 * IMHO it is extremely important that Betacommand / Δ have the onus of following the rules and avoiding problems. He is under sanctions.  Those should be interpreted broadly, and he should avoid anything suspicious, even if it's borderline.  That's what it means to be under sanctions.  -- N  Y  Kevin  @757, i.e. 17:10, 28 October 2011 (UTC)


 * Why is this problem user allowed to waste so much of everyone's time? 86.160.218.77 (talk)

It looks like ArbCom has decided to review these sanctions themselves
I'm making this note here so people hopefully avoid wasting their time !voting on individual proposals, because it seems that those are going to be moot soon enough. See Arbitration/Requests/Clarification. ASCIIn2Bme (talk) 22:10, 31 October 2011 (UTC)
 * Good. We've seen so much chaos with the community-imposed restrictions that I hope they issue a clear and internally-consistent set of restrictions; I really don't care what they do, as long as what they do is easier to understand and implement than the current restrictions.  Nyttend (talk) 06:26, 3 November 2011 (UTC)