Wikipedia talk:Semi-bots

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Comment[edit]

"current treshold for "bot rate": two edits per minute" Where has 2 edits per minute come from? stub sorters using a tabbed browser can do double this, I have seen pywiki bots do over 10 edits a minute without causing any trouble. This threshold is way too low. On a different note, I dont think this page is needed at all, it is far too prescriptive, and the parts that are useful can just be added to Wikipedia:Bots. Martin 14:40, 15 April 2006 (UTC)[reply]

"Bot rate", not inventing anything new here, e.g. "Until new bots are accepted as ok they should wait 30-60 seconds between edits" (see: Wikipedia:Bots#Current policy on running bots). Only flagged bots can edit at a speed exceeding that. The "tabbed browser" argument has been used before, ... it sort of has become a standard excuse for semibot operations (it has the "advantage" nobody else can actually check it). I thought it best not to refer to "tabbed browsing" in this guideline because of its blurring effect, but instead make the proposal refer to (types of) tasks. "Stub sorting" is a good example in that sense, I'll mention it in the proposal too. If you would be interested in some preceding talk regarding this issue, see e.g. user talk:Rich Farmbrough#Smackbot de-flagged. Anyway, pywiki bots doing 10 edits per minute should be flagged, which would normally only happen after procedures explained at WP:BOTS, they're clearly not semi-bots in the sense of this guideline proposal, they would need to have an agreed upon bot task description etc, so fully covered by that existing policy.
The semi-bot proposal was initiated because the WP:BOTS instrument is often to coarse for semi-bots. The semi-bots proposal is less prescriptive for semi-bots than treating them as bots (e.g. semi-bots don't need a preliminary agreed upon job description, unlike un-flagged bots listed at WP:BOTS). Further treating semi-bots as non-flagged bots (as is practice up till now) created a lot of aggravation and controversy (e.g. AWB claiming not to be a bot, which is, as far as I can see, correct).
Also: the semi-bot guidance would not be something of official policy level itself. which would be best for the semi-bot guidance IMHO, while criteria can't be played as hard as for bots: thus far semi-bots were either crushed by the WP:BOTS policy, or were handsomely just kept out of the reach of that policy, leading to blocks that could be justifiably disputed while covered by no specific guideline/policy. So, I hope to avoid that sort of aggravation, prone to cause wheel-warring, in the future too. --Francis Schonken 15:17, 15 April 2006 (UTC)[reply]
Ok, I misunderstood that it meant un-flagged bots. I appreciate that point, but please don't use language that implies I am making an "excuse", it is unhelpful language when trying to maintain a rational discussion. Anyway, I think it is a great idea to have a guidline to differentiate semi-bots from normal bots, but it really is far too prescriptive, i.e. the bit about adding spaces around piped links, which I assume is in refernce to the link you provided on the village pump, now I agree that it wasnt a helpful edit, but 1) I have never seen anyone do that before, and 2) as far as I can see it wasnt even a semi-automated edit (I may be wrong about that though). Certainly the de facto standard is not to have spaces around links, and all editors should respect that, but it really doesn't need to be spelt out here, I think it would be much more helpful to simply advise editors to respect all policies, guidlines and common practices. Martin 15:34, 15 April 2006 (UTC)[reply]
Well, I never said nor even implied you used tabbed browing as an "excuse". I was referring to another case, where it was used as an excuse. I don't want to drag in that (but if I must and you ask me I'll explain), it wasn't even a discussion I was involved in, just read it afterwards. Anyway, as I said, for that reason I tried to make the semi-bot description independent from tabbed browsing (which I use myself, as you might see when reading the SmackBot piece I made a link to above, so there I used it as an "excuse" myself).
Re. the Jossi edit, it was serialized:
  1. 04:44, 11 April 2006 (hist) (diff) Wikipedia:Version 1.0 Editorial Team/Core topics (format + spacing)
  2. 03:52, 11 April 2006 (hist) (diff) m Wikipedia:What Wikipedia is not (frmt / spacing)
  3. 03:52, 11 April 2006 (hist) (diff) m Wikipedia:NPOV tutorial (frmt / spacing)
Really, I don't want to spend my time checking such edits, which are no more than annoying, redundant, and in general: contraproductive. "Pointing to guidelines" isn't really an option here I suppose, I don't think this is in any guideline, nor should it be as far as I'm concerned. Note that I remarked something similar as part of this edit some time before, so I think it is really coded in some version of AWB or so (don't know and don't have to know), so this is not really a "one of" situation, and that's why I think it useful to mention this *explicitly* in this guideline (and not in another guideline: removing/adding whitespace is perfectly innocent and, for example, you wouldn't have to look too hard to find an edit where I added or removed whitespace in existing text as part of a normal editing process: this express removal/adding of whitespace only becomes annoying when serialized).
Re. your general point ("[...] I think it would be much more helpful to simply advise editors to respect all policies, guidlines and common practices"): better not to go in denial about a flock of recent aggravation that couldn't be properly handled nor with existing policies and guidelines, nor with WP:BOTS procedures. E.g. someone posted on my talk page "[...] I have been horrified by the retaliation being taken against [user:...]. It seems to me these people have utterly failed to make any move at all to try and bring the guidelines towards what they feel ought to be said.", which was said about a semi-bot operator crushed by "creative" (but in fact unjustified) use of WP:BOTS. So, if the semi-bots guideline can be written in a way to avoid (e.g.) the aggravation caused by making a user submit a bot approval request, for something that is covered by a guideline, but in a "very narrow" consensus way, a bot approval which was denied two consecutive times, after which that user proceeded with these serialized edits in non-bot mode, and eventually was blocked, and threatened to be blocked again if he would give execution to what is in the guideline up till today (but not before Jimbo had rolled his thunder [1] – BTW, Jimbo was mistaken: he rolled his thunder against something that was not a bot at the time). Not that I don't admire Jimbo rolling his thunder, but please, maybe we'd better try to construct a nice guideline, that had avoided the aggravation both to the user and rest of the wikipedia community in the first place. What d'you think? --Francis Schonken 15:43, 16 April 2006 (UTC)[reply]
For the record, the edits made by Jossi do things the opposite way around to AWB, so I think it is unlikely it was done with this tool, but it is academic really. Anyway, I still feel that this guideline is far too bloated, really the entire section on specific tasks and the specific references to AWB should be removed, otherwise it makes it read like a personal rant, no offence.
I think this guideline only needs to have two things 1) what a semi-bot is and 2) the current nutshell definition "Only serialize edits that are covered by a broad consensus", which could happily be appended to the current bot page, all the rest is unnecessary. Martin 16:20, 16 April 2006 (UTC)[reply]

Bureaucratic red tape galore![edit]

So, let's see if I got this right:

  • Performing any repetitive task quickly garners the label of "semi-bot".
  • Not actually using software beyond a standard webbrowser (define "standard", in any case) isn't a defense.
  • Semi-bots are not to perform tasks with no basis in official(!) policy.

We're now neatly banning:

  • Leaving thank-you notes after a successful RFA.
  • Any type of manual stub- or category-sorting.
  • Most of the work performed by the various cleanup projects.
  • Any work related to conformance with mere guidelines.
  • Pretty much anything else that requires repetetive editing.

Do you have any idea just how useless "official policy" is in editorial terms? Most material governing actual article appearance is, at most, a formal guideline—and sometimes not even that! Kirill Lokshin 15:32, 15 April 2006 (UTC)[reply]

I completely agree with you except for the bit about RfA's. Thank yous for RfAs are time consuming, take up unecessary resources and often involve pictures that put unecessary drain on the already stressed image servers. JoshuaZ 16:54, 23 April 2006 (UTC)[reply]
Brion has, IIRC, said the "drain" of userspace image use is marginal/practically non-existant. —Locke Coletc 20:54, 25 April 2006 (UTC)[reply]
Yes, this has recently pointed out to me Brion's comments in that regard (in a discussion about possibly discouraging such notes). JoshuaZ 20:58, 25 April 2006 (UTC)[reply]

Sorry, but this essay here is just an extended form of "botophobia" (err, sorry - semi-botophobia). "Whether the tasks are fully automated, or humanly-supervised for every edit makes no difference for the semi-bot definition, only a repetitive pattern of edits as defined above" this is not helpful. I can assure you that a lot of tasks are repetitive. Defining these tasks as semi-botting is not needed. We do not need this red tape here. "humanly-supervised for every edit" this makes a lot of a difference to me. If I carefully check each diff before saving, this is completely different compared to some bot without UI cycling through a list of articles. If I use an UI tool and carefully check each diff before saving, then it's definitely not a bot, not even a semi-bot. I reject this essay here. Unneeded and misleading. Have you ever used AWB actually? Did you notice that it has an edit window? Please be aware that I do use this edit window, so my AWB edits even contain a certain amount of manual edits. Maybe just someone crossed one of your walled gardens using AWB. Please be aware that nobody owns articles here. If you do not want your edits having edited by others, then don't contribute on this wiki. Current procedures as laid out are completely sufficient. If the community rejects some serial edits, the editor is quickly informed and will learn very fast if his edits are unwanted. Please assume good faith. There are people that care on a broader base about Wikipedia. It is not sufficient to concentrate on a handful featured articles only. It is also the average quality of articles that counts. If you have a problem with an edit done using AWB, talk with the editor, as for any other edit. But please be aware that some specialist edits are a bit harder to understand from the standpoint of a singular article. So please be kind and assume good faith on the part of AWB users. This is a wiki. You are not alone. --Ligulem 18:14, 15 April 2006 (UTC)[reply]

Unnecessary policy?[edit]

Considering the only semi-bot you mention in the draft is AWB, I'll focus in on that:

  1. "...nor can semi-bots be used to perform tasks for which there is a broad consensus, but which need context-dependent interpretation for deciding whether a change is to be performed or not." AWB requires human interaction to save (unless you are on the AWB's list of bots, which only admins can change and includes - I think - only flagged bots), and users that blatantly do not check their edits are usually warned and then removed from the list of allowed users.
  2. "Edit summaries of changes performed by semi-bots should be clear as well about the performed changes..." So should AWB summaries state "heading fixing as per MoS and interwiki sorting and unicodifying and external link bulletting and wikifying HTML and bad link fixing and link simplifying and title bolding and self-reference delinking using AWB" just in case on of those happens to occur in that edit (all of which are applied by general fixes) or do you want the AWB to automatically append to the summary exactly what it does?
  3. "Operators of semi-bots... should be reachable and responsive on an en:wikipedia talk page..." The AWB doesn't let the user edit if there is a "new messages" warning (of course, this won't work for users who receive messages on a separate accounts, such as bots).
  4. "Not being responsive within a reasonable delay of time (24 H), may lead to the blocking of the semi-bot account..." 24 hours? If someone is using a bot and is away for 24 hours (with the bot still going, I presume) then they really should need a bot flag! Going back to the AWB, though, why block the user? Why not just remove him/her from the AWB approved list?

I understand that this policy isn't exclusively for AWB, but, if it was, why need this whole page? I agree with Martin - it's too formulaic. 1, 3, and 4 I've addressed, and 2 can be changed by programming AWB to interactively change edit summaries as it edits - or, more simply, just leaving the edit summaries alone. So, IMHO, the rules listed on WP:AWB alone should suffice. --M@thwiz2020 16:23, 15 April 2006 (UTC)[reply]

Unresponsive for 24 hours[edit]

I don't think this is right at all. The current text is ambiguous, but I can't see how it would work under any interpretation. The text of the proposal currently states:

Operators of semi-bots (whether separate account or not) should be reachable and responsive on an en:wikipedia talk page and prepared to undo edits diverging from the principles of this guideline. These reversions should not destroy intermediate changes by other editors. Only improving the semi-bot's settings without properly undoing rejected edits does not suffise. Removing remarks given about the semi-bot's behaviour, before ascertaining that the poster of the remark considers the remark properly handled is considered the same as "not being responsive". Not being responsive within a reasonable delay of time (24 H), may lead to the blocking of the semi-bot account, for which the blocking admin will leave a note on the contact page for the semi-bot.
  • The 'prepared to undo' stuff I agree with. I've done this myself.
  • The 'Removing remarks' stuff is pretty straight-forward, and covered by the usual talk & archive guidelines.
  • What does 'unresponsive for 24 hours' mean? 24 hours while the bot is running is far too long (~3k edits at bot-rate) - and if we're talking about supervised bots, rather unlikely to happen. People sleep, even if they don't want to. On the other hand, 24 hours while the bot is not running is far to short. Not everybody logs on several times a day, and they shouldn't need to. If the changes are no longer being made, there's no need for a block at all.

Some sort of policy/guideline for software-assisted human-monitored edits is needed, but we need to alter this proposal a bit. SeventyThree(Talk) 17:36, 16 April 2006 (UTC)[reply]

I've proposed an alternative to "24 H responsiveness" now [2], I'd appreciate your input whether you like this better.
Re. your second point (removing remarks)... well, erm, the fact that someone mentioned in village pump that he felt rather powerless against semi-bot like editors removing remarks without properly handling them, kicked me off to start with this semibot proposal. See wikipedia:Village pump (policy)#Blanking of user talk pages --Francis Schonken 14:18, 18 April 2006 (UTC)[reply]
Definately clearer. I've re-written it some more, and hopefully the language is clearer now. I'm going to go through and spell/grammar check the rest of the page, as some of the paragraphs have become overlarge. I'll try not to change the meanings, but revert back anything you disagree with. SeventyThree(Talk) 04:51, 20 April 2006 (UTC)[reply]
After doing that, I have to say that I don't think this page is going to work. Most of the proposal is too prescriptive, and there's too much of a focus on examples rather than general rules. I think most people can work out the rules from the principles, and anything else should be dealt with case-by-case. Too much text here. Some of the ideas could be incorporated into WP:BOTS, after discussion on that talk page. SeventyThree(Talk) 05:19, 20 April 2006 (UTC)[reply]

not needed[edit]

This is entirely uneeded as many of the guidelines here are layed out on the pages of the tools that fall under the category of semi-bots and much of this seems to be pure paranoia against semi-bot tools. Pegasus1138Talk | Contribs | Email ---- 21:11, 16 April 2006 (UTC)[reply]

Anybody else?[edit]

Is there anybody else that wants / needs this essay here besides User:Francis Schonken? If not, I would say rejected per WP:SNOW. Francis, please move it to under your user space. --Ligulem 22:33, 16 April 2006 (UTC)[reply]

I agree that this is rejected and will mark it as such. Pegasus1138Talk | Contribs | Email ---- 22:52, 16 April 2006 (UTC)[reply]
Funny - WP:SNOW is an essay. The semi-bot proposal is only out for two days, very active in comments and updates of the proposal, widely advertised. So I don't think one could say it isn't an "active" proposal. For active proposals, there are guidelines. I'm neither won for Martin's idea to summarize this in the policy page WP:BOTS - I'd definitely think that would be too high strung for something I basicly see as something that would better be something of guideline level; nor do I think it a good idea to abort this prematurely, but follow the guidelines on how to forge guidelines instead (i.e. keep it a proposal and not declare it inactive before it is). I'd definitely want to hear TreyHarris on this proposal too (his comments kicked me into starting this, see Wikipedia:Village pump (policy)#Blanking of user talk pages)
Also from constructive talk with Ligulem (see User talk:Francis Schonken#AWB and User talk:Ligulem#Wikipedia:Semi-bots) I think Ligulem would agree to further explore the potential of this proposal before dunking it. --Francis Schonken 13:30, 17 April 2006 (UTC)[reply]
No I would love to see this page dunkend, you have reverted edits I made to it in good faith without prior discussion. We do not need another "policy" page just to discuss the issues you are bringing up. The cases you brought can be handled for example at RFC's. You nedlessly hit the tool. This is a pattern often seen. We can address the issues on the WP:AWB page. And if you have problems with the editors using AWB then there is no need to put the AWB users in handbaskets as a group, by trying to establish bureaucratic red tape and instruction creep. It might be that I'm a bit damaged by this kind of pattern (establish a "policy" and then divide et impera). I wouldn't say that your semi bots proposal can fully be compared with that, but I have seen what a single person (or a small group) can do with such a pamphlet (see WP:AUM). Twisting arms until no false claims can be proven and voilà, you have a new nuker. You fear tools like AWB? I fear "policies" established like WP:AUM. --Ligulem 14:48, 17 April 2006 (UTC)[reply]
Anyway, it's not going to be dunked now. It is a proposal.
I partially reverted, partially adapted your updates to the proposal in good faith. As your current option is to get the proposal dunked ASAP, I think you're making it a bit difficult for yourself to be seen as a "good faither" for possible future edits of the proposal.
I'd like it the other way around: that is: you not trying to get it dunked from a to z, but working on it in a constructive manner. In short, the choice is up to you.
This proposal is not AWB-centered (don't try to get yourself in the center of the picture!). There is other semi-bot software. Not all semi-bots even use auxiliary software, and really, I'm not interested if any additional software is used.
and hey, hey, hey, can I get your attention for a second: ***THIS IS NOT INTENDED TO BECOME POLICY*** even if that was what Martin/Bluemoose was suggesting ("insert it in the WP:BOTS official policy page"). No, I'm proposing not to go that road. It's not the first time I say that I'd rather like to see this at guideline level, and that is also clearly indicated in the proposal. Like, for instance, wikipedia:Citing sources is a guideline, and not a policy like wikipedia:verifiability, nor a how-to guideline for the use of software (like wikipedia:footnotes explaining how to use the Cite.php software), knowing also that there are other software and non-software options for citing sources. --Francis Schonken 15:40, 17 April 2006 (UTC)[reply]
I see no issue with letting this proposal exist for awhile and improve and I in retrospect agree that it was probably premature to mark it rejected... so soon, also since you state that this is not AWB centric I have removed some of the excess mentions to AWB though I have left in the main one on the list of tools that qualify for being used for semi-bot activity since that's the important one. Pegasus1138Talk | Contribs | Email ---- 17:00, 17 April 2006 (UTC)[reply]

Francis, your logic is wrong. You state that because I am against this guideline, that any edit I do to this is per se in bad faith. This is assuming bad faith on your part! I wonder how you want to declare this to be consensus, as consensus is what is needed to make a guideline. You might have gathered that I'm not the only one opposing your essay. I see no consensus here. I see only you reverting edits from me and others. I have seen this pattern of behaviour already ("power guidelining"). Trying to establish guideline the way you do it. You simply disregard input from AWB users, as you deem them to be the evil ones. That's not consensus. By the way, on Wikipedia there isn't such a big difference between guideline and policy. Both are (1) actionable and (2) authorized by consensus. I'm an inclusionist on articlespace. But not on guidelines/policies. --Ligulem 23:21, 17 April 2006 (UTC)[reply]


Straw poll[edit]

content of this section moved to Wikipedia talk:Semi-bots/straw poll per Guidelines for creating policies and guidelines point 10, Do not call a vote --Francis Schonken 22:49, 17 April 2006 (UTC)[reply]
I don't agree with this and think that this proposal will never get a consensus to become a guideline when the time comes for a consensus to be judged but after looking at all the relevant policies and guidelines I have come to think that it is definitely premature to have see whether this has consensus or not (more likely not). Pegasus1138Talk | Contribs | Email ---- 02:06, 18 April 2006 (UTC)[reply]
Ok. you don't want to have a poll. But that doesn't make the fact go away that Pegasus1138, Mathwiz2020 and myself have said we do not want to have this guideline established. There is no consensus to have this guideline at all. --Ligulem 07:04, 18 April 2006 (UTC)[reply]
Just for the records: I would also say that Kirill Lokshin sounds mostly against this proposed guideline. Bluemoose – the inventor of AWB and a well established bot operator with tons of edits – wrote
"I think this guideline only needs to have two things 1) what a semi-bot is and 2) the current nutshell definition "Only serialize edits that are covered by a broad consensus", which could happily be appended to the current bot page, all the rest is unnecessary".
So, as I see it there are currently Bluemoose, Mathwiz2020, Kirill Lokshin, Pegasus1138 and Ligulem (myself) which say this proposal is unwanted or unneeded. So. Currently there is 5 contra 1. How is this consensus? If you want to try finding consensus, you definitely need to allow some changes to this guideline, persistently reverting edits from opposers won't get you consensus. I would also propose to Francis to seek support from at least a few other wikipedians before presenting such a proposal. This is best done working out under your user space in early stages. At least you should have been talking with a few others before doing such a proposal. A nice thing would have been to involve an AWB user. Pushing this proposal against the will of the AWB users will not work. --Ligulem 07:25, 18 April 2006 (UTC)[reply]
Add me to the list of people who say that this proposal is unwanted/unneeded. Apparently this guy is coming after my Ref converter now, which is a simple Perl script that interfaces with a web browser. Why do we need so many layers of bureaucracy? Wikipedia has over a million articles in it ... trying to fix a particular issue purely manually is a monumental (and wasteful) timesink. --Cyde Weys 18:02, 19 April 2006 (UTC)[reply]
Ashibaka is also against having this as a guideline [3], [4]. He was reverted by Francis [5]. There is clear consensus not to have this as a guideline at all. Francis ignores this. So we have now Bluemoose, Mathwiz2020, Kirill Lokshin, Pegasus1138, Cyde, Ashibaka and Ligulem (myself) which say this proposal is unwanted or unneeded. 7 against Francis. No consensus for having this at all. --Ligulem 11:08, 23 April 2006 (UTC)[reply]
Another NO. I know that I'm being a bit obvious, but making different edit policies for users who use Wikipedia Firefox plug-ins and whatnot is an incredibly bad idea that will only cause serious problems. This is a solution looking for a problem. Current editing and conduct guidelines apply to all users and they work quite well.
I could go on and on about every other problem with this "semi-bot policy" but that has already been done quite well by editors on this talk page.
—-- That Guy, From That Show! (esperanza) 2006-04-25 03:04

bot vs action[edit]

I don't think the definition of semi bot works so well, saying that it's an account is misleading at best since most people use their accounts mostly for non semi-bot work so it should be entirely redefined as the action of doing one of these things or better yet a style of doing one of these things since they can (in theory) be done in a non semi bot way i.e. if they happen as part of a bigger edit or are just random improvements in one or two articles (thus not qualifying as repetitive. Pegasus1138Talk | Contribs | Email ---- 17:03, 17 April 2006 (UTC)[reply]

Seconded. A bot is not an account. Also a semi-bot cannot be an account. The term semi-bot itself is contentious. If you want you can also say that Firefox is a semi-bot under this proposed guideline. Too much weasel wording. --Ligulem 07:33, 18 April 2006 (UTC)[reply]
Thirded. I also strongly dislike the term semi-bot which is vague and general. JoshuaZ 16:58, 23 April 2006 (UTC)[reply]
I on the other hand do recognise a certain type of edit that I've personally always called a "bot-like" edit. I think there would be advantages to naming this sort of editing as it is becoming more and common so it would be good to be able to easily refer to it! On the other hand, I don't mind what the name is and I don't think we need all this reams of proposed policy to govern bot-like bots (current policy is enough for me!). Pcb21 Pete 09:14, 24 April 2006 (UTC)[reply]

Comment[edit]

This proposal is overly bureaucratic and unnecessary. The use of editorial assistance devices is necessary to keep up with the sheer volume of content in the encyclopedia; this proposal seeks to cripple editors from being able to do necessary tasks efficiently simply because one person objected to one type of easily-automated tasks for reasons having nothing to do with encyclopedic merit. Kelly Martin (talk) 13:47, 25 April 2006 (UTC)[reply]

I'm in agreement. As long as actions aren't fully-automated they really are no different than any other action. Each action is being verified by human eyes and that human is entirely responsible. A real-world equivalent would be if the only tools you were allowed were your hands and you had to get progressively tougher licenses to use screwdrivers and then electric screwdrivers. As long as the screwdriver doesn't turn in screws automatically when no one is around it's really just an extension of a person. I believe gun laws also back this up ... guns don't kill people, people kill people. --Cyde Weys 20:36, 25 April 2006 (UTC)[reply]

Rejected[edit]

Despite the fact that some users are stubbornly refusing to let this die as nature intended this proposal is quite dead, there is a strong consensus against it (vs what's needed which is a consensus for it so that it can go into implementation) and there are many many many threads of comments of how this is an awful idea, this together shows that this is an unworkable proposal that has been rejected by the editors who have commented on it bar a small number who support it. As such I have marked it rejected. Pegasus1138Talk | Contribs | Email ---- 20:30, 25 April 2006 (UTC)[reply]

Hi Pegasus, please stop trying to take ownership of the page. If you have good ideas, you're welcome to improve the proposal. Denying it is a proposal, at the time when it is, is not such a good idea in wikipedia's spirit of collaboration.
See also AmiDaniel's posting on your talk page "P.S. I do have some very slight reservations regarding your recent incivility with the Wikipedia:Semi-bots proposal, which I too observed; however, I assume this was a one time incident."[6]... this was barred later ([7]), but I think it's safe to say you've taken up the same antics again, so no longer "a one time incident".
Currently, I'm not very impressed by the (semi-)bot users' rallying against this proposal. Only shows the need for some sort of guidance on the matter. The proposal didn't get many reactions yet by the vast majority of wikipedians that don't use (semi-)bot software. I await these. --Francis Schonken 09:58, 26 April 2006 (UTC)[reply]
I'll add my reaction as a editor who edits only in a completely manual way. I wouldn't consider myself to be a semi-bot user: take a look at the speed of my edits. Except under this proposal, I would be tagged as a semi-bot user, since I am using software (popups) that could be used to enhance editing speed, despite the fact that I use this for navigation. Thus by this guideline, my account would be prohibited from making links and changing redirects (note that the guidelines are unclear here, apparently later saying that I can use the account). Does this make sense? The proposal is far too broad, far too restrictive, and doesn't really make any sense. It seems to me that the entire point of software like AWB is to allow editors to make edits that are in depend on context or might not be appropriate in all cases. Following this proposal would make it so that AWB and other software could only do things that a real bot could do much faster. Thus, I would not support this proposal even if the wording were fixed to not encompass completely unrelated editors.--Constantine Evans 11:01, 26 April 2006 (UTC)[reply]
"take a look at the speed of my edits" - I don't see what you're trying to say. Speed is irrelevant for semi-bots (that is: if you're working at bot speed, WP:BOTS policy has to be applied, so also irrelevant for semi-bots).
Re. "making links and changing redirects", either these would be non-contentious links and redirects (and then if semi-bots were a guideline it wouldn't make a difference), either they would be contentious, in which case this guideline draws your attention that you would be multiplying contentiousness by serializing it. What is your problem? If you use popups for editing, please indicate so in the edit summary like anybody else (e.g. [8]) If you don't use popups for editing, I don't really understand what problem you try to explain, nor do I understand what would be "unclear" in the formulation. Could you try to formulate your problem clearer?
The problem is that in its current state, we have "any user account using software which enhances the speed with which edits can be made...can be labelled as a semi-bot". Thus my account can be labelled as a semi-bot even though I don't use popups for doing repetitive edits (I don't even think popups can help with that, besides providing a more direct link to edit). The point of this proposal is to govern repetitive edits, is it not? Then why is it concerned about editing speed and software? What about editors who do repetitive edits manually? It would seem to me that it would be better to rewrite this so as to cover all serialized edits, instead of trying to come up with a criterion based on differences from a "standard webbrowser installation". --Constantine Evans 22:52, 26 April 2006 (UTC)[reply]
Re. your AWB remark: see bots listed at WP:BOTS, many of these use AWB, as well the high-speed ones as (even more) the non-flagged ones. If the type of repetitive edit is possibly contentious, get an approval for the job description first, that is present WP:BOTS policy. --Francis Schonken 12:02, 26 April 2006 (UTC)[reply]
Hmm, the WP:BOTS policy only applies to automated edits, not merely repetetive ones. That's really the core of the problem here; you've created a "No repetetive edits" proposal but are still trying to call it a bot-related one. Kirill Lokshin 13:31, 26 April 2006 (UTC)[reply]
??? Is it even too difficult for you to read the proposed guideline in a nutshell formulation, "Only serialize edits that are covered by a broad consensus"? Well, as we all now There Are No Cabals, but there certainly ins't a "No repetetive edits" proposal. I think that's where your problem is. --Francis Schonken 13:48, 26 April 2006 (UTC)[reply]
But what do software enhancements have to do with serialising edits, beside making it easier? In the current state, editors who don't use any enhancements are free to serialise as much as they want, and users who don't serialise but do use these enhancements are restricted. --Constantine Evans 22:52, 26 April 2006 (UTC)[reply]
My apologies for somewhat overstating the extent of the proposal; but statements that "a broad consensus (as for example in official policy) for the type of edits you want to serialize is usually required" are still focusing merely on the repetetive aspects of the edits. Broad consensus is not generally needed a priori—certainly not on the level of official policy—even for sweeping changes; and no amount of presumed software (again, what exactly is a "standard webbrowser installation"?) changes that. It's only when the edits actually become automated that this should even be an issue. Kirill Lokshin 22:56, 26 April 2006 (UTC)[reply]
Francis, I'm not taking ownership of this and have actually acted to improve this as a proposal (as you can see from the page history) but that being said almost all the input on this has been that it is an overbearing and uneeded proposal, thus why I marked it as rejected, and it doesn't matter who those opinions come from, they're still valid and they still work to establish that there is a pretty clear consensus that this is a bad idea, also I would like to see where you think I've been uncivil, this entire process I have been nothing but civil and marking a rejected policy as rejected is not uncivil so much as it is just disagreeing with your POV. Pegasus1138Talk | Contribs | Email ---- 13:29, 26 April 2006 (UTC)[reply]
I have reverted myself so now it is marked as {{proposed}} since it was and is wrong of me to mark this as rejected without at least some more input on the subject, though I do have very real concerns that people won't let this die even if most people are strongly against it. Pegasus1138Talk | Contribs | Email ---- 13:40, 26 April 2006 (UTC)[reply]

traceability of tools[edit]

I just had a thought, although some tools like vandalfighter and AWB force a tracer note onto edit summaries stating that's what being used many javascript tools either don't or indeed can't by their very nature do that (do to the fact that anyone can mod their own version of the js because it's by nature open to all) so this policy while it may technically apply to tools like popups is in reality unenforceable for any js plug and/or many other tools. Pegasus1138Talk | Contribs | Email ---- 13:43, 26 April 2006 (UTC)[reply]

nth time, this isn't a policy proposal. --Francis Schonken 13:50, 26 April 2006 (UTC)[reply]
It doesn't matter since many guidelines (i.e. WP:REDIRECT are treated as policy anyway, the point still stands as a guideline much of it doesn't apply to many of the tools used by people. Pegasus1138Talk | Contribs | Email ---- 13:52, 26 April 2006 (UTC)[reply]
Sorry, again, I see this at guideline level, not at policy level. Guidelines need to be actionable, and I don't see why this one wouldn't be. Not all scripts are intended to increase speed of consecutive edits (e.g. the script run by AIDbot, to update a single page: it was never the intention of that script to "increase the number of updates" to that page). If an account not listed at WP:BOTS, runs a script that doesn't increase speed of consecutive edits, I don't see why that should be marked in the edit summary. If the account engages in repetitive edits, the semi-bot guideline would be actionable on it, without script-or-no-script discussion. The present guideline supports to be clear about scripts that are used, what is customary currently for the more elaborate auxiliary software types. It also reminds people that are using scripts that don't auto-generate edit-summary text that it is preferable they are clear about what they use. --Francis Schonken 14:47, 26 April 2006 (UTC)[reply]

v

Please help test Citation Tool[edit]

The tool (semi-bot) that I have been working on, Citation Tool has reached a usable and useful state, I believe. The purpose of this tool is several fold, but the main (and implemented) goal is the detection and guided correction of errors in m:Cite.php markup.

As of this exact moment, the tool does the correct diagnosis of two types of errors. By later today, it should also be able to propose specific modified text that corrects the errors (sometimes requiring operator decisions). The web page for the tool also links back to the edit page for a given corrected article. Notice that any modification made based on the advice of Citation Tool is made under the user's own WP username. The two types of problems currently identified are:

  1. Multiple <ref name=...> tags with the same name but different contents (hence hiding all but the first in the rendered page).
  2. Empty <ref name=...> tags that occur before ones with content. Same basic problem, but this is especially easy to inadvertantly create if articles are reorganized.

These type of errors seem to occur quite frequently "in the wild".

The proposed changes made by Citation Tool do not change the referencing style or technology used on a page (currently: plans are underway to aid insertion of Harvard references as an adjunct to footnotes, where a mixed style is appropriate). So as far as I can see, the changes proposed by the tool should be non-controversial. The only possible issue I can see is that editors might disagree about whether a currently hidden footnote content is or is not better than the one that had been visible; but that's a pretty regular editorial/content issue, per article.

Well... the other issue is that the tool might be buggy, since it hasn't been banged on by anyone other than me yet. That's why I'd appreciate some other people using it, and paying attention to results. If the diagnosis or proposed solution seems to be wrong for certain pages, that matter needs to be identified and fixed. Lulu of the Lotus-Eaters 21:41, 28 April 2006 (UTC)[reply]

Instruction creep?[edit]

Why do we even need this guideline? (I also have issues with the content, but even its existence seems pointless to me) People running automated programs on their account without appropriate safeguards already get blocked if the bot goes haywire, people who make disruptive edits using semi-auto software like AWB, popups or vandal fighter can already be blocked under the blocking policies that apply to editors. So how will having a specific guideline for the use of semi-auto edit programs be any more useful than, say, having a guideline for editing using a tabbed browser? Cynical 13:36, 3 May 2006 (UTC)[reply]

I assume the rationale is that it's one thing to make a "marginal" edit once: if it transpires to be a good idea/have consensus, then fair enough, if not, it's easily fixed. But to make essentially the same edit a hundred times is to potentially make a real nuisance if there turns out after the fact to be opposition to it, or even if there's simply interim consternation as to whether it's indicated. Whether this proposal is a needed, consensus-backed, clear or efficient way of expressing that is another matter entirely. Alai 22:37, 3 May 2006 (UTC)[reply]
If there is a later decision that the edits were in fact detrimental to Wikipedia, then 'semi-automatic' programs such as AWB can then be used to reverse the same edits. As well as the instruction creep problem, this also goes against WP:BOLD (which, admittedly, is not policy, but then neither would this proposal be even if it did achieve consensus). Cynical
I tend to think that the "nutshell" aspect should be factored into WP:BOLD in some fashion (the greater the possible nuisance, and the lower the reversibility, the more caution is indicated). The rest of this proposal I'd like to see the back of, for numerous reasons. Alai 02:43, 5 May 2006 (UTC)[reply]

Nutshell mismatch[edit]

A basic problem with this proposal is that the nutshell (which talks about serialisation, regardless of means) is entirely at odds with the contents, which is largely concerned with the means. As the title also strongly implies said means, I think the nutshell has to be reworked accordingly. Alai 17:33, 6 May 2006 (UTC)[reply]

True, it has to be reworked accordingly. But in what manner? --Siva1979Talk to me 18:11, 6 May 2006 (UTC)[reply]
By my reckoning, the proposal is about half method and half serialisation. Personaly, I think the 'nutshell' and serialisation bits of the proposal are fairly good, and that the method part should go. Until that happens, though, you're right - the 'nutshell' should reflect the page. Two suggestions:
  1. Only serialize edits using software which enhances the speed with which edits can be made when the edits are covered by a broad consensus (using a mash of words already on the page); or
  2. Only make serialized edits using speed-enhancing software when those edits are covered by a broad consensus (reworded a bit).
I prefer the second as better English. SeventyThree(Talk) 00:33, 7 May 2006 (UTC)[reply]
We're perhaps in danger of trying to work backwards from a putative solution, to a possible problem. It might be better to consult widely on the principle (whether that be the use of serialised edits as such, or use of software enhanced browsers), before banging away at the detailed text. Alai 03:15, 7 May 2006 (UTC)[reply]

I edited this as per the above, and was reverted. As the proposal is called "semi-bots", one might suppose it's saying something about software; one might also assume the same on the basis of the lengthy discussion of software in the proposal. This needs to be fixed one way or another (or via the third option of the "rejected" tag, if it's making no progress towards attracting any degree of consensus). Alai 04:57, 7 May 2006 (UTC)[reply]

These were my reasons (in short) for not keeping the software centered nutshell/definition, per my edit summary [9]: "Don't think focussing this on software a good idea. I'm not bothered whether people use software or not. Would lead to useless discussions."
  • Regarding "Don't think focussing this on software a good idea": when starting this I got loads of criticism from (semi-)bot software operators thinking I was trying to get at them. Which wasn't the case: I tried to do something about annoying, repetitive edits, for which the WP:BOTS guideline was too coarse as an instrument (while too focussed on software, so leading to stupid "I was NOT using software"..."No, you were!" type of discussions). Semi-bot is still appropriate as a name for people who start doing repetitive stuff, their actions then have something robot-like, so: SEMI-bot is not a misnomer in that case.
  • Regarding "I'm not bothered whether people use software or not" - really not. Someone doing beautiful things with a bot or otherwise software-assisted (and believe me, most people do beautiful things with auxiliary software), shouldn't even need to "declare" that software has been used, as far as I'm concerned. That's not the point. The whole point is: when it starts to be annoying, or inadvertedly disruptive (while a few edits of that kind wouldn't be), or errors start creeping in (the typical "systemic" kind of errors one gets from repetitive actions, humanly-supervised or not, and that differ from the "typical" one-off-always-different errors a non-repetitive human would make).
  • Regarding "Would lead to useless discussions": per the first point above. Really, I've seen some disputes of the kind "no, I was only using tabbed browsing", vs. "no, you were using software", which all are missing the point (and were one of the reasons why on a blue monday I started this semi-bots proposal). See also above on this page, I made some links to such discussions. The idea is that when someone comes accross a series of edits by another editor, they don't lose time deciding whether the semi-bots recommendations apply "while maybe no software was used", but get to the heart of what is the problem (or not) with the actual serialized edits, per the guidance offered.
So, that's a summary of my reasons. Differing reasons by others may be as valid... but as far as I'm concerned I'd still make the proposal less software centered, rather than make it more software-centered. --Francis Schonken 07:30, 7 May 2006 (UTC)[reply]
Either way, the nutshell should match the proposal. I'm going to be bold, and take out some of the more glaring software-specific text. I'll move any large sections onto the talk page, incase somebody wants to keep it as an essay or whatever. SeventyThree(Talk) 23:11, 7 May 2006 (UTC)[reply]
OK, that ended up being a bigger change than I expected. I've managed to reduce all of the parts mentioning bots/software to two paragraphs (!), largly by taking out unrelated sections. Below are the sections I pretty much completely removed:

Responsiveness[edit]

Operators of semi-bots (whether separate account or not) should be reachable and responsive on an en:wiki talk page. Removing remarks given about the semi-bot's behaviour before ascertaining that the poster of the remark considers the remark properly handled is considered the same as "not being responsive". Following on the posting of a remark on the appropriate user talk page, a response is expected within minutes of the next edit by the semi-bot. Not being responsive may lead to the blocking of the semi-bot account, for which the blocking admin should leave a note on the contact page for the semi-bot. Alternatively, and this is preferred where possible, the semi-bot software is temporarily disabled for that account, equally with an appropriate note to the semi-bot operator. For example, AWB has such functionality at Wikipedia:AutoWikiBrowser/CheckPage#Enabled users.

Separate account?[edit]

Unlike bots, semi-bot operators are not required nor even specifically encouraged to take a separate user account for semi-bot operations. Nor does the Wikipedia:Sock puppet guideline discourage the use of a second account for serialized operations.

So, the decision is up to the semi-bot operator. The reason for this section is to list pro's and con's for both approaches, in order to help a semi-bot operator to make his/her choice:

  • A separate account might be perceived as some kind of bot, with its disadvantages, e.g. bot accounts are sooner blocked than bot operator accounts if a bot starts to behave strangely. If a semi-bot and its operator share the same account, this would usually make sysops hold back from pre-emptive blocking (which is not a big issue when applied to a separate account).
  • If, on the long run, a semi-bot operator might want to request approval for bot status, it might be a good idea to start with a separate account, so that the behaviour of the account performing serialized operations is already known by the time of the bot account application (which would usually speed up the process of receiving approval as a bot for that account).
  • Reachability: think for yourself what would be the easiest way for wikipedians to contact you with regard to issues on the semi-bot operations: if separate accounts would make it take longer before you notice a message has been sent to you (e.g. while you're logged in with the bot account, and you don't receive notification of messages left on your operator account's talk page), this might be a contra-indication for having separate accounts.
  • Risk of being perceived as sockpuppeteering, e.g. forgetting to change login when expressing your opinion in a straw-poll may be ill-received.
  • Cleaner separation of tasks: glitches performed by a semi-bot that are properly handled don't reflect back as much on the operator: if the two accounts are not separated the "glitch" is more identified with the operator.
  • Starting as a semi-bot under your own account is certainly the less red tape solution.
  • Sometimes the auxiliary software (if any is used) gives an indication: most of the typical semi-bot software (e.g. anti-vandalism tools) is designed to be used on a single account. Typical bot software (e.g. py framework) is rather designed for a separate account (even when used as semi-bot).

If a semi-bot operator decides to use a separate account it is recommended not to use "bot" in the semi-bot's account name (in order not to confuse with bots that have a listed and agreed upon job description). Instead it is recommended to use an account name in the vein of:

(derivative of) user's account name + "Task"

Where "Task" can be either just the word task, or a word that indicates a task. For example linkcheck could be a "Task" name for a semi-bot that checks whether external links are still live.

Recommendations for auxiliary software developers[edit]

Development of auxiliary software is usually not as strongly supervised as the development of the features and implementation of the MediaWiki software itself. Some suggestions:

  • It's always possible to discuss ideas at Wikipedia:Village pump (for example in the "proposals" or "technical" section) or Meta-Wiki;
  • Be careful not to program anything that might easily lead users to perform actions that are unsupported by wikipedia's guidelines and policies. If that can't be avoided, at least give proper warnings in the software and/or be clear about such risks in the manual. In other words, try to make the tool as fool-proof as possible, taking account of e.g. the KISS principle and Murphy's law.
  • Preferably the software is copylefted compatible with wikipedia's GFDL and/or MediaWiki's GPL.

Examples[edit]

Semi-bot tools include (see also Wikipedia:Types of bots):


Large removals are a bad idea[edit]

There was a lot of worthwhile description taken out in the recent edits. I don't think the guideline should be paired down nearly so much. It's one thing to say the concern isn't strictly software itself, fair enough. But readers should still have some sense that it is likely to be autmated tools that are often associated with repetitive edits; and the stuff about advice on the use of semi-bots is important. LotLE×talk 03:32, 8 May 2006 (UTC)[reply]

Sorry about that - I didn't origionally intend to take out so much, but I got a bit carried away. I was in two minds about forking instead - if you think I've taken out too much, revert me or add some parts back in. I copied the sections to the talk page to make it a little easier to add back parts if somebody objected. SeventyThree(Talk) 03:58, 8 May 2006 (UTC)[reply]

Anyway, I revert to my last version (apart leaving out the "bot" definition of "non-humanly supervised software", which is wrong guideline/policy page). One half of me says, finally people start to feel at home in this guideline proposal, and start to collaborate, the other half of me says: let's now not get too rash either. The definition of what it is, is centered on repetitive stuff, but also includes typical semi-bot software; the recommendations of the guideline both regard things that have to do with serializing in general, and as well with practical recommendations regarding auxiliary software. It's supposed to be a practical guideline in the first place, and some of the practical stuff taken out by 73, was actively used by wikipedians when 73 decided to take it out. Really, the naming issue is a minor decision, after we get the content of this proposal as workable as we can get it. --Francis Schonken 06:35, 8 May 2006 (UTC)[reply]

I disagree with both your halves, Francis: that it's being edited to try and fix the more glaring problems is not evidence that it's anywhere near consensus; and your reversions of two different attempts to fix same, is just stalling the process further. If you really want guidelines on both things, please refactor it into two separate proposals. At this point I'm highly inclined to revert to either my last version, or to 73's last version; I'm not entirely sure (nor especially bothered) which, as either represent a significant improving clarification in the scope (admittedly in entirely different directions). Lulu, what was removed was hardly just giving "some sense" of the use of software tools (I'd suggest avoiding the term "automation", lest further confusion with actual bots creep in), it was scads of "essay" and "detailed legislation" written explicitly in terms of serialisation by software assistance. Alai 16:36, 8 May 2006 (UTC)[reply]

Tools and tool users[edit]

I've merged some of my chages back in, and they seem to have been accepted - good! I think the next move is to remove some of the stuff not relating to the guideline itself. What should go depends on the scope of the guideline. I would like to see the last two sections (Wikipedia:Semi-bots#Recommendations for semi-bot operators and Wikipedia:Semi-bots#Recommendations for auxiliary software developers) removed. They are interesting, and possibly good as an essay somewhere else, but they have nothing to do with serialised editing. The guideline is about serialised editing, which naturally overlaps with auxiliary software/semi-bots because they make it easier. What do people think? SeventyThree(Talk) 15:00, 10 May 2006 (UTC)[reply]

I wouldn't mind refactoring, but I'd like to see the conceptual connection maintained. Specifically I think these sections should move to a subpage of the main (proposed) guideline, maybe Wikipedia:Semi-bots/Software guidelines. One sentence pointing "down" to that discussion would be fine for the guideline, I think. This is a similar pattern to that followed in the discussions about footnotes and referencing, as well as to other guidelines. LotLE×talk 15:06, 10 May 2006 (UTC)[reply]
Footnotes seems different to me, from what I remember at the time and looking at the histories and talk. The pages (mostly separate pages, rather than subpages) were made in turn to give people a clean space in which to write a guideline to replace the then-current guideline. Also, they were mostly documenting different ways of making footnotes, and so were a lot closer in scope than this.
We've got to be clear about what's in this guideline and what's not. If you intend the "software guidelines" to be part of this guideline, then I think they should stay on this page. If they're to be part of a second, separate guideline (which I would support), then they need a different page not a subpage. If they're not going to be a guideline, then I'd prefer to put them on a separate page, call them an essay, and provide a link from here. SeventyThree(Talk) 23:05, 10 May 2006 (UTC)[reply]
Well, I didn't really write any of this guideline myself (maybe a few words of tweaking). So I didn't quite intend much anything. But I think it makes sense to include the software guidance in the guideline, or at least with a close conceptual relation such as a child page.
These issues just seem very related to me. Advising editors not to serialize contentious repetitive changes (without obtaining consenus) is certainly great advice. But since software tools often make such serialization much easier than it would be to do the same minus the tools, the advice kinda needs to filter out to the creators of the tools. Both parts are important, and interconnected, to good etiquette about serialization. LotLE×talk 01:56, 11 May 2006 (UTC)[reply]
By intend, I was refering to the suggestion of a subpage.
Given how difficult it is to tell if somebody's using some of the tools, I don't think we can make tools a major part of the guideline. It would make it too hard to enforce - guidelines have to be actionable. How about we try to get together a lead and main section which are only concerned with serialised editing, and don't mention the method used at all. Then have a different section/page concerning tools. I'm not sure how well that would work, but I feel that making a clean break between the two parts would make the former much more general and actionable. SeventyThree(Talk) 14:09, 11 May 2006 (UTC)[reply]
Hmmm... it sounded before like you didn't want a subpage, but something in a very different space. In practice, editors who make a lot of the same change will be using a software tool; but indeed, we can't really prove that, and it doesn't really matter anyway, at least not in terms of any disagreements other editors might have about the changes. Still, there seems like a big gulf between responsible and irresponsible tool creation, even if we don't necessarily have formal evidence about the tool creation/creator: a guideline isn't about verdicts and proofs necessarily, we also try to assume good faith, and think tool creators will experience insight when they read it.
Tools are a fuzzy boundary too. Sometimes when I work on a major change, I'll copy the whole article into my text editor. From there I'll make replace operations that would be difficult to make in a web browser text window, such as ones based on regular expression patterns. Or I'll use the Python interactive shell for a similar purpose. In practice, I don't save those steps for reuse, but it wouldn't be much work to do so. I don't think of my text editor as a semi-bot, but of course it has many features in common with them. Python shell? Well, again not, but it's close. Obviously, it's utterly pointless to try to complain against a "defendant" who claims that the thing they created isn't a "semi-bot" in some hypertechnical sense--but we don't have "defendants" here. The most we can hope is that software types will gain an understanding of consensus from reading the guideline. LotLE×talk 15:51, 11 May 2006 (UTC)[reply]

(heading back left) I really don't want a sub-page. I don't mind too much whether it ends up all-in-one or split into two different guidelines, but a subpage seems like a vague mess of both ideas.

Alai's edit to the nutshell (specificly mentioning software) was reverted, so I thought I'd try to remove most of the mentions and see where we ended up. I still think that the guideline could stand alone like that, with hardly a mention of tools. You're convincing me though - if the wording's right, it could work. SeventyThree(Talk) 21:00, 11 May 2006 (UTC)[reply]

Let me see if I can convince you back. :) I agree that there's a conceptual connection, but what's being proposed here is intended to be an "actionable guideline", not an essay on conceptually connected themes. If the action being considered relates to serial edits, then software use is neither here nor there (and the current title is inappropriate). It'd cover, for example, the ever-popular mass-page-moves of US roadgeek fame, which would (or at least, might) make conceptual sense for the current "nutshell", without the distractions of whether special software was involved (which I'm assuming it wasn't). The issue there is simply a sequence of edits, and labelling someone's account a "semi-bot" is just to obfuscate matters with misleading and misapplied jargon.
Guidance as regards openly-advertised, generally available software (which is as noted, really all that can be "legislated for", as distinct from the resultant editing) is a sensible idea, but it's an entirely different scope of action (and one which is not covered by the current nutshell). Conceptual connections are best served by distinct proposals, linked where appropriate, not a single proposal with scope-creep. Alai 22:08, 16 May 2006 (UTC)[reply]

Proposal abandoned?[edit]

It seems that there hasn't been much discussion here recently. If nobody objects, I will orphan this page and add the {{historical}} tag. ~MDD4696 14:53, 26 June 2006 (UTC)[reply]

I strongly object. LotLE×talk 16:37, 26 June 2006 (UTC)[reply]
Although I can't say at this point that it has been positively proven that this guideline can't be missed, maybe still somewhat too early to archive. Anyway, importing this problem that has apparently popped up again at wikipedia talk:categorization of people over the last 24h:

The damage that was done by alphabeticizing bots

As I categorize more articles, I see more and more clearer how much careful work was casually wrecked by the alphabeticising bots. There are many examples where people added hidden text to encourage people to sort the categories (nearly always with occupational categories at the top) which have been made a nonsense of the bots. Then there are all the cases where hidden comments have been added to explain individual categories, but these have been sundered from the relevant category. This applies to hundreds of Oscar winners and a good number of other articles. Chicheley 12:42, 26 June 2006 (UTC)[reply]

There was discussion at Wikipedia talk:Categorization (now archived) about alphabetizing of categories. The consensus seemed to be that there was no policy to alphabetize, and we requested on the AWB talk page that it not be used. However, once something is in a piece of software, it is hard to get people to refrain from using it. Perhaps the maintainers of AWB could be persuaded to do a new version that doesn't have it. --Samuel Wantman 19:21, 26 June 2006 (UTC)[reply]
From what you say there also was no consensus not to alphabetize, correct? So this means that consensus must be gained on each article? The archive link goes to a page which does not seem to have archives past mid April and I can not find this discussion. Thanks. Doc 21:54, 26 June 2006 (UTC)[reply]

Well, indeed maybe we could use the semi-bot proposal as a support to ask the AWB people to remove the "category alphabetisation" feature from the software. --Francis Schonken 00:50, 27 June 2006 (UTC)[reply]

The alphabetising option was removed a long time ago, as a result of the said discussion, no policy/guideline was needed. Martin 08:46, 27 June 2006 (UTC)[reply]

If this proposal were seen to be going anywhere, then that would be fine and dandy; the trouble is that it's not under active revision, there's no process underway to establish consensus, and indeed both of these have been actively resisted. So I can't see that it can accurately be described as anything other than historical/rejected, at least unless those things change in relatively short order. I'm still of the belief that it should be rescoped, and possibly split, for the sakes of clarity and manageability: there's issues to do with "serialisation" that have little to do with software tools, and issues to do with software that have little to do with editing speedy, etc. Like eating the proverbial elephant, this is likely to be more feasible a small bit at a time. Alai 01:15, 2 July 2006 (UTC)[reply]

Well, and then now Bobblewik's delinking of dates has come up again.[10] Old system (per prior discussion, while WP:BOTS seems to have no grip on the script tool Bobblewik uses for the disruption): block Bobblewik, doubling the block time every time Bobblewik does it again. I'm still waiting to see whether Wikipedia:Semi-bots could give a less stressful solution. --Francis Schonken 10:40, 2 July 2006 (UTC)[reply]
I think a significantly less broad version than the current proposal would deal with Bobblwikish issues. A statement that "large number of similar controversial edits, or very large numbers of excessively minor edits may be considered disruption" would pretty much cover it. Alai 18:54, 2 July 2006 (UTC)[reply]
Doesn't cover undoing of massive edits to be performed by the semi-bot operator. A block doesn't solve that (and leaves the work to others). The present proposal leaves that option open to the "perpetrator" in order to avoid block. I haven't seen this work yet, but maybe this would only work if the proposal becomes guideline.
Also, for example, the recommendations for semi-bot software developers are not covered by your simplified version proposal. And I think them useful. --Francis Schonken 19:27, 2 July 2006 (UTC)[reply]
If they required "massive undoing", then it seems fairly clear they were controversial, I would think. And I think you're misconstruing "may be considered disruption", as "must be blocked", and thus somehow prohibiting any other resolution, which is far from what I'd suggest. Certainly it doesn't require the software-specific stuff to cover such cases (though some of it I'd support under separate cover, esp. the edit summaries stuff, in regard to which I've recently encountered one "semi-bot" that doesn't self-identify in any way). Nevertheless, if you're going to insist on "all or nothing", put me down for "nothing". Alai 00:14, 3 July 2006 (UTC)[reply]

What's the problem with accounts using edit-accelerating auxiliary software?[edit]

What's the problem with

For the practicability of this guideline, any user account using software which enhances the speed with which edits can be made (that is: faster than editing exclusively with a standard webbrowser installation), and that is not listed at Wikipedia:Bots, can be labeled a semi-bot.

in the definitions section?

I have no problem with this. --Francis Schonken 09:44, 28 July 2006 (UTC)[reply]

It's far to broad. Not enforceable. Cannot be defined. What is a standard webbrowser? Given that this proposal here has already been rejected this discussion is moot anyway. Francis: how long will it take until you accept the fact that this proposal has not aquired consensus? Do we have to have such proposals forever, until those that said they disagree with ignore it? You still keep revert warring your personal POV into it. How long do we have to have this on our watchlist to make sure you do not slap a guideline tag once again onto it outside consensus? Francis, stop it now. --Ligulem 09:52, 28 July 2006 (UTC)[reply]
It is absurdly vague and broad. Tabs in a browser can speed up edits considerably, so, since IE is the most common browser by far, any user who uses Firefox is a semi-bot. Any user of popups is a semi-bot. And in most cases, the proposal has nothing to do with these users. Being able to speed up edits is not necessarily related to serializing edits. Even if we agreed on this definition, everyone would be confused about it, as most editors are with WP:SOCK, which labels every alternate account (including bots) as a sock puppet. --Philosophus T 10:32, 28 July 2006 (UTC)[reply]

My recent edit[edit]

I only intended to remove the link to Radiokirk's copy of my script, as it doesn't seem helpful (there are numerous copies of my tools on wikipedia, some with minor variations and some verbatim copies). I seem to have edited an old revision by mistake, though, but I don't have any particular views on the skirmish currently taking place. Lupin|talk|popups 13:25, 28 July 2006 (UTC)[reply]

Personal attack?[edit]

The Page moves section feels a bit like a personal attack to me. --HiddenKnowledge (talk) 00:09, 23 November 2014 (UTC)[reply]