Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Remove ability for new users to create other accounts

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

---

For background, see [1] - it is a common MO of a number of serial vandals to create one account, then use that account to mass-create a bunch of "sleeper" accounts. These accounts have no log entries of their own, which makes detecting them through Checkuser impossible until they are used, thus allowing the vandals to continue attacking the site after the main account is blocked. Even aside from these nefarious purposes, I have noticed a number of new users create an account, get confused, and accidentally create another account. Now they have two accounts, and in rare occasions get blocked as sockpuppets because they start editing with the first, then later log into the second mistakenly thinking it was the one they created in the first place.

To this end, I'd like to propose that the ability for non-autoconfirmed users to create accounts be revoked. This may seem backwards, as anonymous users can still make accounts, but in the first example, the serial vandal would have to make a log entry in the checkuser database for all of the accounts, making them infinitely easier to locate and block all at once. In the second case, the new user may be confused by the "access denied" message, but hopefully with the use of Mediawiki messages, we can make it clear that it's because they already created an account and are free to edit. Thoughts, comments, and concerns are welcome. Hersfold ^(t/a/c) 01:14, 31 August 2011 (UTC)

It sounds like a good idea but I'm just wondering: once a person sees they can't create multiple accounts while logged in, wouldn't it be just as simple for them to log out and then create whatever number of accounts they'd like to, logging off in between each creation? Maybe the idea is still just as viable because people won't think of this workaround, so it will still be preventative, but I'm just wondering about the mechanics.--Fuhghettaboutit (talk) 01:24, 31 August 2011 (UTC)

• I saw the ANI thread that led to this proposal, which does sound reasonable. Are there any potential pitfalls of it, besides the "access denied" issue you already raised? I presume the situation of multiple people on one IP address (such as library access, university access) would not have a problem because they'd individually be registering accounts from that IP, right? LadyofShalott 01:28, 31 August 2011 (UTC)

I don't know the Checkuser tools but I suppose you know that public logs show who created an account and which other accounts they have created. For example, [2] shows that User:Kentdorfman was created by Hersfold, and [3] shows other accounts created by Hersfold. If it doesn't exist already then somebody could maybe make a one-click script to get these logs from a user page, or display them by default. But if you say the proposal would make it much easier for Checkusers to find abuse then I believe you. PrimeHunter (talk) 01:59, 31 August 2011 (UTC)

• From a technical point of view, it would be easy to modify the throttle limit for account creations from the current 6 accounts to 1 every 24 hours, however, this would place users at WP:ACC at a severe disadvantage. Also, I'm not sure if it would be technically possible to disallow account creations by new users. If the createaccount right was restricted in the user group, then anyone in the user group would be unable to create accounts - regardless of whether or not the user had access to the right as part of another user group. To do this, new users would need to be automatically put in a separate group which would then be removed when they became autoconfirmed... and that would take time and effort on part of the devs. Ajraddatz (Talk) 04:16, 31 August 2011 (UTC)
• For it to stop the primary offender, we'll need both a ban on new accounts creating accounts and a lower throttle; 2 or 3 for non-ACC people would seem reasonable. The above-linked banned user won't be any less difficult to spot, as anyone who's seen him knows, it'll just make it harder for him. The Blade of the Northern Lights (話して下さい) 06:05, 31 August 2011 (UTC)I must admit, though, I had to laugh when I saw User:Cloudy with a Chance of Mascots; in a strange way, it can be entertaining.

I just wanted to snipe my 2 cents in here too. I also agree that there is no need for someone to be able to create an army of additional accounts on day one. I think the idea of limiting this ability to Autoconfirmed users is good as is the limitation of only creating 1 account per 24 hours. Additionally, it should be possible to write a sql report against the database to see if a user has created another User account and in particular if they haev created multiples. It may even be possible to determine if those accounts have contributed. Let me do some asking around and see if that is possible. --Kumioko (talk) 14:51, 31 August 2011 (UTC)

This seems like a sensible step forward - there is no good reason for non-auto-confirmed users to be able to create multiple accounts. -- Eraserhead1 <talk> 20:37, 31 August 2011 (UTC)

I see this a good direction to explore further. I am puzzled at the above comment that users at WP:ACC would be disadvantaged by this change. I assume that the people who handle requests at ACC have the ability to create accounts in large numbers if they are needed. Also, why would the creation of a new account by a registered user not show up in their own log? Can't all users (not just checkusers) see what other accounts someone has created? EdJohnston (talk) 20:54, 31 August 2011 (UTC)

They can (and that's one of the reasons it's so easy to nail MascotGuy socks), but new users probably don't know how to check that. I see that happen with some frequency when I monitor the new user log; a person will join as Davidsmith, then (for instance) create the account David smith, because they thought that's what their account was named in the first place (there are a couple scenarios where that might happen), and they end up confusing themselves. Our logs aren't exactly easy to find if you don't know how to get to them, so although it shows up there, a new user won't realize what they accidentally did. The Blade of the Northern Lights (話して下さい) 22:43, 31 August 2011 (UTC)

Only those with the accountcreator flag are free of rate limits, so new contributors to the ACC would be at a disadvantage. Ajraddatz (Talk) 23:09, 31 August 2011 (UTC)

• Why not improve the logging so that the account creations appear in the log that the checkuser reviews? Seems overkill to restrict the ability when the real problem seems to be the lack of the log entry for the Checkusers to see. Monty₈₄₅ 22:51, 31 August 2011 (UTC)

  How so? What do you mean by appearing in the log that the checkuser reviews? Ajraddatz (Talk) 23:09, 31 August 2011 (UTC)

  • I think it'd be a simple log that shows each account creation with either a user name or IP address, restrict access to checkuser only. If someone starts making a lot of enteries then the check user will be able to see it easily also by checking thru the log they can identify every account easily. Gnangarra 14:08, 1 September 2011 (UTC)
    • Special:Log/newusers? Ajraddatz (Talk) 15:51, 1 September 2011 (UTC)

      The rationale for the change was in part: These accounts have no log entries of their own, which makes detecting them through Checkuser impossible until they are used fix that and restricting creation is unnecessary as I understand it. Monty₈₄₅ 16:09, 1 September 2011 (UTC)

• I would support cutting the limit of accounts that can be created by new accounts (or non autoconfirmed accounts, whichever) to one. TNXMan 14:43, 1 September 2011 (UTC)
• I echo Tnxman above for non-autoconfirmed accounts. The Blade of the Northern Lights (話して下さい) 16:43, 1 September 2011 (UTC)

• Keep in mind that the reason why multiple accounts are "authorized" is due to the fact that the only check here is to see if the same IP address is being used to create multiple accounts. For users at something like an internet cafe, at a school, or some other activity where multiple people can be using the same computers and/or ip address, putting a throttle on new account creation actually can keep some legitimate users from being able to create accounts. Yes, it would be a rare exception for when this situation would happen (such as a classroom assignment for some tech class of non-Wikimedia users simultaneously creating accounts in a short period of time), and the real question would be to ask how many new users with genuine accounts would this impact? It would not be zero people, as I know this has happened, but my experience is that such efforts are usually quite rare, on the order of once or twice per month if I was being extremely generous (more like a couple of times per year). In this exceedingly rare situation, an instructor could also get some cooperation from an admin to help out in terms of simply creating the accounts as well, so I don't think it is necessarily the end of the world. --Robert Horning (talk) 17:50, 1 September 2011 (UTC)

• If the root problem here is that these "secondarily created" accounts don't get log entries, surely it would be just as easy to develop a way to make this be logged in the same fashion as normal account creation? Shimgray | talk | 17:58, 1 September 2011 (UTC)
• I think there are two issues getting confused here. One is the ability to track account creations with the checkuser tool. Let's leave that aside for the moment.
• The bigger issue here, I think, is someone registering an account and then using that new account to create multiple other accounts (not multiple people registering one account on the same IP address or anything like that). There is simply no reason for someone to create an account, then use that account to create multiple other accounts (see this log entry). TNXMan 18:04, 1 September 2011 (UTC)

  That's the problem I have as well. Anyone who watches the new user log will have seen innumerable similar log entries, and the way it's set up now he's allowed to multiply x6 (this is what can be done with the current throttle), making it that much more annoying because admins have to block all the accounts and non-admins can't do anything but report, watch, and wait. I can't think of a good reason why a newly registered account would need to create more than one new account (and then only for things like softerblocked usernames and the like). The Blade of the Northern Lights (話して下さい) 19:14, 1 September 2011 (UTC)

For what its worth I found out that it is possible to create a report that would tell if someone used their account to create another account even if that account has never been used. I don't know how useful it would be since technically its allowed until they do something stupid with it but I thought I would drop a note and let you know. --Kumioko (talk) 19:34, 1 September 2011 (UTC)

I have thought that Special:Log/newusers was created many years ago. You seems to be unaware of it. Ruslik_Zero 20:00, 2 September 2011 (UTC)

RfC: Lower the limit of account creation in a 24 hour period by non-autoconfirmed accounts

A discussion at WP:ANI on sockpuppets creating other sockpuppets seems to have consensus to lower this limit. The reason not to eliminate this ability altogether is to allow for a bad username to be changed by the user as they familiarize with WP:USERNAME policy. There are two proposals, one to lower the limit for non-autoconfirmed users to two accounts per 24 hour period, the other to one account per 24 period. Cerejota (talk) 19:43, 1 September 2011 (UTC) moved from ANI as per WP:SNOW, only moved !vote, not discussion on moving here--Cerejota (talk) 20:35, 1 September 2011 (UTC)

• Two accounts - Otherwise, inappropriately named accounts cannot create a per-policy account except by waiting 24 hours. Reaper Eternal (talk) 20:03, 1 September 2011 (UTC)
• Users should be permitted to create one original account and one additional account, if needed. TNXMan 20:49, 1 September 2011 (UTC)
• What Tnxman says above. The Blade of the Northern Lights (話して下さい) 21:05, 1 September 2011 (UTC)
• Tnxman's proposal sounds sensible. -- Eraserhead1 <talk> 21:10, 1 September 2011 (UTC)
• Agree with Tnxman307, there's a legitimate reason for creating one additional account (if a person is soft-blocked for username violation but encouraged to create a new account) but the only reason I see to create more accounts is sock-puppetry. -- Atama頭 22:52, 1 September 2011 (UTC)
• Two accounts per twenty four hours, to allow newbies to ACC to be able to do stuff and so that inappropriate usernames can make a new account. Ajraddatz (Talk) 23:18, 1 September 2011 (UTC)
• Forgot to !vote, lol: yeah what Tnxman said for the reasons Atama said.--Cerejota (talk) 23:20, 1 September 2011 (UTC)
• One original and one additional only per Tnxman Beyond My Ken (talk) 01:39, 2 September 2011 (UTC)
• Two accounts in 24 hours per Tnxman. EdJohnston (talk) 01:45, 2 September 2011 (UTC)
• Comment - Although the title of this section mentions non-autoconfirmed users, it doesn't state that in the body of the text. Not trying to be nit-picky, but would somebody mind adding non-autoconfirmed to the body of the text so that this proposal doesn't inadvertently impact the Account Creation Team? Thanks in advance. - Hydroxonium (T•C•V) 04:21, 2 September 2011 (UTC)

 Done--Cerejota (talk) 04:34, 2 September 2011 (UTC)

• Oppose. Another mindless proposal that will only serve to turn Wikipedia into a club with restricted access. I also do not understand why the above proposal was discussed for only one day before a consensus was declared? And why are we now asked to determine an exact number if there was no consensus above? There are also doubts that it is technically feasible to do. Ruslik_Zero 19:55, 2 September 2011 (UTC)
  • As a developer/hacker familiar with MediaWiki, I can assure you that it's feasible. — Kudu ^~I/O~ 22:46, 8 September 2011 (UTC)
• Two accounts an original, and a rename for an inappropriate first try. Should the individual screw up a second time it's not hard for an admin or accountcreater to give them a hand. For that matter, it should be two accounts per 24 hours for ALL individuals without the admin/accountcreator flag, but that's another discussion for another day. N419BH 20:02, 2 September 2011 (UTC)
• Oppose, don't see evidence that the vandal situation is out of control enough to inconvenience anyone. Per WP:DENY, we don't make policy to deal with single vandals anyway. —Kusma (t·c) 20:08, 2 September 2011 (UTC)
  • I respectfully disagree that is not a problem. TNXMan 20:34, 2 September 2011 (UTC)
    • Yeah I think we are editing different wikipedias :)--Cerejota (talk) 20:46, 2 September 2011 (UTC)
  • Kusma, we're not talking about a "slight vandal" here; read this, and watch the new user log for a couple of days. There are others, but he's the primary annoyance. Frankly, this should have been done years ago. The Blade of the Northern Lights (話して下さい) 22:43, 2 September 2011 (UTC)
• Two accounts seems very reasonable to me. — AlexSm 23:26, 2 September 2011 (UTC)
• Two accounts per Tnxman & others in support.--JayJasper (talk) 23:37, 2 September 2011 (UTC)
• Two accounts per Tnxman et al. If they need more (how often does that happen?) they can ask an admin for assistance. Herostratus (talk) 02:52, 3 September 2011 (UTC)
• weak oppose I understand the problem but the discussion here seems to fall into the category of "I just made one account here and I'm fine". We should be careful creating strict technical limits on the basis of a sampling of long term editors alone. Protonk (talk) 22:09, 3 September 2011 (UTC)
• Two accounts. Not sure this is really a common problem, but two accounts seems pretty common-sensical to me. Andrew Lenahan - Starblind 02:09, 5 September 2011 (UTC)
• Two accounts Makes sense to me. -- Donald Albury 11:17, 6 September 2011 (UTC)
• Oppose per Ruslik0. Perhaps this specific vandal's behaviour is annoying, but this would be weird even to document - how to explain why IPs may create up to 6 accounts per day, but registered users may only create one? Makes no sense to me. As an active account creator, I can also say the ACC process isn't pleasurable and should be avoided within reason when it's possible. — Kudu ^~I/O~ 22:51, 8 September 2011 (UTC)
• Two seems fine, although consideration should be given to placing a similar restriction against IPs per KuduIO. Stifle (talk) 13:07, 14 September 2011 (UTC)
• Oppose. I am not convinced that anything is broken. This measure would only force vandals to log out before creating many sock puppets, making those which are not currently doing so much harder to spot/verify for non-privileged users. If the checkuser tools don't provide this information, then the checkuser tools should be fixed, not the servers. Hans Adler 07:10, 16 September 2011 (UTC)
• Strong support - I spend a lot of time fighting vandalism, and in the case of persistent vandalism cases (Holy Land USA is a good example) this would have been a mitigant. People are lazy, and like other "soft deterrents" this would be a curb. One account a day is plenty. Best, Markvs88 (talk) 13:03, 16 September 2011 (UTC)
• Two accounts is plenty. bd2412 T 13:06, 16 September 2011 (UTC)
• Oppose per Protonk. Ironholds (talk) 13:07, 4 October 2011 (UTC)

How about treating this like aspirin?

Is the issue really # of accounts in 24 hours or # of accounts in a short period of time? What if we had a limit of 6 accounts per day but 2 per hour? Or even beyond that, 2 per hour, 6 per day and 12 per week? Protonk (talk) 04:36, 2 September 2011 (UTC)

But why do new accounts/non autoconfirmed users need to create that many accounts? I just don't see what anyone would do with that many accounts. TNXMan 11:31, 2 September 2011 (UTC)

Will be teaching a class of medical students coming up. They will all be creating new accounts from a single IP. Would this proposal interfere with that? Doc James (talk · contribs · email) 11:43, 2 September 2011 (UTC)

No, this only affects users who create an account, then use that account to make more accounts. Editors that use one IP to make multiple accounts, per your example, would be fine. TNXMan 13:13, 2 September 2011 (UTC)

I can think of a few reasons, but my point is the restrictions should match our goals. It doesn't need to be 6 per day but it is pointless to just say "well no one should need that many accounts." I'm just suggesting a solution which nets the same benefits but keeps an overall rate limit closer to the old one so we don't curtail legitimate use. Protonk (talk) 15:37, 2 September 2011 (UTC)

• OK, a few things. First, Protonk, what you suggest is possible (I think), but honestly is it needed? I think that 2 per day would be fine, no real need to make it more complicated from there. Doc James, yes this would affect you (and Tnxman you are wrong, the reduced limit applies for the IP and not accounts), but you can request temporary accountcreator flag at WP:RFR to allow you to bypass the rate limit. Ajraddatz (Talk) 20:28, 2 September 2011 (UTC)

I want to know a single hypothetical or real scenario for which a non-autoconfirmed user might want to create six accounts a day. Name just one. I have a rather wild imagination and I cant think of one other than puppetfarming. Autoconfirmed users do have at least one reason, which is to help the article creation team, but even then that's a right.--Cerejota (talk) 23:49, 2 September 2011 (UTC)

A professor creating accounts for his students. It's happened before, several times. We've always had to use the accountcreator right for that, though. And puppet farming is stupid if you create it from your same account. Then it's logged, and what's the point of logging your sockpuppetey? /ƒETCHCOMMS/ 15:49, 3 September 2011 (UTC)

Tell that to this guy, then; he's been doing that since 2004. He seems to just like doing it, and the throttle now lets him do this, which is 300% the annoyance compared to lowering the threshold to 2 accounts. And he does this at least a few times a day. The Blade of the Northern Lights (話して下さい) 17:21, 3 September 2011 (UTC)

I am not annoyed by MG. If you are, it is your problem. Do not try to solve it at the expense of others. Ruslik_Zero 18:13, 3 September 2011 (UTC)

That you aren't involved in fixing the damage he creates is your problem; don't foist your laziness on those of us who are trying to do something about it. Give me one good reason why a new editor would need to create 6 accounts. The Blade of the Northern Lights (話して下さい) 18:20, 3 September 2011 (UTC)

The bottom line is there is no legitimate reason for anyone except an accountcreator or sysop to need the ability to create six accounts in one day. The only example of a need for more than two that has been thus far brought up is a professor creating accounts for students, and this requires the accountcreator anyway. N419BH 18:32, 3 September 2011 (UTC)

The Blade of the Northern Lights, that reason was provided several lines above your comment, but you seem to have ignored it. /ƒETCHCOMMS/ 03:57, 4 September 2011 (UTC)

Well a higher account limit would allow for professors to make accounts (or the students themselves, if the computer lab parcels out one IP for dozens of computers) without being dragged through PERM or ACC. Both processes are (no offense to participants there) a pain in the ass. Protonk (talk) 22:07, 3 September 2011 (UTC)

Okay so if I need to create a hundred accounts in the span of a few minutes for a workship at McMaster [4] how do I go about doing this again? Will I need to create them myself and then hand them out? Doc James (talk · contribs · email) 05:30, 4 September 2011 (UTC)

In your case, you should be fine, as you're an admin. For others, it shouldn't be too hard to go through the ACC people; if this is implemented, we'll of course want to make ACC easier to find. Perhaps a note in the login window about it would be good. That is the only reason I can think of a new user would need to create so many accounts, and we have a way of doing it that won't open us up to the annoyance of malicious users doing it. @Fetchomms; I didn't ignore it, I merely think that our ACC process can already handle it, and new users should arguably go through it already. The Blade of the Northern Lights (話して下さい) 13:38, 4 September 2011 (UTC)

I don't know if you've used the ACC system before (as a volunteer, not applying for an account) but it's a bit of a hassle if we get a bunch of requests at once, to check that they're all from the same IP, then create them, and then tell the requesters to check their email for a password, etc., etc. This could be addressed if there was a better way to request accountcreator (and if the account creation limit was displayed more prominently somewhere for professors/teachers/etc. to see), but it's still annoying. It would also mean that basically every ACC volunteer will get the accountcreator right, which has the side effect of being able to edit editnotices (unless they changed that), and people have messed around with that ability before. Anyway, MascotGuy won't stop creating accounts if there's a lower limit; it just means a minute saved for admins blocking them. But he's so easy to detect there's no real problem there. /ƒETCHCOMMS/ 19:20, 4 September 2011 (UTC)

It seems he'd not the only one doing this at the moment; see [5]. The Blade of the Northern Lights (話して下さい) 20:23, 4 September 2011 (UTC)

Sorry if I'm missing something, but all those problematic usernames weren't created by other accounts as far as I can see ... /ƒETCHCOMMS/ 16:40, 5 September 2011 (UTC)

No, that's me not thinking straight. The Blade of the Northern Lights (話して下さい) 18:04, 5 September 2011 (UTC)

IPs would still be limited by this throttle. This would also slow down this kind of crap. Reaper Eternal (talk) 12:19, 9 September 2011 (UTC)

Is it possible to reduce the timeframe from 24 hours along with account creation, say perhaps 12 hours or similar? You can argue that would have the same effect in stopping a good amount of disruption as with 24 but would minimize much of the collateral damage caused. –MuZemike 18:23, 4 September 2011 (UTC)

It's possible. — Kudu ^~I/O~ 23:08, 8 September 2011 (UTC)

• Can someone clarify for me - are we targeting an actual problem here? Yes, MascotGuy is annoying. He's also just one person - last time I checked, we didn't make technical changes which affected every new user based on one person, or, for that matter, on "it makes my life a bit easier, and that's the only concern" - although some of the people I see in this discussion seem to have a track record of believing that things work that way. Ironholds (talk) 04:43, 4 October 2011 (UTC)

  Reaper Eternal linked to another vandal who seems to like mass account creation, and I've seen this happen elsewhere too (a whole series of accounts named User:Tim Pawlenty's DNA, User:John Boehner's DNA, and so on with various Republican politicians' names). Yes, MascotGuy is the primary annoyance and the most visibly obvious one, but it's not just him. And finally, I'm pretty sure Filter 360 was set up last summer to help prevent one particular IP-hopping user from spamming something, which was configured to nail IPs and non-autoconfirmed users. The Blade of the Northern Lights (話して下さい)

  So...three. You're restricting account creation to deal with three people, one of whom, by your explanation, seems to have such an obvious modus operandi that an edit filter would work a lot better. Ironholds (talk) 21:56, 4 October 2011 (UTC)

  The examples were meant to be demonstrative, not exhaustive, but regardless I'd be fine with simply making an edit filter to handle it. I don't much care how, more that it gets done in some form. The Blade of the Northern Lights (話して下さい) 03:41, 5 October 2011 (UTC)

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

Content dispute resolution

A breakdown of content dispute resolution processes. Two diagrams discuss how content dispute resolution was done in the past and how it is done at present, with two further diagrams outlining potential shuffles of the DR hierarchy.

This isn't the first time I've been here recently. Back in June I proposed the creation of the dispute resolution noticeboard, a way of getting many eyes on a dispute and coming to a quick resolution as opposed to something like MedCab or an RFC. Not to toot my own horn, but it has been reasonably successful thus far. Since then, I've been discussing proposed changes to the Mediation Cabal (see discussion) to make it more of an intermediate option as opposed to how things are at present (refer to diagram).

Resolution process for content and conduct issues at present

Additionally, it's made me think of the issues that content dispute resolution faces at times. Conduct issues have a pretty clear cut method of resolution, whereas content disputes have no lasting resolution. Consensus can change, and that's important. At the same time, there have been a select few disputes in the past that have gone through conventional DR methods numerous amount of times, and have ended up at ArbCom, often because of conduct issues, but at times topic bans or discretionary sanctions don't have the desired effect and the issues with the content continue. Senkaku Islands, Ireland article names, Eastern European disputes and Palestine-Israel articles are a few examples of disputes that have been through the DR processes endlessly both at present and in the past.

This is not a new idea. It's been proposed in the past, with Wikipedia:Community enforceable mediation, there was some discussion of it at an RFC on content DR back in 2008, and several variants of the idea for binding resolution of content disputes are littered over userspace, Two examples of this are here and here. I don't think that such a committee or body should be utilised lightly, it should only be done when all other methods of dispute resolution has failed. Perhaps it could be used after a case is closed as unresolved by the Mediation Committee. Perhaps a dispute would be referred there by the Arbitration Committee. Or perhaps there's another idea completely. I don't have any concrete ideas as of yet, I do think that any potential resolutions or decisions by this, well, for now let's call it "content ArbCom" should have time limits and be open to amendments if situations change vastly within the dispute, but would be ideal for highly charged disputes such as the ones I've listed above, and would appreciate input from the community on this. Thanks. Steven Zhang ^{The clock is ticking....} 01:00, 29 September 2011 (UTC)

Since one of the referenced userspace drafts is mine, I'm obviously in favor of the idea. While my version is a bit rule-intense, its goal is to make content arbitration a kind of enforceable-RFC which requires a prior attempt at RFC and DR, attempts to make a last-ditch attempt to draw in as much community participation in the final outcome as possible, and only allows the arbitrators to make a decision if the community fails to come to consensus about the content, saying in effect: "Hey, community - trout slap - if you don't decide this, it's going to be decided for you: Do you really want that to happen?" Though it's not mentioned in my draft, I would hope that filings with this committee would get the publicity, such as ongoing reporting in the Signpost, as do ArbCom proceedings so as to draw in as many editors as possible and avoid committee-only decisions. Whether by community consensus or committee decision, decision at this forum would determine the matter for the time being and would be enforceable. Best regards, TransporterMan (TALK) 14:05, 29 September 2011 (UTC)

Just rename Wikipedia:Administrators' noticeboard/Incidents to Wikipedia:Community forum, because that is all that is. Moreover, I question whether or not "mediation" is suitable in an open wiki environment (as opposed to MedCom, which is more closed). –MuZemike 23:01, 1 October 2011 (UTC)

• We already have a last resort for content disputes. It's called ArbCom. Not sure what the point is here, but it seems to ignore the fact that behavioral and content issues often go hand in hand, therefore it makes sense to have one body that is authorized to deal with both. Beeblebrox (talk) 23:51, 1 October 2011 (UTC)

• • No, not really. I'm actually bringing this here partly on the suggestion of an arbitrator (see the Abortion workshop). ArbCom don't issue decisions on content. I agree that in 99% of cases there shouldn't be a "binding" decision in regards to content, but for the rare cases where continuous discussion is damaging to the community (see the list of cases I linked to) there should be a method to resolve the disputes, at least for a period of time (like the Ireland article names dispute). I have no concrete ideas at present, but think we should have a serious discussion about it instead of throwing ideas out pretty much straight away. If ArbCom deals with content disputes, why are so many issues sent around the loop too often without resolution. At least think about it. Steven Zhang ^{The clock is ticking....} 00:08, 2 October 2011 (UTC)

Ok, i see where you are coming from, they make decisions about how editors in dispute are to behave, but you are right that they don't usually wade into the dispute itself. I guess I'd like to see a more solid idea of how this would work. Beeblebrox (talk) 18:28, 2 October 2011 (UTC)

There are two possible ways we could do this. Either a dispute goes through the content dispute hierarchy first (Talk page, DRN/3O/MedCab or MedCom) and then ArbCom who will look at any conduct issues and refer any unresolved content issues to this "content committee" or it could be a step taken directly after a MedCab/MedCom case, with strict requirements for the dispute so the new committee doesn't become a free-for-all (Serious discussion must have happened for an extended period of time and all options of resolution have been tried without success.) A modified version of User:TransporterMan/Sandbox/3 may be a starting point, out of which we can mould a more of a solid proposal. Steven Zhang ^{The clock is ticking....} 02:40, 3 October 2011 (UTC)

• I don't think there is a problem here to solve. Content issues, devoid of editorial issues, should be dealt with by: 1) Editing, 2) talk page, 3) WP:3O, 4) WP:RFC. The higher number should be seen as supporting the lower number, with solutions only ever obtained via #1. Perhaps there is room for some structure for RFC? There are various noticeboards that can support, and I think that committed tendentious editors should be restricted in editing in the problem area without reference to the content issue. --SmokeyJoe (talk) 03:13, 4 October 2011 (UTC)

• • Part of the reason I brought it here was the Senkaku Islands dispute which has been through content DR processes several times over. If a dispute is still unresolved after 2-3 years of conventional DR, we need something new to fix that. Our standard processes also have no way of dealing with civil POV pushing. Is this a radical idea? Of course. But I think by the info I listed at the top of this section, it's needed, at least for those once a year issues that warrant it. Steven Zhang ^{The clock is ticking....} 03:29, 4 October 2011 (UTC)

• I agree with the idea of having a semi-systematic way of making a final decision on controversial content issues (final in the sense of, if nothing changes in the real world, nothing changes on Wikipedia); when an edit war drags on for years and years, it's in the encyclopedia's best interests to come to a resolution and put the issue to rest. However, I cannot support this proposal without knowing more details about how this body will work. What, ideally, should their decisions be based on? Like for ArbCom, their decisions are based on Wikipedia's policies and guidelines, etc., but it really comes down to personal judgment and common sense. Why does User X deserve a 1-year ban while User Y only gets admonished? The severity of sanctions is not encoded anywhere in policy; it's just what feels right to the arbiters. Now, a bit of personal opinion is perfectly fine for ArbCom, because ArbCom members (as well as most experienced users) are all pretty mainstream when it comes down to user conduct. Even an ardent deletionist, as long as they understand and uphold our policies, would object to someone mass deleting articles they don't like, for example. The problem for content disputes is, however, that it would be very difficult to find a group of users who are relatively neutral on all political, social, and other controversial issues. Moreover, while our behavioral guidelines cover all of user conduct (yes, all - any leftovers are taken up by WP:IAR), we can never hope to create a set of guidelines describing all possible content, simply because the world has too many twists and turns. IAR is fine, but just try moving Republic of Ireland to Ireland unilaterally. IAR means common sense; articles, however, feed on sources. Interpretation of those sources (what to include, what to prioritize, etc.) is what leads to this mess. If a policy or guideline is ambiguous, we hold a discussion to amend it. But the sources are there, and we can't change them. The above is the fundamental difference between conduct and content. -- King of ♥ ♦ ♣ ♠ 08:55, 4 October 2011 (UTC)

• • I agree with the differences in content and conduct disputes, and the complexities and difficulties that convening such a DR body for content issues will create. The reasons you give are sound ones. As Wikipedians we all have personal opinions on things, religion (either religious or not religious) or politically (various broad categories here). One doesn't have to have no opinion on anything to be able to be objective and neutral, they must however have a very sound understanding of the content policies and how they work together (NPOV, RS, V, BLP, UNDUE to name a few) as these are largely how content is governed. I think TransporterMan's draft proposal might be a decent starting point we can mould something out of. I'd agree that this should be done cautiously, so perhaps the requirements for case acceptance at the "Content Committee" can be very strict to start off with, with their remedies to be in effect for a max period of time to start with (say 6 months) and the acceptance requirements and duration of remedies etc can be modified as the committee becomes more structured and the case process becomes smoother and works better as time goes on. Steven Zhang ^{The clock is ticking....} 10:23, 4 October 2011 (UTC)
• The more time single purpose editors spend arguing, the less time they spend edit warring. In that respect, the status quo works relatively well.

  I think what we need is an alternative to RfC that comes after existing options have failed, in which uninvolved editors try to determine whether there a solution is remotely conceivable, or whether the issue should be recognised as something which is unlikely to ever be resolved. When writing about love and war, religion and politics, life, the universe and everything, it's inevitable that the latter will sometimes be the case. —WFC— 14:35, 4 October 2011 (UTC)

• Would be in support of this idea. Frequently a RfC resolves issues but for cases in which it does not we do need a further mechanism of content resolution.--Doc James (talk · contribs · email) 01:43, 6 October 2011 (UTC)
• Support something being done in this area. ArbCom's current model is not working; content and conduct problems don't always go hand in hand and so dealing with conduct only is inadequate. (To be fair, it's not really the Arbs' fault their model is inadequate; their scope is given to them by the community.) What exactly should be done I don't know (I might think of some more ideas when I'm more lucid), but something should be. Heimstern Läufer (talk) 05:56, 12 October 2011 (UTC)

Thoughts by FT2 on content resolution + proposals

The issues that cause content not to be resolved are very well known - as a community we have seen it happen thousands of times. Four issues seem to cause a debate to get really bad. I would like to propose a 4-way framework that would be likely to help.

The problem with "binding content resolution"

1. The risks of "setting content in stone" is huge, this alone is a major concern ("you can't change it, it was agreed by arbitration etc").
2. It makes it hard to improve any "fixed" text later,
3. It creates a prime target for gaming and politiking (eg who gets to make these decisions),
4. We don't want to ditch broad community consensus as our process except in the utmost need.

Issues to design around

• Some topics are inherently difficult because of the question, even if conduct is good. For example: - weighing sources, evaluating what is a "mainstream" view, and issues with genuine multiple answers (naming disputes etc). The process especially needs to help these kinds of question.

• It doesn't take many people to frustrate good debate. We have policies that in theory should work well but rely on good quality participators and very good faith efforts and mutual respect. In heated debates these are easy to break or hard to obtain from all participants.

• We don't have a formal structure to help editors reach consensus in complex issues. So each time there is a "reinventing of the wheel". At Arbitration the answer to many content issues is "you need to try proper multi-stage, carefully planned, consensus-seeking". Several "heavy" content issues got resolved this way but the lesson how to do it (or that it may be needed) hasn't spread.

• It's easy for a newcomer to a topic to demand a rehash of a debate even if there isn't really anything new to add. This can add scrutiny and improvement and inclusion of updated facts (good) but can also cause pointless rehashing and lack of progress to the frustration of long term topic editors (bad). It can also mean a newcomer with a good point is silenced due to impatience that they were not aware of nor responsible for (bad).

Proposed framework

Three key targets:

1. A way to bring specific points to a process that examines genuine hard content questions productively and narrows down or answers the problem, but without fossilizing or helping gamers.
2. A way to make more/better use of multi-stage dispute resolution methods, also easier and earlier. (Used as well or instead of #1)
3. A way to put the brakes on users who "fly under the radar" by impeding good discussion in a way that makes it hard to block them (eg civil edit warriors), and on disputes involving so many heavily-involved users that little progress towards resolution gets made over years (eg ethnic disputes)

Framework proposal #1 - Content review for genuinely hard issues

Users able to bring specific content points for independent evidence-based review, if all other routes fail.

• Talk pages often get distracted or fail. The review "rules" are designed differently to avoid that.
• Users present evidence related to the content issue (not related to past debates, behavior, personalities etc).
• Only the highest standard of contribution is allowed, eg speaking on content issues only, examining evidence only, asking questions intended to clarify concerns or points of fact/evidence, and making succinct (non-essay) points related to policy or best practice only.
• Page header states that anyone meeting certain standards (eg mainspace edit count, GA/FA, no recent blocks) can contribute but users who can't or won't discuss to a very high standard , may be asked to contribute on the review's talk page only.
• The aim is to set rules that gain high quality discussion by experienced users - including a high proportion of uninvolved users - who can be shown the actual evidence on the content point rather than endless dispute history, and who collaborate to analyze that evidence and ask questions, and clarify their thinking to the disputants.
• The outcome is that disputants get a high quality review of the content related evidence, which can be taken back and used to help settle the dispute - but is only binding in the sense that it's an independent and high quality review.
• Future questions on the topic can be resolved by pointing to the discussion of evidence, or by adding a new section to reopen the debate on specific new points of evidence if editors can't solve it on the talk page. So content isn't fossilized or "dictated by edict", but also isn't endlessly rehashed in the absence of new evidence.

Framework proposal #2 - Making multi-stage dispute resolution more accessible

Users able to get proper uninvolved help to set up and operate a good quality multi-stage DR process. We have seen these used on several big disputes already. They work.

• Relies on experienced users working neutrally together (maybe part of MEDCOM or a separate WikiProject?) who help others with a dispute to set design, set up, and operate a decent DR process for their specific content concern, by listening and learning what the issues are and why it's stalled, and trying to help the participants to develop a way to resolve it (eg based on what's worked in other major issues)
• Users in a difficult content dispute could disagree on the content but agree they are getting nowhere and agree to ask for help to design a good quality DR process. The request would be something like, "This is a major and messy dispute, we agree we need a proper DR process but we can't agree on one or don't know how to operate one. Please help"
• The role of the "helping" users would be to help disputants build consensus for a process that gets enough "buy-in" to be helpful (eg to frame the issue, agree what questions need asking, agree any "rules" for the discussions, then hold a discussion with agreed "rules" etc)
• May work or may not, but this is how many "heavy" disputes like naming disputes actually get resolved after years of arguing, so worth making it more accessible.

Framework proposal #3 - Keeping "skilled disruptors" and "mass involved participant issues" from damaging content progress

Two possible avenues:

• The line between disruption and good faith lack of skill or advocacy is hard to draw. Disputes often flounder because our criterion for removing a user is that they are egregiously causing a problem. If the rule was flipped in some disputes, that users had to contribute to a visibly high standard of conduct (as seen by uninvolved user consensus) to stay in the debate, and not just "avoid egregious bad conduct", or there was a "one warning and courteously asked to leave the page for 24-48 hours without a block" rule for some disputes, then a lot of disputes would vanish because people would start to realize anything but good content-focused conduct just got them excluded. It would make tendentiousness or ad hominem much harder to get away with.

• Good quality content tends to be more stable and less polarized. Articles with perennial disputes drive away exactly the skilled editors who could help improve the content. An option would be to develop a way to identify users the community trusts in content disputes - users who have shown a high level of editing skill and capability, very good respect for policy, not prone to POV or gaming, good on both conduct and content, fair, etc etc. In effect "trusted content editors" - people we know from their past editing will consistently edit content well, neutrally, and with good conduct. We have easily hundreds or thousands of such users, enough to make this work. Such users could be given exclusive editing of the article for a month, then it handed back to the wider community/previous participants to take it over again. It won't stay perfect, but being put into good shape by good quality editing that reflects multiple views neutrally and acknowledges issues, will reinvigorate it, and makes it much easier for regular users to maintain.

Together these would make a massive improvement to content issues, possibly including some of the worst, and avoid the risks of "binding content arbitration". FT2 ^{(Talk | email)} 15:15, 4 October 2011 (UTC)

• We certainly do need a workable process for content dispute resolution. Options that I can think of are (1) to set up authority figures who chair, guide, steer, or decide, as FT2 suggests (will we elect these people?), or (2) to have a fixed-duration centralised discussion framework, which would resemble XFD discussions, to be closed by administrators based on community consensus. Either way would lead to a quicker and more final decision on content matters, which I think is the outcome we want.—S Marshall T/C 00:12, 5 October 2011 (UTC)

• Many moons ago I came up with a proposal for a circuit of lower courts under the authority of the Arbitration Committee, run by a single judge (or some other title) who could adjudicate content disputes by fiat, using a set of criteria laid down by Arbcom. Those decisions could then be appealed to the full Committee, and the lower court justices would be elected by the community and could be removed by Arbcom at any time (and easily). Obviously this is modeled after the US civil justice system. It has the advantage that it could lighten the load of Arbcom (because they can reject appeals where it looks like the case is straightforward and the lower court arbitrator did his or her diligence, plus the lower court arbitrator would have already done the clerking work of making the dispute legible to committee members), which means that more disputes could be put into the Arbitration phase, and earlier. That would provide binding content dispute resolution that supports the efforts of good-faith editors who don't back down from trolls. We'd probably have to delete WP:BURO if we did that, though. causa sui (talk) 19:17, 11 October 2011 (UTC)

Would an admin assess the consensus in this discussion? Thanks, Cunard (talk) 22:44, 19 October 2011 (UTC)

I have a feeling that there hasn't been enough discussion to do much here, which is a shame. But not much that can be done, if there's a lack of interest. Steven Zhang ^{The clock is ticking....} 23:24, 19 October 2011 (UTC)

Many thoughtful proposals have been raised here (in this subsection alone, the proposals by FT2, S Marshall, and causa sui are very innovative). There was likely a lack of interest in this discussion because there was not a well-defined proposal about what changes to implement.

This discussion's purpose was to elicit ideas about how to change the content dispute resolution structure. If you are still interested in implementing one or more of the proposals here, I recommend that you create a page dedicated to discussing them and ask the editors who have participated in this discussion to help you form (a) well-defined proposal(s) for change. Solicit more proposals and opinions via WP:CENT and other pages. After drafting a well-defined proposal and advertising it on WP:AN, WP:ANI, WP:VPP, and WP:CENT, it will likely garner much higher user turnout and interest. Cunard (talk) 04:34, 20 October 2011 (UTC)

Villages

At present there is a discrepancy on the way villages and other types of unincorporated localities are treated. For some countries, articles on villages are accepted, for other countries they are not, even when there is no major difference in the administrative setup. It does not make sense for instance, to accept articles and categories for villages in Bulgaria, Bangladesh, Botswana, Hungary, Poland, Ukraine and not for Romania, Moldova or Serbia. Even if villages are not independent administrative entities, they are separate settlements and should be accepted as subjects for separate articles. There is no reason why an unincorporated locality such as McLean, Virginia should be accepted as subject for an article and Veneţia de Jos, Braşov (which is first documented in 1235) should be excluded. These are only examples. The issue is that all settlements (villages) should be accepted as subjects for articles, regardless of the country in which they are located. A unitary approach should be adopted for the entire en:wiki. Treating the locatities of different countries in different ways only creates conclusions.Afil (talk) 16:52, 11 October 2011 (UTC)

???? Based on the consensus demonstrated at numerous AfD discussions, every geographic location or entity that has a name and a verifiable location is suitable for inclusion as a topic of an article in Wikipedia. Who told you otherwise? --Orange Mike | Talk 17:15, 11 October 2011 (UTC)

If I'm reading you correctly, your using McLean, Virginia as an example of a place without an article? Monty₈₄₅ 17:32, 11 October 2011 (UTC)

On the contrary, I was quoting it as a place with an article as opposed to others for which the articles have been deleted.Afil (talk) 18:13, 11 October 2011 (UTC)

So have you tried actually creating these articles only to have the deleted/merged or is it that they don't exist? If the letter, then go make them. Just because something hasn't been done doesn't mean "it's not accepted". ♫ Melodia Chaconne ♫ (talk) 18:20, 11 October 2011 (UTC)

The problem started in some articles on villages which I have posted and which have been deleted being replaced by redirects. I also designed a template for the communes to which the villages are administratively subordinated. This lead to a dispute on the talk page of Template:Beceni, Buzău where a fellow wikipedian considered that even if Romanian villages have a name and a location, they should not have their own articles. The discussion was getting heated and I had no proof of what the accepted policy of Wikipedia was. As the discussion was getting nowhere, and each of us was sticking to his guns, I am trying to find out what is agreed upon, if there is a consensus on the matter (or to generate a discussion if the matter was not agreed upon. It is definitely a matter of not accepting articles on Romanian villages and this view has been advocated by my opponent. I don't want to argue indefinitely but simply know what is correct and what is not correct.

And I fail to understand why a template which lists the compunent villages of a commune and tthe neighboring communes should be deleted because the villages are irrelevant.

Afil (talk) 18:30, 11 October 2011 (UTC)

As I am the user in question, I would like to clarify why Romanian (and Moldovan) villages are (and should be) covered under the articles of the parent communes to which they belong, as well as through redirects to those articles, rather than as separate articles:

1) Rather than have 13,000 permanent stubs, it seems far preferable to have 3000 (mostly) stubs that can be expanded; having eternal and virtually identical stubs floating about is not a goal of Wikipedia. If an article has no chance to get to FA status, it shouldn't exist; this is the case for Romanian villages, but not communes, and even if villages did make FA, they'd necessarily overlap greatly with the commune articles, or else the latter would remain empty shells, with relevant material in the village articles. Multiple articles on essentially the same topic are by nature redundant and cumbersome as well. Would readers want to have several small articles to look through, all of them assuming that the readers already know how one article relates to the other, or do they want a single, reasonably long coherent article that answers most questions in one place? Because you can make a coherent article on a locality of 1,000 people if you don't decide to make ones about each of its individual parts.

2) In 95% of cases, commune A will have villages A, B, C, etc. How do we distinguish village A from commune A in two separate articles, and more to the point, why take that pedantic step, a step tantamount to content forking?

3) The standard Romanian encyclopedic dictionary of 1978 stops at the commune level. Yes, I know we're not paper, but this still matters.

4) Villages don't have administrative powers; communes do. Again, I know this isn't determinative, but it's another factor.

I'd like to emphasize that I have never sought to delete articles on villages, but to merge and redirect them, so please let's stop right here with charges of "deletion". Whatever relevant content there is on them should be added, but I (and others; this isn't just my opinion) simply think this material should be in the commune article, not split up. I'd also like to note that another discussion (in which I took no part) decided not to have articles on the barangays of the Philippines, so such a step is not without precedent. And that it's possible a more logical structure could be devised for organizing villages in Bulgaria or Bangladesh or Botswana, but the important thing, as I see it, is to have consistency within countries rather than across them. There are almost 200 countries on earth, and terms like "village" or "commune" or "county" mean different things in different places, so it seems absurd to try for one standard that fits all. (Moreover, I'm afraid referring to other countries is untenable: what we have is articles on the smallest self-administrating units of each country, which Romanian villages are not. A Romanian village is a the equivalent of a commune quarter, which makes it have unparalleled status and border on zero relevancy for this project as a whole.) Involved editors happen to have thought up a standard that fits Romania and Moldova quite well, and there's no reason to discard it. - Biruitorul ^Talk 22:31, 11 October 2011 (UTC)

I agree - certainly every spot on a map should be mentioned on Wikipedia, but there has to be a level below which we don't necessarily create separate articles for each of them (unless there's something especially interesting about a particular spot). In many countries which have "commune"-like units, that seems a good level to use for article separation. (Entities below that level are likely to be more like hamlets than real villages.) Similarly, civil parishes in England (where they exist), and sołectwos in Poland, seem to be the right sort of level to make separate articles. (We need to consider how we represent the coordinates of subvillages, though - this should be done in such a way that they can still be exported to external map applications.)--Kotniski (talk) 08:05, 12 October 2011 (UTC)

I think this is a case of deciding on organization rather than actual text. No one is questioning whether or not information at Wikipedia regarding such villages should be included; I see nothing wrong with keeping such information around. Whether it makes more sense to organize it into seperate articles, or to collect it into larger articles covering multiple villages within a larger administrative unit; well, that is the sort of thing that needs to be taken on a case-by-case basis, and needn't be decided by any all-encompassing policy for the whole 'pedia. Instead, use common sense, and decide what situation calls for what sort of organization. It is not insulting or unfair that many small articles are redirected to a larger, omnibus article if such method makes for better reading. No one is deleting anything, and if that works to make Wikipedia easier to use, then go with that! If, perchance, more information were to be found regarding certain villages, then it could be spunout into a larger article. But there's nothing wrong with merging these articles, so long as the information is preserved. --Jayron32 19:32, 12 October 2011 (UTC)

The discussion is presented incorrectly by User:Biruitorul. If you look at his discussion regarding Template:Beceni, Buzău. he specifically states that ALL articles on villages in Romania and Bulgaria should be replaced by redirects. There is no reference on the contents - even if the information is sufficient to justify an independent article it still should be merged into the article on the commune. This is incorrect.

What I am objecting to is setting a different rule for any country as opposed to a general rule applicable to the entire Wikipedia. We cannot have country-specific rules. If we do dont want stubs or small articles for inincorporated localities, this should be specified. Any rule which is applied only to a certain group, country, nationality etc. constitutes a discrimination. If we accept the views advocated by user:Biruitorul they should be equally applicable to Bulgaria, Poland, Hungary etc.

Some arguments simply do not hold water, for instance the fact that villages do not have administrative powers. It is not a factor at all. It it was, we would not have an article on McLean, Virginia, who has absolutely no administrative powers.

In conclusion, I consider that all countries are to be considered equal and that no single country should be the object of a separate discriminatory rule which is not applicable to the rest of the world. This is the issue I have raised and which should be addressed. Afil (talk) 20:07, 12 October 2011 (UTC)

Actually, I said nothing about Bulgaria. As for Romania, yes, I support merging and redirecting articles on villages, and indeed I've done it for all 13,000 of them. As Jayron notes, an extra-long article on a village could conceivably be split off, but we're nowhere near that stage yet. When we have information on a Romanian village sufficient to justify an independent article, I'll be pleasantly surprised.

In fact, we very well can have country-specific rules; see for instance this section of WP:NCGN. This is not an instance of "discrimination" (oh, and by the way, in relation to this topic, you've used that word nine times in recent days and it's failed to cause people to fall all over themselves, so you might as well quietly drop it) — it's a matter of dealing with different realities in different countries. For the reasons outlined above, the model I have followed probably works best for Romania; other models may work better elsewhere. (The average Bulgarian rural municipality, for instance, is ten times bigger both in terms of population and area than its Romanian counterparts, so it could perhaps make more sense to have separate articles on Bulgarian villages.) See also WP:CREEP: we probably have enough rules as is, and we're simply not going to create one special standard that encompasses all 193 UN member states. WP:GNG and WP:CFORK are more than sufficient to handle this situation.

On the contrary, villages' lack of administrative powers is a factor: we're talking about places with hundreds or even tens of inhabitants that don't even have their own mayor and local council, and that are in fact informal, often undefined or vaguely defined districts of communes. We absolutely should (and, thanks to me, do) mention them at the articles of the communes they belong to, and redirect for accessibility (again something I've done), but splitting them off would only create redundancy and confusion. After all, would readers want to have several small articles to look through, all of them assuming that the readers already know how one article relates to the other, or do they want a single, reasonably long coherent article that answers most questions in one place? As for McLean: let's not compare a city of 50,000 with commune quarters of a few hundred residents.

Just so participants can get a concrete idea of what we're talking about, please have a look at a well-developed article on a Romanian commune, Coronini, made up of two villages, Coronini and Sfânta Elena. Now, if I understand Afil correctly, he'd want us to have articles on Coronini (the village), Sfânta Elena and Coronini Commune. (This is what they do on Romanian Wikipedia...) The first two would split the content roughly in half, while the third would be a pretty empty shell. Now, in all honesty, isn't the suggestion a little absurd? Why take a nicely written, coherent article on a single entity and cut it into pieces on a whim, in the process dispersing and reduplicating content? Because one editor thinks it's "anti-Romanian discrimination" not to have three articles where we easily can have one?

And your final point is more of the same ignoratio elenchi. Having a particular arrangement for how we deal with one country's geographical subdivisions does not mean we consider it less "equal" or that we "discriminate" against it (that word again!). Just as we don't have articles on the smallest units in the Philippines or (as Kotniski helpfully informs us) Poland, there's a logical stopping point for Romania as well, and that's the commune. - Biruitorul ^Talk 21:37, 12 October 2011 (UTC)

You do not understand me correctly. What I am opposing is discrimination of any kind. I would consider it equally offensive if we advocated a rule which for whatever reason (let's ssay because the names exceed 20 characters) would exclude Welsh names from Wikipedia. I would consider it offensive to propose a rule which for whatever reason would exclude some Israeli entities from Wikipedia.

I am also opposed to hidden discrimination i.e. of designing criteria which would have the effect of eliminating a certain category.

This is a general principle which should be followed by Wikipedia in all cases. There should bbe no rule which is applicable only to a single nationality, ethnicity, country, religion etc. And no pretext which would have the effect of singling them out should be acceptable.

If there is a rule which says that "every geographic location or entity that has a name and a verifiable location is suitable for inclusion as a topic of an article in Wikipedia" it is not acceptable to add "except in Romania or Moldova". Even if some pretext are presented to explain why this exception should be accepted.

It would be non-discriminatory to indicate that information regarding these locations should be included in articles with more comprehensive subjects, to put certain conditions on when stubs are not acceptable as long as they are applicable to the entire world and not to a certain country, geographic area, nationality etc. I am not against such rules, as long as they are not defined in a discriminatory way or do not have hidden discriminatory effects.

But a rule which excludes only geographic entities in Romania and Moldova is discriminatory and anti-romanian (especially as it targets the only two Romanian-speaking countries in the world), just like a rule which would exclude geographic entities in Africa would be a racial discrimination and the exclusion of geographic entities in Israel would be antisemitic.Afil (talk) 22:18, 12 October 2011 (UTC)

• Established practice throughout Wikipedia is that there should be individual articles. The only related instances where any discussion at AfD has ruled otherwise is in cases where the real existence cannot be proved, cases where the proposed village actually is a single non-notable isolated house or farm, where the name is not a community but just a non-notable housing development of some sort being given a distinctive name by the proprietor and only the proprietor, and --most often -- for the neighborhoods of a city where the name is not an official designation and not used in a specific and reproducible way with sources other than real estate advertisements. For the examples you give, the smaller included locations are separate settlements in the sense we use it here, and should unquestionably have separate articles. Unfortunately we have no final way of settling questions like this except to make it a question of deletion and take it to AfD. We've frequently held that if an AfD closes as a keep, and the discussion includes the possibility of a merge, and the closing specifies in accord with consensus that it not be a merge, that a subsequent merge is improper. As for the applicability in a specific country, I do not think that discrimination would normally have anything to do with it, but rather the question of consistency. Trying to do it differently for a particular country would be like saying that any other eneral guideline hilds, except for a particular area.

With respect to the arguments: 1/the number of stubs is irrelevant., We can accommodate any number of small articles just as well as large ones. There will always be something specific to talk about in the geographical section & almost always the historical also. 2/ if commune A has villages A, B, and C, this is no different from a country or province A having cites A, B, and C. We simply distinguish in the heading. 3/How the country's standard gazetteer limits itself is irrelevant if we have sources. / Administrative powers are irrelevant if they are known to be distinct and defined communities. There's another argument; The individual parts in a long-settled country normally have separate origins and were once independently administered at some point, before a later organization. Any historical village gets an article here just as does a current one. Using the very example given, the individual villages in Coronini do in fact have this earlier clear separation, and have not only different dates of formation, but different histories and ethnic compositions. I think it a very clear case for why we have sand should have eparate articles. DGG ( talk ) 22:39, 12 October 2011 (UTC)

DGG, what you write about AfD is not especially relevant, given that no one here has proposed deletion, but merger and redirect have instead been applied. I will also note that all the information on a village can easily fit into an article on a commune, and the redirects were mostly done with that in mind. The village is not an administrative subdivision of any kind, and, if anything, functions as an informal section of a commune, when the commune itself only hosts thousands of inhabitants at best. No matter how much one would expand the article on a village, the info would still not be too much not be featured nicely in the relevant commune article; the opposite will result in articles which either say the same thing or of which at least one is forced to remain a stub (the commune article, which in that scenario would only say "x commune has x, y, z villages"). All of the information would be segregated along impractical lines.

This would specifically happen with Coronini: sure, the two villages have their own histories, but they also happen to be part of the same administrative unit, and having one article on each and then one on the commune will necessarily result in duplication and one permastub, when now, all the content is under one coherent umbrella, and anyone happening to search for Sfânta Elena (or, if you prefer, by its Czech name Svatá Helena) will effortlessly find it. - Biruitorul ^Talk 23:25, 12 October 2011 (UTC)

Congratulations, Afil: you managed to use "discrimination" seven times in your last post, as well as throwing in "offensive" twice, and "anti-Romanian" for good measure. I hope people continue to ignore this nonsense, but just in case, let me state for the record that I am a patriotic Romanian who simply has a more logical approach to presenting the country's geography on Wikipedia — not that who I am should have any bearing on the discussion, but I don't want casual observers to get the wrong idea about my motivations based on Afil's tireless repetition of the same baseless canard.

At this point in the discussion I think we've established that all named places should be mentioned and accessible (which they are for Romania and Moldova), but how exactly this is approached will necessarily vary from country to country, given the plethora of administrative systems in existence. The strength of this encyclopedia lies in its pragmatism: there are some general rules for all to follow, but it's quite common that particular subjects are tackled on a case-by-case basis, and it would be counterproductive to have a policy covering Romania and Peru and Malawi and Tuvalu and Burma and North Korea stating what sorts of places need separate articles. It would be more enlightening if instead of complaining of "discrimination... discrimination... discrimination", you'd actually delve into the details of this, like how you'd approach Coronini Commune and why your approach would work better; or why readers should be asked to wade through several permastubs on informal quarters of communes, when these are now brought together in reasonably coherent wholes; or how your plan (if you have one) addresses WP:GNG and WP:CFORK; but maybe that's too much to ask. - Biruitorul ^Talk 23:25, 12 October 2011 (UTC)

I consider that we can only agree to disagree. The discussion had been carried out long enough. You may stick to your guns and I to mine. I am not complaining about anything, I simply stated that I do not like any kind of rule which implies discrimination in any way. And this means singling out some elements which are not subject to a generalized rule. Once a general rule has been agreed upon then we can discuss any details you wish. But coming up wwith any detailed examples cannot cover the main issue which I have raised, that the rule must be applicable to all countries of the world, without exception. If we talk about pragmatism, this would imply accepting articles for nonincorporated localities - wherever they are located - if there is sufficient information to justify an article and to recommend incorporating the information in more comprehensive articles (covering the municipality, commune, upazilla or whatever may be the case). What I am objecting to is the general rule you want to establish that in the case of Romania and Moldavia ONLY, unincorporated villages should not have articles. All your lengthy discussion and claims to patriotism - which has nothing to do with this issue - just avoids the issue. Afil (talk) 21:58, 13 October 2011 (UTC)

I only mentioned my patriotism because I didn't want others to buy into the false charges of "discrimination"; I'm not that self-absorbed to think it normally matters. Interestingly, France seems to be another country treated much the same as Romania and Moldova: we have articles on the French communes, but the villages in France category mainly contains communes as well. Anyway, when "sufficient information to justify an article" about a Romanian village turns up, I'll be pleasantly surprised. At present, that day seems far off.

And if we're going to talk about avoiding the issue, the crux of the matter is not "discrimination" or the alleged need to create a single standard covering geographical entities in all ~200 countries on Earth, but how we structure information logically and present it to readers in an accessible fashion, keeping in mind WP:GNG and WP:CFORK. As I've said before, it makes far more sense to present information on villages A, B and C of commune A in one article, "A", rather than disperse and duplicate it into articles "A", "B", "C" and shell article "Commune A", while expecting readers to look through all four (even assuming they know how they're related). Perhaps you can address that point, preferably without using the word "discrimination" or calling for a generalized rule on the topic. - Biruitorul ^Talk 00:59, 14 October 2011 (UTC)

Huh??!! 13,000 articles merged, all related to the same country, by one editor? I can't believe someone would decide on his own a policy for articles about one country and then apply this policy to all the articles. Not only that, also "knowing what a reader would prefer", assuming that the articles wouldn't be expanded (I can believe that, who'd want to spend time and effort after seeing 10,000 articles removed), using the allowance of geographical differences in titles as justification, and claiming that none of those could ever make it to FA.

It's clear that at least some editors don't agree with your merging activities. Yet when I look at for example the revision history of Hoghiz, there's an edit marked merging on 5 september,

• but no notification of a merge proposal, no proposal on the talk page, or reasons given, arguments or any discussion.
• No edit summary noting merge content from [[SOURCEPAGE]] , "a step required in order to conform with Wikipedia's licensing requirements. Do not omit it nor omit the page name." See Help:Merging
• In the edit summary of Cuciulata, once again only the word "merging", despite the clear instruction: Save the source page with an edit summary noting merge content to [[DESTINATIONPAGE]] .

So you seem to be telling us that you've ignored wikipedia guidelines, policies and rules, over ten thousand times? That could be a new record... DS Belgium ٩(͡๏̯͡๏)۶ 10:22, 15 October 2011 (UTC)

The number of "articles" (we'll call them that, even though they usually didn't come up to any basic standards) I actually merged was roughly two dozen of 10,000. The remaining 9,975 or so never existed as articles; I simply created redirects for them and added mention of their existence at the commune articles. And don't forget Moldova, where I did the same thing for about 1,000 villages; the number of pre-existing "articles" there was about 5.

I've fixed the problem regarding Hoghiz/Cuciulata; thank you for pointing that out.

This was not a unilateral step, but rather was discussed by a number of interested editors. I actually do think a reasonable reader, rather than having several small articles to look through, all of them assuming that the reader already knew how one article relates to the other, would prefer a single, reasonably long coherent article that answers most questions in one place. And this is not the only justification; I've outlined several, the main point being that informal commune quarters without administrative capacity border on negligible notability, and that it's sufficient to fold them all into the same article rather than spreading them out in several disparate, duplicating directions. And I repeat: if we take article A on Commune A with villages A, B and C, and if we split it into four articles ("A", "B", "C" and "Commune A"), the last of these will have essentially nothing to say, except what its villages are and what its population, ethnic and religious composition are — at best three lines of text. ("A", "B" and "C" are also going to be very short in most cases.) Whereas by covering everything in one place, including history, geography and so forth, we at least have a chance to develop a "well-written, comprehensive, well-researched" article. - Biruitorul ^Talk 15:48, 15 October 2011 (UTC)

The discussion mentioned is probably Wikipedia:Romanian Wikipedians' notice board/Archive 10. However no consensus has been reached and in the conclusions of the discussion, drawn by User:MariusM he indicates the pros and cons of the various alternatives and concludes that small villages should not be excluded as having potential separate articles. The discussion was held in 2007.

To define the problem in Romania communes are territorial units - not settlements. By law, there are four types of settlements in Romania:cities, towns, villages which are commune seats and villages which are not commune seats. This type of setup is valid for most countries in the world, where the lowest level territorial units have a number of settlements of which one is the seat of the territorial unit.

Is is therefore interesting to present how Wikipedia has dealt with the problem in other countries.

Let us take, for instance, the Commonwealth of Virginia. The lowest level of administrative unit in Virginia is the county. As an example Culpeper County, Virginia has a separate article presenting the administrative unit (county). The seat of the county is Culpeper, Virginia which is a town with a population of 9664 inhabitants, which is of the same order of magnitude of some of the seats of communes in Romania. Culpeper, Virginia is a different article and is not included in the county article. The county has several unincorporated communities, some of them, for which information is available, having their own articles, for instance: Richardsville, Virginia. Though it is only a stub, it has a separate article and the available information regarding Richardsville is not merged into the county seat or county article.

Looking at another country, let us take the state of Schleswig-Holstein in Germany. The state is divided into "Kreise" (Districts) which in turn are divided into "Ämter" which are the lowest level of territorial units. Each Amt has several settlements, called °Gemeinde" (which would be correctly translated as community, but for wich en:wiki has preferred the name of municipality). Let us take the Amt of Leezen (Amt) which has its own article. The seat of the Amt has is Leezen, which is a settlement of 1700 inhabitants. which has a separate article. All the other communities of the Leezen Amt have their own articles, for instance Wittenborn, Bark, Germany, Neversdorf etc. Most of these Gemeinden have populations of a few hundred inhabitants and the articles are mostly stubs.

The argument user:Biruitorul presents could be made both for Virginia, for Schleswig-Holstein and for the great majority of states or countries in the world. However, as it has been established that "every geographic location or entity that has a name and a verifiable location is suitable for inclusion as a topic of an article in Wikipedia" and if this rule has been applied for other countries, as indicated in the examples presented above. I see no reason why we should make the argument made by user:Biruitorul which is applicable only to a single country and not stick to the rule which has been applied everywhere else. The argument made by Biruitorul may have its merits - what is does not explain is why the situation is different in Romania from the example presented in Germany, which is basically identical. Especially, as even for Romania, the old discussion mentioned has not reached a consensus. Afil (talk) 19:51, 16 October 2011 (UTC)

According to the Romanian Constitution (Article 3, Section 3): "The territory is organized administratively into communes, towns and counties. Some towns are declared municipalities, according to the provisions of the law." The Constitution says nothing about villages. The relevant law (Law 2 of 1968) does mention that communes are made up of "one or more villages", but Romania (unlike perhaps Virginia or Germany) lends itself well to stopping at the commune level. Why? Well, simply for the reasons I've stressed above over and over. I'm glad you've dropped the claim of discrimination; even if it happened to strike you as such, my motives are only with the best of intentions. As I see it, the important thing is not to try and force the same standard onto Romania and Germany and France at the same time, but to do what's most practical in each case. And covering information on parts of communes under the umbrella of their commune will surely make for more coherent articles (if these ever materialize; precious little has happened on that front since 2007), rather than slicing and reduplicating for no particular reason, given that the villages are still accessible to all looking for them.

I'm also aware that we can't do something completely separate from the rest of Wikipedia for Romania and Moldova only. But the fact is that for many countries, we do seem to stop at the smallest self-administering unit: a quick perusal showed that Algeria, Guinea, Mali, Spain, Iceland, Cambodia, and by and large Italy and France all seem to fall into this pattern. So in fact, the way we now cover Romania and Moldova seems not that unusual.

About the Leezen example: does having a dozen one-line stubs, where the content could all be covered in one place, actually improve the encyclopedia? If so, how?

For the record, I disagree that 9664 is "of the same order of magnitude of some of the seats of communes in Romania". I believe Holboca is the largest commune in Romania, at 11,662 people. With seven villages, that's 1666 inhabitants per village. Of course, some of those villages will be larger than that, but probably not too much. The average village (10,139,000 rural inhabitants ÷ 13,285 villages) has 763 residents. Some have just a handful, or even 0. - Biruitorul ^Talk 04:02, 17 October 2011 (UTC)

I would not compare the villages of Romania with the ones of Guinea. I have worked in countryside of both countries and there are few similarities. Have you ever seen a village in Guinea or Mali?

Just for the record. The component villages of the commune of Holboca are: Holboca (2689 inhabitants), Dancu (7225 inh), Orzeni (752 inh), Cristesti (643 inh), Rusenii Vechi (673 inh), Rusenii Noi (375 inh), Valea Lungă (281 inh).

The biggest village of the commune has 7225 inhabitants which is obviously of the same order of magnitude as the 9664 inhabitants of Culpepper.

I was presenting the comparison whith the amt of Leezen in Germany and its component villages who all have articles in en:Wiki. The entire Amt has 8516 inhabitants. The various villages have: Bark 1003, Bebensee 608, Fredesdorf 385, Gross Niendorf 683, Hogersdorf 405, Leezen (Amt seat) 1700, Mozen 461, Neversdorf 103, Schwissel 254, Todesfelde 59, Wittenbord 825.

What is the difference which makes small villages having 59 or 103 inhabitants in Germany be acceptable and similar villages in Romania not to be worth having separate articles. These are actual examples. What makes Germany so much superior to Romania regarding the value of its settlements? If you look at the articles of the German villages, could you present an arguments as why the content of these articles justifies a separate article while the information on villages in Romania does not? Can you make a similar argument why the unincorporated settlements in Culpepper County which have articles (not all have) justify a separate article.

Regarding the villages, it is true that the Constitution of Romania does not mention villages, as it deals only with the territorial organization of the country. I have also indicated the communes are not settlements, but territorial units and that is how they are defined by the constitution. Settlements are classified by Law 351 of 6 July 2001 which indicates the various types of settlements and which lists villages which are county seats as rank IV settlements and villages and rank V settlements. Therefore, villages of various types are separate entities, recognized as such by law. This is not the case for unincorporated settlements which have no legal status. The frazione in Italy have just recently been granted some legal rights and even so, some frazione in Italy have their own articles. Anyway, in Romania, villages are legally separate units. And the law makes a distinction between communes which are territorial units and villages commune seats which are settlements. Obviously you can ignore both the similarity with Germany and the provisions of the Romanian legal system and create your own. But that does not make it right and correct.

In conclusion, my proposal of accepting separate articles for each entity is based both on the legal definition of these entities by the Romanian legal system and on an analogy with other similar cases for other countries in Wikipedia. Afil (talk) 22:41, 17 October 2011 (UTC)

No, I've never been to Mali or to Ghana, but that's not the point: the point is that you repeatedly claimed I somehow set a special precedent by excluding articles only on Romanian villages and stopping at the lowest self-administering unit, and this is wrong. The various countries I cited above, including several in Europe, disprove your contention.

Thank you for the data on Holboca. Naturally, some villages are extra large, and I wouldn't be surprised to see them become communes soon. Meanwhile, the same arguments apply: we may as well give readers access to the same information on the same related entities in one reasonably coherent whole.

Myself, I think it's absolutely silly to have one-line stubs on German villages that can be folded into the article on the next-level settlement. And I think it was thoughtless to have created them. I'm not going to get involved on anything related to Germany, but it was a bad idea.

All right, so villages are settlements; we knew that beforehand. That doesn't mean they're self-administering settlements, or that we don't stop there for a bunch of other countries, or that it doesn't make sense to do so for Romania. - Biruitorul ^Talk 02:38, 18 October 2011 (UTC)

I'm 100% behind Afil on this one. See: WP:IMBALANCE. If a village in the States deserves an article, a village in Romania deserves an article. The reason Romanian (or Cambodian, as mentioned above) village articles don't exist is because no one's gotten around to creating them yet. And in fact some do exist in many of these countries, but the way it's being carried out is haphazard: some with infoboxes some without, some in the correct category some not, and all using English transliterations of their names coming from different sources. As Wikipedia grows over the decades to come, these articles will get padded out, eventually. So they should be created. And the best way is to do it in a uniform matter, because with nearly 4 million articles the most important thing is structure, or we'll just be overwhelmed. To place them in a list and fork them out when they reach an arbitrary number of characters is just asking for trouble, IMHO, because then instead of a team creating a nice outline for each village in one go, you'll get individuals over the next decade+ creating the pages (using villages in Uttar Pradesh as an example) "'Village', Romania'"; "'Village', 'County'"; "'Village', 'Commune'"; "'Village' (village)"; "'Village ('Commune')" with an infinite variety of infoboxes and category placements which will cause nothing but grief.

I know a lot of people hate stubs, but in cases like this, where we know that eventually we'll get to a stage where the articles start filling out, it's better just to create them now, in an organized manner, to speed up development and avoid future grief. Standardization is the key, and the forking method is not the way to achieve that.

Cheers, PhnomPencil (talk) 23:36, 17 October 2011 (UTC)

PhnomPencil, allow me to set a few things straight, if I may. I appreciate your concern about standardization and having a uniform approach. It's something I took quite seriously as I did this kind of thing, creating redirects for every single Romanian village, adding mention of those villages to their commune articles, making sure those articles, on every single Romanian commune, had uniform titles and (for the most part) structures. I really went through with a fine-tooth comb, and our coverage of Romanian settlements is a little less chaotic and a lot more complete than it was a year ago. (To give just one example about titles: someone who probably didn't bother checking how we title Romanian communes moved Bobota to Bobota, Romania upon creating Bobota, Croatia. While working on the villages, I moved it to Bobota, Sălaj, where it belongs - commune, county.)

That we don't have much content on Romanian villages is indeed because no one's added it, but that we don't have articles on them is the result of a conscious decision on the part of several interested editors, implemented by me. Anyone interested will still be able to find them, just under the heading of their respective communes. And anyone wishing to add relevant content is also able to do so under the current structure. I've done it myself in one or two places and it really works out quite nicely.

So we do have a highly standardized approach to Romanian (and Moldovan) geography as of right now. It happens to stop at the lowest self-administrating level, but it makes accessible the next level (i.e., the village) and encourages (one hopes) the addition of content on them. As for forking, well, I won't ask you to wade through everything I wrote, so let me repeat it. When you have Commune A with villages A, B and C, you can cover everything in one place, as we do now, in an article that has the potential to become well-developed, and where readers know precisely how the various settlements relate to one another. Or you can split it up into four disparate bits ("A", "B", "C" and "Commune A"), where there would inevitably be forking, and where at least one ("Commune A") and probably others would inevitably remain stubs in perpetuity. I think there's something to be said for the former approach, don't you? - Biruitorul ^Talk 02:38, 18 October 2011 (UTC)

I wholeheartedly endorse Biruitorul's approach above, being one of the first to propose it (let me add, contrary to what is claimed above, that there was consensus on this: the few objections came from editors canvassed from Romanian wikipedia, who were quick to proclaim that a "massacre" of Romanian villages was in the making, etc.). Now, I want to be very clear about this: nobody is suggesting not to have info on the villages themselves, but what is noted is the need to fit that info into an accessible standard, make it the least redundant and most informative. There is absolutely no practical use to splitting the info on a small locality into its even smaller divisions, particularly since the core info is utterly redundant and confusing; there is even less cause to having these and a separate article on the commune, which would either duplicate the relevant info or simply function as a stubby list (commune comprises x, y, z villages").

As the precedents on Romanian wikipedia show, the only "merit" of separate articles on the villages is for various editors to propagate local patriotism, giving as much exposure to non-encyclopedic, unsourced, unverifiable or simply inane factoids of sub-commune importance. This applies to the largest of the villages, since those existing villages that only number in the hundreds or tens of inhabitants are likely to function as permastubs. In every case: get all the relevant info on all the component villages collected in one place, the commune article, and you'll have an article that: a) says it all; b) puts things in relation without sending the reader all over the place; c) can be kept clean and informative. Do the opposite, and you'll have loads of confusing rants, and loads of original research. One of my own contributions to sorting this out is Coronini: look over it, and tell if anything is confusing or missing.

Note that this also reflects issues of sourcing. By now, countless sources will mention, for instance, that x writer was born in y commune (leaving us to guess what village of that commune is his). Published monographs often deal with communes and specify villages in the same manner I propose. Add to this that, under Romania's own administrative system, villages are awarded no recognition, which means that we only call them units of something by uncodified tradition.

As for the suggestion that we should have separate articles on each and every geographical location: I find it unrealistic and indigestible. First, how does one define a geo location, and when is something not a geo location? Even in the case of Romanian villages, this issue is self-evident: villages sometimes have hamlets, or are divided into several parts (say, a Romanian and a Rom half), which have their own nomenclature. If it is proposed that we define geo locations after oral tradition, these subdivisions are also "geographical locations". Since neither them nor the villages are actually (still) codified by external norms, and since we have to assume that articles on communes are "not enough", then we might as well start work on every imaginable subdivision of a commune, or how else would we be serving our readers? Dahn (talk) 18:12, 21 October 2011 (UTC)

Dahn is not totally correct. The Romanian legislation acknowledged villages which are not commune seats as a distinct type of settlements. Hamlets are not. Each commune has defined villages which are part of the commune and are officially listed as such. They do not cover hamlets or other types of settlements. There are not every imaginable subdivisions, but entities which are recognized by law.

But all this does not answer the basic question I have asked. What is the general Wikipedia policy regarding settlements? I have shown that for other countries, such as Germany, all settlements, even those having populations of under 100 inhabitants have their own articles. I have shown that unincorporated settlements in the Unites States, which also have no administrative recognition have their own articles. Now we have a discussion regarding villages in Romania and the Republic of Moldova. Tomorrow, somebody else might start a discussions on the villages of Hungary or Romania.

It does not make any sense that for situations which are extremely similar in various countries to adopt a different policy. Neither Biruitorul nor Dahn have answered this question. Maybe Biruitorul considers the case of the Leezen Amt in Germany and the component villages, which I have quoted above as making no sense. However, it exists in Wikipedia and is considered as complying with the general rules. Why would those rules not be applicable to the settlements in Romania. And if we have new rules for Romania, why would they not be applicable for other countries too. Just as Biruitorul has replaced articles for villages with redirects, why would we not make the same corrections for the villages of Leezen Amt and the rest of Germany as well as for Culpepper District and the other districts of the United States? The entire discussion does not answer this question. Afil (talk) 05:04, 22 October 2011 (UTC)

Proposal for Henrik's 'Page View Statistics' to have official Wikipedia support

In view of the fact that yet again Henrik's Page View Statistics' is not doing its job: for example, for the Yeung Kui-wan article: from 1 Oct, to 4th Oct, 2011, then fixed and now [14 Oct] it is 4 days adrift), it is sad (and a great pity) that such a great tool doesn't seem to get official Wikipedia support. For me, as a fledgling contributor, it is essential to be able to follow the evolution of hits on 'my' articles' on a daily basis. It also seems to be very popular with many other contributors.

So, I plead that someone 'up there' has a look at this tool and makes it an official, Wikipedia function, which will be maintained on a regular basis. Please advise what are Wikipedia's policy and planning for this tool.

It would be perhaps interesting to set-up a poll to sound out just what is the level of interest in Henrik's 'Page View Statistics'.

I hope this forum is the right place in the panoply of Wikipedia forums for this plea. [Note I am advised that this is the case: "The correct place would probably be Wikipedia:Village pump (proposals)".-- Obsidi♠n Soul 07:30, 4 October 2011 (UTC)"] Duncan.france (talk) 01:05, 14 October 2011 (UTC)

This great thing that you want us to either support or fix (it's not clear to me yet): what is it and where would we find out more about it? Who is Henrik? And what of Esmerelda? — JohnFromPinckney (talk) 02:01, 14 October 2011 (UTC)

See Help:Pageview stats; the tool is maintained by Henrik (talk · contribs). -- John of Reading (talk) 07:32, 14 October 2011 (UTC)

Just to be clear, this refers to stats.grok.se, which apparently relies on data from dammit.lt, a site which appears to be down at the moment (perhaps explaining the problems with Henrik's tool). According to [6] [7], the man to talk to is Domas Mituzas, aka midom (talk · contribs).

Henrik's tool is well-used, especially by WP:RFD and WP:DYKSTATS, and it is linked from every history page. It is fairly important to have such a tool in good working order. — This, that, and the other (talk) 09:21, 14 October 2011 (UTC)

There was once a superstition against making page-view statistics available (I think there was a fear that people might hit pages deliberately to increase the statistics, or something). But now we have an external tool anyway, people find it useful, and it doesn't seem to lead to abuse, perhaps the developers would be persuaded to make such information available on-wiki (so it's not dependent on an outside site being up).--Kotniski (talk) 10:14, 14 October 2011 (UTC)

Page view stats is already available from the link on all page histories. It works perfectly, is very fast, and is indispensable for some work. Kudpung กุดผึ้ง (talk) 10:18, 14 October 2011 (UTC)

Trouble is, it's a bit intermittent. — This, that, and the other (talk) 11:03, 14 October 2011 (UTC)

Henrik's page view tool is great but it does go down from time to time. If Henrik is busy or out of town the tool may be down for a week. This tool should be supported by more than a single volunteer. -- SWTPC6800 (talk) 02:21, 15 October 2011 (UTC)

If that's the case, then yes. Kudpung กุดผึ้ง (talk) 06:04, 15 October 2011 (UTC)

It's a bit depressing to think that all this data gathering is thanks to one Lithuanian database engineer (Domas Mituzas). None of these tools (except it seems http://en.wiki-watch.de/ ) will work when the server in Lithuania is down. And let's face it, it doesn't look like the foundation is going to help any time soon. Maybe they see it as potentially opening a can of worms, "official" view statistics that can be manipulated from outside would make them an easy target for critics. Any solution will have to come from volunteers I think. Split up the data from the squid server logs, send to multiple clients so each receives all data on their share of the articles, and set up a p2p network to distribute the data to anyone who wants it, providing a robust backup system, redundancy, load balancing... DS Belgium ٩(͡๏̯͡๏)۶ 13:04, 15 October 2011 (UTC)

The raw stats are now being made available through WMF servers, so I suppose that Domas maybe no longer needs to maintain his site. I guess Grok hasn't migrated. Way back when, we didn't have page view stats, not because of philosphical objections, but because the servers couldn't handle the load required by logging. This was resolved by embedding a "bug", if I remember correctly, which picks up a hit on another server that basically did nothing but log. Rich Farmbrough, 17:45, 16 October 2011 (UTC).

In response to the 'optimistic' observation of Kudpung กุดผึ้ง (talk), I recommend that he look at : http://stats.grok.se/en/201110/Yeung%20Kui-wan (obtained using the quoted Henriks' website: http://stats.grok.se/en/latest/Help:Pageview_stats. As of now (17/10/2011), this shows, no data after 7/10/2011... for the 'Yeung Kui-wan' article!! Now, how is that "working perfectly"??? Please, please, will someone 'up there' support this very useful (and popular) 'service'??Duncan.france (talk) 10:37, 17 October 2011 (UTC)

It now shows data till 16/10/2011. Domas server was up for a while today, (well, yesterday, 5 hours ago) but stopped responding 2:40 hours ago. Long enough for Henriks' site to download the data it seems. DS Belgium (talk) 01:57, 18 October 2011 (UTC)

I looked at http://www.wikiroll.com/ he sais "Using Amazon AWS services I discovered that "Wikipedia Traffic Statistics" data in freely available". I found this http://aws.amazon.com/search?_encoding=UTF8&searchQuery=Wikipedia but still can't find the source!! Goddamn! Probably missing something obvious.. 4:08 am, time to sleep DS Belgium (talk) 02:10, 18 October 2011 (UTC)

Just out of interest, how do people know this is not doing its job? I thought that if one went to the article history, one could click on "Page View Statistics". I am willing to bet that sometimes this might be a little slow, but could there not be template to indicate this, as there is when one clicks on one's "Edit Count"? ACEOREVIVED (talk) 15:58, 20 October 2011 (UTC)

well, it's still working perfectly for me at Malvern,_Worcestershire and I use it a lot because it's a GA I wrote. Why can't it be hosted on the ToolServer?

Just want to 'plus one' this call. The page view data is very valuable for research and for explaining to people how important Wikipedia is. Its an important data point for recruiting and keeping editors as it gives them some great positive feedback that their work matters. Whether its Henrik's tool or another, please support access to page view data. Benjamin Good (talk) 22:57, 20 October 2011 (UTC)

In answer to ACEOREVIVE's query as to how one can tell whether Henrik's page-view statistics are doing their job or not, I keep an on going record of the hits on 'my' articles 'Yeung Kui-wan' and its redirect 'Yang Quyun'. I have observed the following anomalies:

1) Periodically, the data for a number of days 'jump' to a different set of days. This occurs at times when 'the server is down'(?). When the 'server comes back on-line' (say), the data-set jumps to the correct days.

2) There are days when zero hits are shown in both articles. Surprisingly these 'zero-hits' days are off-set by one day.

3) The last days of data for 'my' two articles are always off-set by one day [the redirect being one day behind]. I am not sure whether this is an error or not.

Hope that is clear... Suffice it to say, that the effects I am trying to describe are VERY frustrating...

Please can the powers that be up there in the Wikipedia hierarchy take this service under their wing. This would hopefully prevent such anomalies.

Having said that, Henrik's service, frustrating as it is at times, is preferable to having no hits stats at all.Duncan.france (talk) 03:59, 23 October 2011 (UTC)

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? Sven Manguard 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 Wikipedia: 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 Wikipedia: WikiProject Environment. ACEOREVIVED (talk) 15:21, 20 October 2011 (UTC)

Expanding the use of the {{SWL}} template

We (User:Pleiotrope, User:i9606) are thinking of expanding the use of the {{SWL}} template in article space and would like to have some community input. Basically, the {{SWL}} template allows editors to encode semantic information within the article space. The semantic information winds up as a machine-readable representation of a relationship hidden in the HTML that could later be extracted and used in a number of different ways.

For example, the SWL template could be used to encode the attributes of animals. Using the Spotted Owl as an example, we can alter the following sentence to encode its nocturnal behavior:

It is a strictly [[nocturnal]] [[owl]], which feeds on small mammals and birds.

into the following:

It is a strictly {{SWL|type=behavior|target=nocturnal}} [[owl]], which feeds on small mammals and birds.

The two render identically, except that the {{SWL}} addition adds a faint orange underline to the wikilink, which shows a tooltip describing the relationship if the user hovers over it. In practice, the {{SWL}} template would be used selectively across the article to encode the fundamental attributes of the Spotted Owl; we think judicious and limited use of the template would be ideal to prevent cluttering of the markup.

We’ve also developed a userscript that demonstrates the usefulness of these relationships. The script parses the SWL templates in the article and, if prompted, highlights them and displays an infobox describing each relationship and target. This allows for fast and concise subject comprehension: for example, on this Spotted Owl sandbox copy (with SWL templates added), the infobox would clearly inform the user that the Spotted Owl is nocturnal, mates monogamously, and lives in North America. The userscript is available here if you'd like to test it out, and a screenshot of the userscript is below if you would rather not (the infobox is above the owl infobox):

We would appreciate any feedback or thoughts the community has regarding this concept; if it's something worth discussing more formally, we could make it a RfC... but that seems a bit involved at this point. Thoughts? -- Pleiotrope (talk) 23:38, 18 October 2011 (UTC)

Is there a reason this isn't incorporated into the infobox? --Philosopher ^{Let us reason together.} 19:39, 19 October 2011 (UTC)

From the reader's perspective, this userscript gives context to each asserted fact. It also allows the addition of new fields that do not exist in the relevant infobox (perhaps because they are too specific). In addition, it allows users to clarify the relationship if they find it to be imprecise; for instance, "behavior = nocturnal" may be better represented as "active_period = nocturnal" or something like that, which would be quickly fixable by casual editors. In addition, infoboxes tend to be "least-common-denominators" of their subjects. By continuously adding conditional fields to the infobox for attributes that may, for example, only apply to owls, the maintainability of the infobox decreases for only marginal benefit. Do you agree? --Pleiotrope (talk) 21:09, 19 October 2011 (UTC)

The casual editor is likely to strip out the template entirely, because they can't make heads or tails of it and just want to update the article to correctly link to nocturnality. --Carnildo (talk) 02:03, 20 October 2011 (UTC)

The promise of semantic coding to replace the current infobox method is the much greater flexibility and reusability; I think the immediate applications would be the ability to rewrite and recombine articles in different formats (for example, solving the perennial AfD disputes over whether we can justify small articles or need to combine them, by permitted the display in either manner), and to improve findability by providing a basis for intersection of categories; in the longer term I foresee a fill in the box approach to routine articles. Perhaps the casual editor is not ready for this, but neither is the casual editor able to properly organize articles. Doing either right takes discipline and organization. DGG ( talk ) 04:32, 20 October 2011 (UTC)

I'm far from expert (in fact I was introduced to this idea by seeing/reading this proposal) but am sure there is a great value in embedding data in such a way that scripts can use the page more effectively. I would like to see a standard devised/constructed to shape the use of this template. Without a standard form this template might be used in so many different ways that scripts would be no better off reading the embedded data than reading the page without it. In the OP's example we see 3 types with each their targets. type=behaviour 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^TC 05:26, 20 October 2011 (UTC)

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^TC 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 . 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^TC 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! -- fg^TC 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 ({{SWL|type=type_of|target=horse}}. 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 <ref></ref> 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 and 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 "{{SWL|type=behavior|target=nocturnal}}" 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 {{SWL|type=behavior|target=nocturnal}} [[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)

Tool request

Can anybody create or does a tool exist that can check all revisions of an article and identify when a particular string of characters appears in the article, preferably checking the revisions in reverse chronological order? That means from the current revision the tool should check backwards through all prior revisions and identify the first revision, where the string does not appear and then output the previous revision (which necessarily would be the first revision, where the string was introduced). Toshio Yamaguchi (talk) 13:21, 19 October 2011 (UTC)

History → Revision history search. ---— Gadget850 (Ed) ^talk 13:24, 19 October 2011 (UTC)

I think this is what you are looking for, http://toolserver.org/~soxred93/blame/ GB fan 13:25, 19 October 2011 (UTC)

Hmh, thanks for the replies. When I enter AB Album 2010 into the text search field for the article Ahmed Bukhatir I get this diff by Yobot. However then inserting AB_Album_2010.jpg finds what I need. What an awesome tool. Thanks a million. Toshio Yamaguchi (talk) 13:40, 19 October 2011 (UTC)

There is also this: http://wikipedia.ramselehof.de/wikiblame.php. Helder 14:01, 19 October 2011 (UTC)

Thanks. Much appreciated. Toshio Yamaguchi (talk) 14:11, 19 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 : meta: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 ([8]) 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:

---

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:

(...)

Recommendations 2 and 3

(...) 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.

---

...to which I wrote this response on meta:User talk:Sj.

Another feature of WikiKids/Vikidia is of course that it let children be involved in building the content, and does not "only" aim to produce and offer content for children, for the same benefits that you can find in Wikipedia-editing workshops for students. There is both some school projects and volunteer (and often enthusiastic) children editing on Vikidia along with teenagers, students and adult writers.

I do have in mind that there is Simple English Wikipedia, whom no other equivalent have been created in any other language. I guess that it would make less easy to create a wikikids in english, as it would be partly similar to simple. I would also say that the fact that this wiki is not so big and hasn't been created in other language may show that its aim would not be so clear, mobilizing and justifying. By the way, on Vikidia, we do hope to be usefull not only to children but to people of any age that would like a simple approach of a subject, or a shorter one than on Wikipedia. We beleive that if its content were not relevant to older people, it wouldn't be good either for children.

My question is of course: why is there no Wikikids in English yet ? ;-)

Greetings, Astirmays (talk) 18:04, 20 October 2011 (UTC)

Well, as your quote mentions, there is wikibooks:Wikibooks:What is Wikijunior?. But with regard to your propopsal, I wonder if this is really the right forum for discussing this? It seems like you are proposing an English-language version of Vikidia, but Vikidia isn't a WMF project... --Philosopher ^{Let us reason together.} 22:04, 20 October 2011 (UTC)

On second thought, if you are proposing a new WMF project, the correct place for the proposal is at Meta's m:Proposals for new projects. --Philosopher ^{Let us reason together.} 22:05, 20 October 2011 (UTC)

Actually, this project is not the same as Wikijunior. It is a Wikipedia-like project, which Wikijunior isn't. Secondly you are right. The right place is meta:Wikikids. However, would it be a WMF project or not, I think that it is worthwhile to sound out wikipedians about it. Just as other wikis or other enterprise, its realization depends in the first place on a few people to undertake it. That's a call to them.

By the way, here are (among others) two other discussion on that subject: in June 2008 and July 2010.

Another thought, one may even link this projet with one articles of the convention on the Rights of the Child which is the following:

---

Article 13

1. The child shall have the right to freedom of expression; this right shall include freedom to seek, receive and impart information and ideas of all kinds, regardless of frontiers, either orally, in writing or in print, in the form of art, or through any other media of the child's choice.

2. The exercise of this right may be subject to certain restrictions, but these shall only be such as are provided by law and are necessary:

(a) For respect of the rights or reputations of others; or

(b) For the protection of national security or of public order (ordre public), or of public health or morals.

---

Last thing, the point of this message was also to address the "I don't think it can work well" objection, associated with issue such as vandalism, censorship, defining the appropriate content, children motivation and ability to edit articles... since it does work well at least in two language, where there is children, teenagers and adults working together to better the wiki. And thousands of readers every days.

Greetings, Astirmays (talk) 00:59, 21 October 2011 (UTC)

If you wanted a wikipedia in simple french, yoou should of voted in the request for comment. This pretty much a prennial proposal. ~~Ebe123~~ (+) ^talk
_Contribs • 10:52, 21 October 2011 (UTC)

I don't want a Wikipedia in simple french, because: - I beleive that a wiki designed for children is a more judicious feature than aiming to be written in a simple language - because their scope would intersect quite a bit - and at last because Vikidia allready exists.

The point is to suggest to launch an encyclopedic Wiki for children in english (and possibly other languages). Astirmays (talk) 15:17, 21 October 2011 (UTC)

There was just a discussion of this in Jimbo's talk page. It was pointed out that we already have a Kid's English Wikipedia: Wikipedia CD Selection. It is on CD, not online, and it is not editable. All that would be required would be to put this online. This would not be too hard, since all the work has already been done and it already exists. If we just wanted to put this on-line and make it official Wikimedia offering, that would be trivial. It is already a bit out of date and would become more so, but that is not so terrible. If we wanted to make the basis of an editable, updateable project that would take a bit more work, but much less than starting from scratch. I would probably favor this. I'm not sure where to begin to make this happen -- possibly at Wikimedia proposals for new projects as mentioned, or maybe just lobbying Jimbo and Sue and on the mailing lists? Somebody has to be willing to do this political work. While I'm supportive, I'm not that interested and so it won't be me. But it should be doable. Herostratus (talk) 15:29, 21 October 2011 (UTC)

Thanks for this info. I found this discussion here. Actually, the 2008/9 Wikipedia Selection for schools is online there, thought it has no search engine.

A wikikids project has to be editable (and maintained with the same methods as Wikipedia) See above: "The child shall have the right to (...) seek, receive and impart information..." I think that the Wikipedia Selection doesn't fit to provide a base content because articles have been checked but not rewrited to be easily readable by children. A possibility is rather to use and import content both from b:Wikijunior and Simple: when it fits to this project. That would make it possible to start much faster that from scratch. Astirmays (talk) 20:30, 21 October 2011 (UTC)

Does Wikipedia need a “share” button?

• RfC tag added on 09:34, 22 October 2011 (UTC).
• NO, Facebook will NOT track what you read, there are ways to avoid that. —TheDJ (talk • contribs) 15:22, 22 October 2011 (UTC)
  • They won't directly track you, like they do with anything that has a unified login with Facebook, but they can still connect information every time you click the Wikipedia share button... and then sell that information to advertisers the same as if you used their button. Anything that posts to Facebook, no matter what we do on our end, gives them information, which they will sell, period. Sven Manguard Wha? 07:56, 23 October 2011 (UTC)
    • That amount of information is absolutely trivial/minute and, as you said, inherent to using Facebook; a Facebook user has already accepted such terms. https://www.facebook.com/sharer/sharer.php?t=Main_Page&u=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMain_Page gives Facebook (from Wikipedia's end) no more information than if the user had shared the article directly, besides that the user came from said Wikipedia page. --Cybercobra (talk) 08:10, 23 October 2011 (UTC)
      • Sven; the implication if someone clicks "share to Facebook" is that they wish to, well, share it on Facebook :) Whatever your or I think, politcally/morally, about Facebook isn't really relevant if readers want to share on FB. An they do... --Errant ^(chat!) 09:39, 24 October 2011 (UTC)

Recently, on wikitech-l there was a discussion about adding a “share” button to Wikipedia. Someone suggested that this should be discussed here. Is this something that people would find useful? — ☠MarkAHershberger☢(talk)☣ 16:13, 21 October 2011 (UTC)

Do you mean you want a social networking button to spam your friend's talk pages with articles that you like? I'm not sure I'd find that useful, but there may be some who do. RJH (talk) 18:33, 21 October 2011 (UTC)

I guess he means something like this. emijrp (talk) 18:37, 21 October 2011 (UTC)

No, more like the below-mentioned SignPost version. --Lexein (talk) 08:13, 24 October 2011 (UTC)

He means a social networking button to let Facebook track what you're reading on Wikipedia, so that the data can be sold to advertisers. --Carnildo (talk) 01:06, 22 October 2011 (UTC)

No, he does not mean a tracking "like" button, which is why he used the word "Share". "Tracking" and "privacy" are just irrelevant FUD here. People pass information to other people, and in doing so, identify each other to each other (many times by pseudonyms, which vary). Get over it. --Lexein (talk) 08:13, 24 October 2011 (UTC)

.... which flies in the face of the whole separation of Wikipedia and commercialism thing that everyone seems to agree is really important. Sven Manguard Wha? 12:20, 22 October 2011 (UTC)

It's extremely easy to craft a version of this that does not permit such tracking to occur. --Cybercobra (talk) 08:18, 23 October 2011 (UTC)

Such as the below-mentioned SignPost version. --Lexein (talk) 08:13, 24 October 2011 (UTC)

• Strong Oppose This same like/share idea comes up every month, sometimes several times a month, and gets shot down by a wide margin. Wikipedia is a) not a social networking site, b) has fundamentally different objectives from social networking sites, and c) a community of people who by and large do not enjoy the idea of linking their Wikipedia accounts to their real life identities. There are many, many other reasons why this keeps getting shot down, but suffice to say that a like button would probably have a negative impact on editor retention, there's already quite a bit of grumbling about the perception that Wikipedia is moving towards the social network model in one way or another. Sven Manguard Wha? 18:39, 21 October 2011 (UTC)

A share button is for sharing content, and that is a Wikimedia goal. Sharing buttons have existed before any social network, nobody remember the "mail this link" buttons? Obviously, may be privacy problems, but we can think other solutions.

And about "a like button would probably have a negative impact on editor retention" you know what I say --> <-- . Regards. emijrp (talk) 18:58, 21 October 2011 (UTC)

Just because wikipedia isn't a social networking site doesn't mean that its mission couldn't be advanced by allowing people to more easily share WP articles on social networking sites. I mean, the New York Times' website isn't a social networking site either, and they allow you to share their articles on social setworking sites. I can see how maybe there would be concerns about whether or not the "share" button constitutes an advertisement, but overall I think this is a pretty good idea. Nobody's trying to force you to link your facebook profile on your user page. This request is about making it more easy for people to share articles they find interesting. AgnosticAphid talk 21:01, 21 October 2011 (UTC)

I view a Share button as a distraction - otherwise it would be perfectly acceptable.Jasper Deng (talk) 21:35, 21 October 2011 (UTC)

Wikipedia is a publisher of reliably sourced knowledge. The "Create a book / Download as PDF / Printable version" buttons are publishing tools, and are not distractions. A Share button (as implemented at SignPost) is no different. It could be next to "Create a book", or next to "Read/Edit" (whichever is less distracting. It merely allows publishing to other venues and people. WP is an advertiser, as we radically internally link our articles. We also "advertise" our sources, in the References and External links sections. The Share button advertises nothing but other venues for our content, for the purpose of bringing in prequalified readers to specific articles, with the intended side benefit that those readers might become editors,which the Foundation has stated is a desirable goal. --Lexein (talk) 02:44, 24 October 2011 (UTC)

• Strong oppose - anybody can do a simple URL for a Wikipedia article now. What we would really be doing would be serving as enablers for the creators of spam and vanity articles, for the paid "editors" showing their employers that they've delivered the goods, and for the vandals (and POV pushers) who want to show off what they've done to Wikipedia articles. I can see the messages now: "o wow the lolz see what I did to show that our skool is run by zombies and principle zanexki is a jew pedofile - rotfl - wiki is so totaly pwned!!!!" --Orange Mike | Talk 21:16, 21 October 2011 (UTC)

On a more personal note: if I wanted to play Farmville or win free jewels for my Gaia Online avatar, I'd be doing that. Instead, I'm trying to help build an encyclopedia, not show off my drawings of my imaginary flying unicorn best friends! --Orange Mike | Talk 21:32, 21 October 2011 (UTC)

But, as you note, this is already possible. You just have to enter your "o wow teh lolz" post manually with a manual reference to the wikipedia article. Is there a current problem with paid editors doing this? I didn't realize vandalism was such a problem. Is there some way to address related issues (I'm not well-versed technologically, really, but maybe artificially inflated search engine rankings or something?) within WP? This proposal presents the question of how user-friendly it's going to be to share wikipedia articles on networking sites. I feel like your comment is more oriented toward banning links to wikipedia articles altogether so that they can only be found by searching google or the home page. What's the point of purposely making it kind of difficult to share links and find articles? I feel like WP's goals would be better served by making it easier to access content. AgnosticAphid talk 21:29, 21 October 2011 (UTC)

It is precisely that difficulty that discourages the sharing of pages by drive-by vandals/spammers/ego boosters -- the additional time and effort to figure out you can do this and to copy and paste the URL over isn't worth it. MER-C 05:08, 22 October 2011 (UTC)

• Support. We want to drive traffic to the site. Anything that gets us more readers and more editors is a good thing. Virtually every modern web site has Share buttons, from the BBC News[9] to Harvard University.[10] Quite honestly, Wikipedia is out of step with world.A Quest For Knowledge (talk) 21:25, 21 October 2011 (UTC)

• Wikipedia has an Alexa rank of 5. Is more traffic really needed? →Στc. 01:25, 25 October 2011 (UTC)

• Oppose. Wikipedia isn't a social networking site, and this would just distract from the main purpose of Wikipedia, which is to edit and improve it.Jasper Deng (talk) 21:28, 21 October 2011 (UTC)

  The main purpose of Wikipedia is to read it. ▫ JohnnyMrNinja 21:01, 22 October 2011 (UTC)

• Comment: (edit conflict) Here is a previous discussion on this topic, in case it would be helpful: Wikipedia:Village pump (proposals)/Archive 74#Link to Facebook.

Please tell me exactly how a Facebook "Like" button and "Like" counter will do good for Wikipedia? I have little doubt that the Facebook article would get zillions of "Likes" if we added a "Like" button and "Like" counter to Wikipedia articles, because obviously our obsessed-with-Facebook-and-Twitter world really, really likes Facebook. We already have "Rate this Page" boxes at the bottoms of articles that allow readers and users to rate how Trustworthy, Objective, Complete, and Well-written articles are, so please tell me how the Facebook "Like" rubbish will do good for Wikipedia.

Regards,

—{|Retro00064|☎talk|✍contribs|} 21:34, 21 October 2011 (UTC).

I don't want to speak for the OP, but they are suggesting a Share button, not a Like button (which I agree, would be dumb). A Quest For Knowledge (talk) 21:44, 21 October 2011 (UTC)

You could say that I was directing that comment at Erimjp's comment above. As for the "Share" button, I have no opinion except a request that, if the "Share" button is implemented, it be made as maybe a gadget that can be turned on and off in Special:Preferences. I do not want to have the Facebook and Twitter icons/links staring at me on Wikipedia. I am just going to sit back and watch the community slug this out. —{|Retro00064|☎talk|✍contribs|} 21:53, 21 October 2011 (UTC)

We already have a de facto "Like" button; it's the Wikipedia:Article Feedback Tool. –MuZemike 18:59, 22 October 2011 (UTC)

• Comment The purpose of Wikipedia is not to edit it (stated above). The purpose is for readers to learn stuff. If readers learn something and want to share it, I think that's a great thing. I'm not opposed to sharing in any fashion but find "share this" buttons unpleasant due to my personal dislike of most social networking sites (I like real friends and prefer to not be collected) and would prefer to not be so frequently reminded of them. Not opposing or supporting. -- fg^TC 21:40, 21 October 2011 (UTC)

• See User:TheDJ/Sharebox. If anyone wants to propose it as a gadget, then do so. ---— Gadget850 (Ed) ^talk 22:21, 21 October 2011 (UTC)
• Oppose This is not a social network, and it shouldn't give the appearance of one. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 22:31, 21 October 2011 (UTC)

Comment: Well, behind the scenes, WP really is a single-purpose, single-output closed social network of editors, closed in the sense of not interacting outside Wikipedia. But simplifying distribution of content to external social networks, as a user option, and/or a login checkbox option, does not devalue WP or distract from WP's goal. I see it as a publishing tool similar in value to "Create a book / Download as PDF / Printable version". --Lexein (talk) 22:56, 21 October 2011 (UTC)

• Strong support as a Preferences Gadget which simplifies publishing Wiki content (URL, Article title, highlighted text), out to social tools. I do not support any non-native gadgets like Facebook "Like" buttons which track IP addresses or place cookies. I expect this would a very popular gadget anyways. It would also accelerate bringing in new editors, a very desirable thing, according to the Foundation. Wikipedia's purpose is to be an encyclopedia which is wide open to dynamic improvement and expansion. The more people share out (publish) WP content, with WP URLs, the more likely more editors will come in and correct and expand. On a personal note, I've been impressed by the increased number of quality IP edits in my watchlist lately. Hopefully that's not a temporary thing. I would also support offering this as a checkbox option at both signup and login. --Lexein (talk) 22:56, 21 October 2011 (UTC)

• Oppose for now on the aesthetic grounds that it looks non-serious. Other than that I really don't mind; there have been times that I've sort of wished for such a button myself. But I think it's important for Wikipedia not to go too populist, image-wise. There may come a point when such buttons are so routine that no one would think of them that way, and then I would withdraw my objection. (By the way we should also get rid of Wikilove and the "ratings" bars at the bottom of articles, for similar reasons). Now you kids get off my lawn. --Trovatore (talk) 23:09, 21 October 2011 (UTC)

Trovatore: Can you please take a look at this article, UCLA Neurosurgery gets $2M donation to establish endowed chair in epilepsy research? I don't think that the Share button makes that site look non-serious. A Quest For Knowledge (talk) 23:19, 21 October 2011 (UTC)

The users of that site only read. The users of Wikipedia also edit. No unnecessary distractions like "Share" buttons please.Jasper Deng (talk) 23:22, 21 October 2011 (UTC)

Perhaps more to the point, that's a public-relations-slash-news-release. It's not an encyclopedia article. PR people and journalists will have "share" buttons and this is expected. But we don't do PR and we don't do journalism. We're expected to be just a bit stodgier than that, and if we're not, it reflects negatively on our seriousness. --Trovatore (talk) 23:28, 21 October 2011 (UTC)

Trovatore: Well, how about Nature (journal), the world's most cited interdisciplinary scientific journal according to the Science Edition of the 2010 Journal Citation Reports?[11] I think that is stodgy enough. A Quest For Knowledge (talk) 23:39, 21 October 2011 (UTC)

It's a journal. It's not an encyclopedia. --Trovatore (talk) 23:40, 21 October 2011 (UTC)

OK, if you want an encyclopedia, the Encyclopedia Britannica has a Share button for their articles.[12] A Quest For Knowledge (talk) 23:45, 21 October 2011 (UTC)

They also have tons of ads. Presumably the only way they can pay for it, but sorry, looks unprofessional. --Trovatore (talk) 23:53, 21 October 2011 (UTC)

Trovatore: Adding a Share button doesn't mean we also have to have ads. In your opinion, which sites do look professional to you? A Quest For Knowledge (talk) 00:05, 22 October 2011 (UTC)

Other sites are not particularly relevant. This is my opinion of what is best for the image of Wikipedia. Yours is obviously different. You have the right to a different opinion, but I have expressed mine, and others will agree or disagree based on their own intuitions. --Trovatore (talk) 00:09, 22 October 2011 (UTC)

Don't forget that I think people are not talking about a large, glaring, separate button, but an (optional) same-color addition to the Read/Edit/star/ row with a dropdown menu. I think. --Lexein (talk) 00:27, 22 October 2011 (UTC)

• Oppose(edit conflict × 2) I really feel that a share button would be counter-productive to our mission. People (especially younger editors) would use it like a Facebook page. And I feel it would clutter the workspace.

Also, one of the things that would need to be discussed would be how the system would work. Would it be visible to anonymous editors? Which buttons would be available? (we'd have to be careful with our selections. People might view it as "endorsing" a certain site.) I feel like this is an area that is a huge can o' worms. Just my 2¢. ~ Matthewrbowker ^{Say hi!} 23:56, 21 October 2011 (UTC)

In my vision, it would live next to the Read/Edit buttons, like the Twinkle button with a dropdown menu. For IP editors, it would be On by default, because though we don't know, and don't want to know, their identifying information, only the destination website wants it. Sharing could be Off by default, but controllable by registered users: enabled by a checkbox at login time, or permanently in Preferences/Gadgets. In Preferences, a long list of checkboxes for destinations is presented, this controls the length of the dropdown list. I'm looking for good examples of Share buttons which preserve privacy until the user is at the destination site. http://AddToThis.com is a good visual example, though ours would be handrolled. There may already be an open-source example. --Lexein (talk) 00:23, 22 October 2011 (UTC)

• Comment A possible issue: Many vandals add to their contributions little notes that seem to indicate that they will share their work with others. Making it quicker and simpler could encourage greater vandalism. I think the possibility is not so great that we should panic unduly but, I think it is a possibility. However, if employed "share buttons" could have their use stats monitored so that admin could quickly decide if (on regularly vandalised pages) the button is being used often immediately after a vandal has contributed and follow it up with a (perhaps limited term) disablement.

Further Lets not forget that Wikipedia is all about sharing knowledge. This idea should be considered an extension of that goal. -- fg^TC 00:00, 22 October 2011 (UTC)

• Decided to support Even though I vehemently dislike most social networking sites, they are popular and Wikipedia has a lot to offer. I would like to see people reference it more easily and often. -- fg^TC 00:00, 22 October 2011 (UTC)
• Question: What does a "share" button do exactly? What things would change here if implemented? Does the button changes something here when pressed, or does it change something in facebook? (I don't want to interrupt the discussion, just point me an article or page with this info, and I will formulate an opinion later). Cambalachero (talk) 00:36, 22 October 2011 (UTC)

A share button would not change Wikipedia articles at all. It would add a (possibly formatted) link to the wall of the user at the social site being shared with. It's a simple way to say "Hey guys! Look what I found." -- fg^TC 00:42, 22 October 2011 (UTC)

It would be a huge distraction to the editors of Wikipedia, though, and an unnecessary use of Wikimedia's resources.Jasper Deng (talk) 03:29, 22 October 2011 (UTC)

Jasper: You have said repeatedly that it would be a huge distraction to the editors. I'm an editor and it wouldn't be a distraction to me. Please speak for yourself. I fail to see how it would be distracting to anyone. As mentioned in the discussion it would probably be no more than a tab atop the articles that would only be enabled by choice. As for the resources: It would use few of them compared with everything else that's going on here. I sincerely doubt it would be more than a drop in the ocean as far as measurable server strain would be concerned. -- fg^TC 04:20, 22 October 2011 (UTC)

We're here to build an encyclopedia, not a social network. A "share" button encourages WP:NOTHERE (in a different way than usual) by encouraging new users to simply use Wikipedia as a "hey, look at this" medium, instead of useful editing, which is what we want. Server resources would be wasted answering all of that.Jasper Deng (talk) 04:30, 22 October 2011 (UTC)

You have offered no evidence that a share button (implemented either as seen at Sign post, or as a discreet bar button next to "read/edit") would encourage WP:NOTHERE. A test of the feature would measure the frequency of this occurrence (if any). I advocate testing, anyways. --Lexein (talk) 06:58, 23 October 2011 (UTC)

• Oppose: Facebook is known to use those buttons to track what people are doing, and I presume the other "share" sites do the same. I don't know about you, but I'm opposed to letting anybody track my Wikipedia reading habits. --Carnildo (talk) 01:10, 22 October 2011 (UTC)

• Then don't share. Marcus Qwertyus 01:15, 22 October 2011 (UTC)

• Sadly, it's not that simple; it appears that Facebook (and probably others) record reading pages with those buttons in, even without them being used. If we can find a way to prevent this, it wouldn't have to be not a game-killer, but the standard implementation currently in use is problematic. Shimgray | talk | 12:13, 22 October 2011 (UTC)
• Is there record of Facebook ever using this information for purposes other than advertising? Marcus Qwertyus 17:17, 22 October 2011 (UTC)

• Strong support Not willing to share? Now we see who are the real information hoarders! Jidanni (talk) 01:12, 22 October 2011 (UTC)

• Not willing to share? I assure you, if you search up anything in Google, the relevant Wikipedia article will be within the top 10 search results. We have our information available, and all the readers must do is find it. →Στc. 01:25, 25 October 2011 (UTC)

• • See my next comment.Jasper Deng (talk) 03:29, 22 October 2011 (UTC)
• Support - Sharing is good. Marcus Qwertyus 01:15, 22 October 2011 (UTC)
  • Not if it distracts editors from actually improving Wikipedia.Jasper Deng (talk) 04:30, 22 October 2011 (UTC)
    • I have yet to be distracted by the new "Wikilove" icon. If it makes Wikipedia more fun then edits and productivity will go up. Marcus Qwertyus 04:24, 22 October 2011 (UTC)
      • (edit conflict)Wikilove is actually related to editing, as a simple tool for our awards system. A "share" button is not the same.Jasper Deng (talk) 04:30, 22 October 2011 (UTC)
• Oppose. Wikipedia is not a social networking site, nor supported by ads. If newpspaper and magazines want to have blogs for each article and share/like/follow/tweet buttons, that's their decision. It shouldn't be ours. — Arthur Rubin (talk) 02:42, 22 October 2011 (UTC)
• Strong oppose. Wikipedia is not a social networking site and it's already in danger of becoming one. Sharing it would agtract the wrong kind of dialogue to talk pages, and worst of all, it would attract more vandalis and more unwanted new pages. Wikipedia is doing fine as it is, but new page patroll, vandalism patrol, and AfC are already overburdoned. Kudpung กุดผึ้ง (talk) 03:13, 22 October 2011 (UTC)

Hm. There's no danger of WP becoming a "social" social network - several wide-ranging and highly social initiatives have already come and gone - I can't remember their names. You've offered no evidence to support the claim that a Share button would add to "the wrong kind of dialogue." Testing, of course, would prove or disprove your thesis. --Lexein (talk) 18:35, 24 October 2011 (UTC)

• Support. Adding to other "support" points mentioned above:
  • This feature would be for our readers, not our editors. Readers might find a quirky tidbit that they want to share with their Facebook friends, for example. Wikipedis was hailed as one of the most significant Web 2.0 sites, and we should embrace "social browsing" such as Share buttons.
  • Many editors would not care about this sort of thing, and I can imagine that many would disable a "Share" tool, just as many editors turn off the Article Feedback tool and the Vector skin. (I'm not one of them.) But we shouldn't let that hold us back.
  • I find the argument that "it would distract from the purpose of building an encyclopedia" a bizarre argument, since this would be a reader-facing tool: virtually no readers are here to WP:BUILD - they are here to partake in the "sum of all human knowledge", or whatever Jimbo said.
  • I also find the argument about WP:NOTMYSPACE hard to comprehend - BBC is not a social networking site either, yet it offers this feature.
  • Could it encourage vandalism? Possibly. But it's unlikely to attract the attention of vandals, since sharing features are commonplace across the Web.
  • The only opposing argument I buy is the one about tracking and privacy - this doesn't bother me personally, but it bothers others.
• — This, that, and the other (talk) 04:33, 22 October 2011 (UTC)
  • I agree mostly with your comment, except, what do we do with IP editors?Jasper Deng (talk) 04:37, 22 October 2011 (UTC)
  • The BBC, NYT and Nature aren't editable and hence it is not possible to share a link to a vanity/spam/vandalism page using those sites. MER-C 04:46, 22 October 2011 (UTC)
• Strong oppose. I agree very much with Kudpung and OrangeMike -- this will attract the kind of (l)users we don't want. There is also a real danger of the WMF's Privacy Policy being violated here, especially if the tool is opt-out. MER-C 04:43, 22 October 2011 (UTC)

Again, no evidence offered that articles sent to friends will engender "(l)users we don't want." Anyways, I'd !vote to make sure it's opt-in. Nobody is required to use it. It's just a publishing tool like "Create a book/ Download as PDF/ Printable version". Most readers will likely use it rarely/never, some occasionally, and only a few, frequently. Oh, and because it's a publishing button, it won't be visible on Talk pages, or while editing/viewing history/watchlist/etc., just like the above publishing buttons. --Lexein (talk) 18:35, 24 October 2011 (UTC)

• Comment. Looks like Wikipedia:Signpost has a share button (see "Share this [show]" on the right), so no privacy concerns here? By the way, people here don't know what a social network is. The user pages + userboxes stuff is more like a social network than a button to share a link. emijrp (talk) 08:32, 22 October 2011 (UTC)
• Support wow, the amount of people who simply have NO clue about these share icons, yet strong opinions. First of all, a share button doesn't automatically let Facebook track you, only if you use THEIR share buttons. There are ways to share articles using plain links, that have no privacy problems at all. The signpost uses those, as do many other websites. Also, sharing articles != Wikipedia being a social network and people saying that have 0 clue whatsoever about what that guideline means. It's like saying we shouldn't allow uploading of foto's because 'we are not Flickr". It's the most dense argument in this discussion and noise like this from people who clearly have no idea what our guidelines entail is what stifles many developments within our community. We are about spreading knowledge in a fun and engaging way. If we add PROPER support for sharing articles, then there that can only help our mission. Also the idea that we could attract the 'wrong kind of users' .. sigh, how far the community has fallen into protectionism of 'our knowledge'. You know, WP:OWN in spirit goes beyond a single article. As much as you don't own an article, you don't own the encyclopedia either... —TheDJ (talk • contribs) 09:27, 22 October 2011 (UTC)
  • I don't think your tone about the "denseness" of people and all those rants are warranted. If we're all idiots, then what is your Highness doing here? The fact is that buttons like this give the impression — in terms of style/layout/look — of a social-networking site. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 09:31, 22 October 2011 (UTC)
  • Tone issues aside, TheDJ makes a good point. The Wikipedia Signpost has used sharing buttons for quite some time, without relying on third-party inline frames or scripts - i.e. no privacy concerns at all, unless and until one chooses to click "share". — This, that, and the other (talk) 09:49, 22 October 2011 (UTC)

Sure. And the sign-up form give the impression in terms of style/layout/look of a social-networking/forum site. emijrp (talk) 09:48, 22 October 2011 (UTC)

No, it doesn't. It's as plain and simple as it can get. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 11:59, 22 October 2011 (UTC)

• Support. I have to say, I've been sceptical. But I asked myself: why? There seems to be no good reason to withhold such a feature. It may even help to strengthen Wikipedia's position at a time when it is facing teh editor retention problem. Grandiose (me, talk, contribs) 09:53, 22 October 2011 (UTC)
• Oppose Sharing articles that we are reading on to facebook, like buttons on Youtube? Ridiculous and this would become a conflict of interest and WP:NPOV violation fiasco.Curb Chain (talk) 00:25, 24 October 2011 (UTC)
• Support I can see problems but Wikipedia needs to fit into and try and educate the world as it is. If millions of our potential targets persist in walking in the front of traffic whilst twiddling their thumbs on a smartphone then yeah that's what outreach is. Dmcq (talk) 11:24, 22 October 2011 (UTC)
• Oppose Absolutely not. --cc 12:09, 22 October 2011 (UTC)
• Strong Oppose - I do not want facebook tracking what pages I view/edit. It's bad enough the "like" links are already everywhere (I have AdBlock to deal with them). We don't need them on Wikipeida. All they will do is provide information about pages we access. We might as well grant the facebook employees Checkuser, as that is effectively what they would have. The only difference being, instead of being restricted by a set of guidelines, we have no control of when and how they access this information. I don't mind sharing my knowledge, but I have a big problem with the idea of sharing my personal information with facebook and their non-existent privacy policy. If someone wants to "share" a Wikipedia article, they can copy/paste the URL, or they could use facebook's mirror copy of Wikipedia. Wikipedia is not a social networking site. Adding a set of spam buttons will hinder our attempts at building a neutral encyclopedia. I am here to build an encyclopedia, not wasting time "sharing" edits I've made. We already have such a feature, it's called Special:Contributions. Alpha_Quadrant ^(talk) 14:24, 22 October 2011 (UTC)

This concern has been addressed. There's no way a "Like" button will ever be used - it's a "Share" button which does nothing but navigate to the selected website when clicked. If you don't click on the Facebook link, then Facebook will never know you were here. --Lexein (talk) 18:35, 24 October 2011 (UTC)

• Support, but mostly I wanted to decry the ridiculous amount of misinformation in this discussion. I don't see any way in which a share button allows Facebook to track what pages you're viewing -- on the off chance that it does, coding our own share button would be an easy way around it. I also don't see any way that this feature would "distract" editors; it's a feature for readers, a segment of our audience that seems to get forgotten an awful lot around here. No one who would vandalize an article would be deterred by the absence of a share button. But ultimately -- aren't we supposed to be all about sharing knowledge? Shouldn't we encourage readers to promulgate our articles as far and as widely as possible? Powers ^T 15:57, 22 October 2011 (UTC)

See Facebook 'Like' button draws privacy scrutiny, and it really is a stinker that way. However there's absolutely no earthly reason why it should do anything more than the obvious on Wikipedia so there's no privacy concers for us in providing such facility. Dmcq (talk) 18:01, 22 October 2011 (UTC)

That's the "Like" button, not a Sharing facility. No one has suggested putting the Like button on any Wikipedia page. Powers ^T 19:35, 22 October 2011 (UTC)

Case in point, https://www.facebook.com/sharer/sharer.php?t=Main_Page&u=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMain_Page is just a URL. All Facebook would get is the referer. --Cybercobra (talk) 08:14, 23 October 2011 (UTC)

• Only as a gadget which should be plainly obvious. And definitely no tracking by any third parties. /ƒETCHCOMMS/ 18:29, 22 October 2011 (UTC)
• Weak Support Per User:This, that and the other and User:TheDJ. The feature is reader, not editor, -centric, and (I say this as a computer programmer) so long as we don't use particularly fancy widgets, there will be no danger of tracking. We will still remain WP:NOTMYSPACE since there will be no integration with Wikipedia/Wikimedia user accounts, and all sharing, commenting, etc. will be happening off-wiki. --Cybercobra (talk) 20:25, 22 October 2011 (UTC)
• Oppose  Maybe a third party app could be developed for readers that want a share button.  Then it is someone else's support problem, not ours.  Unscintillating (talk) 21:19, 22 October 2011 (UTC)
• Don't care, but if implemented, than there should be a way to opt out. Sir Armbrust ^{Talk to me} _Contribs 21:24, 22 October 2011 (UTC)
• Support Wikipedia needs additional editors and active readers dipping a toes into the oceans of social networking may help. It is certainly worth testing. Capitalismojo (talk) 22:44, 22 October 2011 (UTC)
• Strong oppose We are not facebook, nor should we be following in facebook's steps. ThemFromSpace 23:43, 22 October 2011 (UTC)
• Support in mainspace only with an opt-out and in the method the Signpost does it. Sceptre ^(talk) 00:05, 23 October 2011 (UTC)
• Suggestion To possibly alleviate some concerns of the opposition, making this feature opt-in rather than having to opt-out might be advisable. -- fg^TC 00:25, 23 October 2011 (UTC)
• Strong Oppose First note, Wikipedia does not *need* a share button. We aren't broken without it. (Even though most of the time I take the opposite side of that argument). Now my main problem with that is 1) A whole whack load of meatpuppets on a new level 2) Mass attacks by recruited people trying to vandalize (I won't say a 5 character name for a site that already does this) 3) It becoming a way to advertise and then if the page is deleted people come to admins talkpages and start going on "YOU DELETEZ MY ARTACALE...U JUS RUIN MY REP WITH MA HOMIES BRO!" or "WHERD THE F**K DID MA PAGE GO!" (excuse my sarcasm and language) 4) Admins flooded 5) Wikipedia is not facebook echoing comments above about Wikipedia already in danger of that. My list is extensive, but i'll leave it there. -- DQ (t) (e) 01:14, 23 October 2011 (UTC)
  • All of those are already possible and happen currently without an integrated sharing feature. We'd be saving submitters one copy-paste; that doesn't seem a huge enough difference to unleash the torrent of badness you seem to be envisioning. --Cybercobra (talk) 02:52, 23 October 2011 (UTC)

That that ugly rant was posted by a Wikipedia admin is something far more fearful than a new way to share knowledge. -- fg^TC 03:17, 23 October 2011 (UTC)

With a whopping 3 deleted edits, you cannot properly comprehend the "ugly rant". →Στc. 01:25, 25 October 2011 (UTC)

• Strong Oppose per Unscintillating. This can all be done browser-side via plug-ins. No need for the project to get its hands dirty if there truly is a need for "sharing".VictorianMutant^(Talk) 01:57, 23 October 2011 (UTC)

• Strong Suggestion - Obviously there has been a mild amount of interest in adding share functionality for a while now. This kind of voting is helpful in-that we can voice some concerns and show the amount of support, but nobody in their right minds thinks we're going to launch social-network features of any kind without testing first, and we don't even have a tool to test. So instead of proposing it, and then debating until we are lukewarm (again and again), why not make a simple gadget? If someone is tech-minded enough, why not make a simple JS tool that adds (locally-hosted) icons to article, portal and file pages (no user, talk or project pages), only visible for users who add the script. We can then refine that tool until it is ready for a proposal. We do not need a consensus for users to write JS, or to use it, and it will only be used by editors knowledgeable enough to know that it exists. So instead of arguing about the problems that might occur based on possible functionality, why don't we hammer together a lowest-common-denominator tool and work from there? ▫ JohnnyMrNinja 05:07, 23 October 2011 (UTC)
  • Because it would not help the encyclopedia. Johnuniq (talk) 06:34, 23 October 2011 (UTC)

If a tree falls in a forest.... What's the point of knowledge if not shared? Why would it not be good for Wikipedia to actively encourage sharing it? -- fg^TC 06:46, 23 October 2011 (UTC)

As one of the top five most visited websites, we don't have the problem of trying to get our content out. Yours is a false argument. Sven Manguard Wha? 07:56, 23 October 2011 (UTC)

Making it easier to "get our content out" (I prefer to think of it as the content) is what this feature would offer. Wikipedia's success is due in part to it being a radical idea. Knowledge changes all the time and so does the content of Wikipedia. The tools we use must change too or we may find ourselves petting a dinosaur. This is not to say that a "share button" is strictly necessary, it is just to say that we must adapt to survive and as with genetic evolution, some changes (however crazy) may just be the very thing that lifts us. I realise that Wikipedia is already popular but it's present popularity is no good reason to curb it gaining more. -- fg^TC 18:18, 23 October 2011 (UTC)

• Support everyone else has a share button - you aren't required to use it. And browser plugins aren't an acceptable solution to the 99% of non-geek users. -- Eraserhead1 <talk> 09:31, 23 October 2011 (UTC)

The "Everyone else has it" argument is pretty weak... "Everyone else" has ads on their website. So because "everyone else does" we should too? I don't think so. VictorianMutant^(Talk) 11:42, 23 October 2011 (UTC)

The BBC doesn't have ads on their website. People only have ads on their websites if they are commercial websites that need to make money. Even Sourceforge, that well known commercial software website, has a like button. -- Eraserhead1 <talk> 11:48, 23 October 2011 (UTC)

• Weak oppose. I don't mind "sharing knowledge" in principle and I can see how this might attract beneficial editing, but what exactly needs to be shared/linked/plussed/digged/etc.? WP is already top search for most topics and I don't quite see how copying the URL is so hard? I also don't want to link my Wikipedia account to any social bookmarking websites I happen to be logged into unless Mediawiki does its own implementation. Additionally, I don't think an open source project should link to arbitrarily selected commercial websites. WMF has already previously rejected non-open source projects and I believe that's the way to go. —  HELLKNOWZ  ▎TALK 10:09, 23 October 2011 (UTC)
  • Copying the URL is hard because people aren't generally technologically savvy. You could make the same argument about the BBC etc. -- Eraserhead1 <talk> 10:25, 23 October 2011 (UTC)
    • If that is really such an advanced concept, then have a "copy link" button. —  HELLKNOWZ  ▎TALK 10:33, 23 October 2011 (UTC)
      • A copy link function doesn't add it straight to the social network of your choice. -- Eraserhead1 <talk> 11:48, 23 October 2011 (UTC)
        • Which is exactly why my argument was more than just "copy URL is enough". —  HELLKNOWZ  ▎TALK 12:04, 23 October 2011 (UTC)
  • Nobody is supporting linking WP and Facebook accounts, check out Wikipedia:Wikipedia Signpost to see how the buttons work. They do not send user info to any of the sharing sites, only the link to be shared. The only info Facebook can glean from that is that you did another thing on your Facebook account, no WP user data is compromised. ▫ JohnnyMrNinja 12:22, 23 October 2011 (UTC)
    • Quite. -- Eraserhead1 <talk> 12:33, 23 October 2011 (UTC)
    • Which is exactly why I added "unless Mediawiki does its own implementation". —  HELLKNOWZ  ▎TALK 15:46, 23 October 2011 (UTC)

TheDJ/Sharebox has been available for quite some time. It allows you to share an article with Facebook and over 50 other sites. The script uses the third-party AddThis and does not use cookies or flash that allows tracking. Privacy concerns are addressed on the doc page. ---— Gadget850 (Ed) ^talk 12:29, 23 October 2011 (UTC)

Right, and as an editor with 20000 edits I'd never heard of it before. It is completely unreasonable to expect our average reader to have heard of that. -- Eraserhead1 <talk> 12:33, 23 October 2011 (UTC)

• Oppose. Can't see why we really need this. Facebook and Wikipedia are two very different entities. As I understand it, it is already possible to share links to any website on Facebook anyway. Cloudbound (talk) 13:22, 23 October 2011 (UTC)
  • It isnt currently possible. And facebook and the economist are very different and they have a "like button". -- Eraserhead1 <talk> 14:50, 23 October 2011 (UTC)

Wrong, you just copy the URL into a status or wall post. Done. Ian.thomson (talk) 20:42, 23 October 2011 (UTC)

• Support Everyone needs to realize that this isn't a referendum on social media. A share button helps drive more traffic, which gives more pageviews, which nets more editors, which ensures the continued survival of the project.--GrapedApe (talk) 14:09, 23 October 2011 (UTC)P
• Strong Don't Care as long as privacy issues are addressed and it is easy to opt out of. Anomie⚔ 15:20, 23 October 2011 (UTC)
• Strong oppose This RfC asks if we need a "share" button. Intuitively we do not "need" this feature! It is not inherently a bad thing, and no one would be forced to press the button; but it would appear as an imitated feature and infer that Wikipedia desires in some way to emulate facebook. To my impression, Wikipedia is the foremost example of functionally productive networking with lasting social value, (in website terms) and we need to continuously develop our own unique niche. Our "like" button, or "share" button is here called an "edit" button; and more importantly, a "save" button. Pressing those are where we measure success, and by doing so, as I once did when creating the Chemical weapon article, starts the share option we are most committed to. One measure of success is the many sites which mirror our content, like this facebook example; which you are welcome to like and/or share, according to their manner.

I would favor a feature that was site specific, like a real time notification system if and when your watchlisted parameters are met. Currently, if someone edits my talkpage, I will not be alerted until my next refresh. There are times when periods pass, or I exit directly from a read, and miss a message until much later than perhaps necessary; or I refresh far more often than otherwise necessary, if I am anticipating some particular edit. Such an ability to share things internally would be a better direction, and use of resources. IMO -- My76Strat (talk) 18:02, 23 October 2011 (UTC)

I get email notifications already. -- Eraserhead1 <talk> 19:56, 23 October 2011 (UTC)

• Conditional support As a long-time Wikipedian and Facebook user, I don't see how sharing links to interesting articles with one's FB network will turn WP into a "social networking site." I think it's just one more great way to build traffic and awareness. Of course, I share the concerns of others that such a functionality not lead to online tracking issues. Shawn in Montreal (talk) 20:19, 23 October 2011 (UTC)

Looking over the discussion...

-The argument that we'd be selling reader info is properly countered by pointing out that it's circumventable on our end.

-The argument that we're not a social network ignores the fact that Facebook is.

-The argument that the site would turn into a social network because "kids" stinks of fuddy-duddy-ism.

But:

-It's easy enough to just copy a Wikipedia URL into a status or wall post on Facebook (or any other site). Noone capable of using either site needs a like button.

-There's been no explanation on how a share button would help us acquire good editors. "It couldn't hurt" is not a good reason, and anyone who knows what facebook is knows about Wikipedia already. The only people who would discover Wikipedia because of a like button would be the sort of techno-throwbacks who believe checking email requires IT training (*glares at grandfather*). The idea that people on Facebook don't know about Wikipedia is honestly damn stupid. What helps acquire new editors is letting (the right people) know that anyone can edit (within the guidelines), and a like button won't help with that. Only talking with your friends will help with that, and that allows us to let stupid friends continue to think we had to go through proper job applications, get circumcised, and join the Masons to "work" here.

-Several years ago, this discussion would have been about Myspace (anyone remember that?), so who knows what social network's feature we'll be discussing in the next decade? By saying that we'll give a feature to Facebook but not Myspace or anyone else's site is showing a preference to and support for Facebook, which is not neutral.

So: Oppose, on grounds that it is unnecessary for either site's users, and for WP:SOAPBOX (because it is helping Facebook). Ian.thomson (talk) 20:42, 23 October 2011 (UTC)

Nice argument. I'm not sure I entirely agree, but its a fair point. -- Eraserhead1 <talk> 20:48, 23 October 2011 (UTC)

• oppose I'm failing to see why we need to provide adverts for third party companies and use up valuable screen real estate to address the issue of what I suspect is a relatively small number of people who can't copy and paste a URL.©Geni 20:50, 23 October 2011 (UTC)
• whatever - probably a good thing, as in the day someone adds this feature I'll immediately stop wasting some of my time in here. - Nabla (talk) 22:52, 23 October 2011 (UTC)
• Support as long as privacy issues are avoided. Moving into the modern age to net more readers and editors is what Wikipedia should be doing. --Patar knight - ^chat/_{contributions} 23:04, 23 October 2011 (UTC)

• We're in the top 5 websites. We have readers. Anyone who knows enough about the net to have a Facebook account knows about this site and uses it. It won't help at all. In 10 years, we'll be out of date for having a Facebook like button, just as we'd be out of date for having a "share on Myspace" feature today. A "like" button won't let readers know that they can edit. Ian.thomson (talk) 01:07, 24 October 2011 (UTC)

• Generic traffic to Wikipedia is not the issue. The "Share" button (not like) will allow a reader to invite another specific person to read a specific article. This "prequalified" visitor is selected based on presumed interest, by a trusted friend. This new visitor to that article may have higher interest in it, and may therefore be more likely to edit that article to improve it. I consider the Share button as a publishing and topic editor recruitment tool. --Lexein (talk) 02:44, 24 October 2011 (UTC)
• Lexein summed it up nicely. This will help recruiting specialized knowledge as well as general editorship (including specialized editors who become more generalized). Also, not everyone who uses Facebook as well as Facebook is technologically competent to paste URLs, so this would be helpful. --Patar knight - ^chat/_{contributions} 19:02, 24 October 2011 (UTC)

• oppose we have no issues with lack of traffic or SEO. If someone wants to share something cut and paste works perfectly well. Ridernyc (talk) 00:32, 24 October 2011 (UTC)

• Generic traffic to Wikipedia is not the issue at all. See above. We cannot presume to know all the reasons people will "Share", but should not preemptively prohibit it. I consider the Share button as a topic editor recruitment tool. --Lexein (talk) 02:44, 24 October 2011 (UTC)

• Support. Join the 21st Century Express my friends. We're a publisher. We have a business model. That model includes includes seeking broad readership (as opposed to acquiring cachet through exclusivity, for instance). That we're both free and nonprofit is germane but peripheral: we need broad readership to thrive just as Time magazine does. Getting many more links into Facebook or whatever is an excellent way to advertise our wares. A way to make it easier to make this happen is good marketing. "He not busy being born / Is busy dying" -- Bob Dylan. Herostratus (talk) 01:19, 24 October 2011 (UTC)
  • We're in the top 5 most viewed sites on the net. We have readers. Can you honestly find anyone on your Facebook friends list who has never used Wikipedia? If you do, I'll find someone on your friends list who is a liar. There's no point in burning more fuel when you're well beyond the finish line and it's not going to catch up to you. Ian.thomson (talk) 02:29, 24 October 2011 (UTC)
    • Successful organizations don't rest on their laurels. Unsuccessful ones do. — Preceding unsigned comment added by Herostratus (talk • contribs)
• Wikipedia is not a for-profit business. Wikipedia's good qualities include being free of ads and other "dirty" Internet traits, let's keep it that way. I agree wholly with Ian.thomson.Jasper Deng (talk) 02:31, 24 October 2011 (UTC):
• Oppose – WP:NOT. What will be the result of making this site friendlier to the current immature, Facebook-y generation without the skill to format even bold text without a visual editor? New users completely devoted to talkspace edits, new trolls, new pages pretending to be articles, heavier backlog on AfC, FEED, and NPP, sharing an attack page with the victim ("hey foobar wiki sayz ur a c0cksuking wh0rfag :D"), paid spammers showing their employers their "articles" ("Advertisement deployed, O Capitalist. The share button has been used, with the advertisement now linked to 19,402,325 other computers."). What’s worse is that we don’t even have automated processes to help alleviate the resulting NPP super-backlog, like we have for regular vandalism edits. In any case, how hard is it to type http://enwp.org/PAGENAME? →Στc. 07:03, 24 October 2011 (UTC)

'Oppose The reason was given above, of driving traffic into our site. That's not our purpose:. Our purpose is providing an encyclopedia. The traffic comes to our site from people who want to use a free comprehensive web encyclopedia, and as long as we're the best available, we'll get the traffic. It's not as if we needed to build awareness of our existence. What we need to attract is prospective good editors, and if anyone can show that this might do so, there might be an argument. My own view is it would drive them away, just as advertisements would. What it will much more likely attract is spam and vandalism. DGG ( talk ) 07:18, 24 October 2011 (UTC)

• Oppose - Let's not risk diluting the message that encyclopedic knowledge is Wikipedia's core. Keep it free of sitewide links to a commercial enterprise. Keep it visibly, unambiguously neutral and independent: a project with a serious purpose. Don't blur boundaries with websites with different values. Also - for every straightforward "look at this article" Facebook share there might well be two look-at-this-joke-or-propaganda-edit shares.Lelijg (talk) 09:42, 24 October 2011 (UTC)
  • This despite the fact we prominently link to other commercial sites - in references, in ISBN's etc. Your last sentence seems speculative and without evidence to support the hypothesis it is uncompelling. --Errant ^(chat!) 09:55, 24 October 2011 (UTC)
    • Well, I like to think each article-based link to a commercial site is individually considered, in its particular context, to be relevant to a particular topic. A "social" link on every page seems quite different. And I'm sorry you find my speculation uncompelling! I was trying to express a genuine sense of how things could go wrong, based partly on my observations of countless unhelpful edits. In some situations you can't muster hard evidence and have to rely on experience, thinking things through etc. Lelijg (talk) 12:20, 24 October 2011 (UTC)
      • As far as I am aware we have no link consideration relating to sites being commercial or not - other than the obvious "no sales links". Most websites can be construed as commercial to some degree or another... and we link to them without concern (news articles, for example, which directly make money from our link via ad impressions!). As to the latter; the issue is that your taking something that happens already (i.e. vandalism) and implying (if I understand) that people will do more of it because they can easily share it with Facebook. I don't really follow that train of thought; either by logic or by instinct :) --Errant ^(chat!) 12:30, 24 October 2011 (UTC)

Support; this is primarily a reader tool, and making it easier to share and enjoy Wikipedia material is a great thing - it being our primary purpose. Opposition to that on the grounds: ** that we are not Facebook (great, an external share button does not make a social network... as you may notice social networks don't do such things)

• that copy/pasting a link is easy (yes, easy for you - standard computer literate egotism at work there), that we don't need to "advertise" (why not? we should always attempt to increase the sharing of information)
• that it will lead to an influx of not-very-good editors (how anyone connected up those dots I have no idea :P certainly they have no concept of causality and apparently a very disillusioned view of the people using social networks)
• concerns of encouraged vanity use (which is amusing listed after an argument that it is already easy to share without a link...)

Aren't particularly compelling. Privacy concerns are important, of course, but that can be accounted for by using pure links. Certainly links to the bookmarking sites would be really handy for me, Facebook less so, but Twitter I might end up using. As editors we do an astonishingly poor job of empathising with the average reader - and consider Wikipedia a tool for us, not a tool for them. The second this becomes about us we have lost a serious battle. Readers first! --Errant ^(chat!) 09:55, 24 October 2011 (UTC)

• Strong oppose - Is it really that hard to paste a Wikipedia URL? Furthermore I still don't see what Wikipedia would get in reward of providing that functionality. Anybody who knows how to use Facebook can paste the url to Facebook and publish it on their wall. Only because other websites include that functionality is not a reason for Wikipedia to do that too. Toshio Yamaguchi (talk) 10:36, 24 October 2011 (UTC)

No it isn't hard to paste an URL but why oppose an alternative? Does Wikipedia need a reward? Should it sit up and beg for treats? Some have argued that other sites use share buttons whilst pointing out how it has not detrimentally effected them. No one is suggesting that because other sites use share buttons, we should. What exactly is your strong opposition? -- fg^TC 11:32, 24 October 2011 (UTC)

Why, exactly, are you pushing it so hard. Is a button that saves you a half second of time really so important to you that you're willing to combat a great deal of a) legitimate privacy concerns, b) concerns about Wikipedia's direction, and c) dislike for social networking sites? You're fighting pretty damned hard for a half second of time. Your edit summary "So many strong opinions and nothing to hang them on." implies that you, in fact, have something to hang your opinion on (something so clearly and universally good that it allows you to snub the opinions of others, it appears). So, what is it? Sven Manguard Wha? 11:43, 24 October 2011 (UTC)

The problem in that paragraph is the word "you" :) Because this is not about us; the idea is that this would be a reader tool. Remember; the readers should always be our primary focus because the aim is to provide a repository of knowledge to as many people as possible. Once it becomes about "us" then we have lost sight of that (and this happens way too often). To try and respond to your points, though.. The privacy matter can be addressed - and if you are clicking a link to push to a third party site there is implicit intention to publish on that site. I struggle to follow concerns that this could link editors to their RL accounts - given that it requires a specific action, and even then a shared link contains no user data. I've never quite "got" the "we are not a social network argument" in this context - given that a share button is not by any means a feature of social networks (instead a social network tries to get people to share to it). I'm struggling to understand why a share button makes us into a social network rather than actually moving us away from the social stuff by pushing that sort of interaction to other sites. And, finally, dislike of social networking sites is a poor reason to oppose links to them! (i.e. IDONTLIKEIT). --Errant ^(chat!) 12:37, 24 October 2011 (UTC)

I almost certainly won't be using the button if we get it. I don't use the sites that most of the share options lead to. If I find a site on the list that I do use I would be surprised but pleased to share my discoveries by using a share button. So, I am not concerned by how many half seconds I can save. Also, I am not pushing any harder for the button than you are pushing against it. I don't consider my taking part here combat or a fight. Privacy concerns have been repeatedly calmed. Wikipedia's direction is hardly going to be detrimentally altered by a share button if all it does is "saves you a half second of time" (a flimsy weasel). My edit summary was the summary for one response to one other edit. That edit (as you can see above) made a few strong statements against having this feature. I failed to see the strength in the statements or any rationale for them being considered strong. We are all entitled to share our views here. That includes me (if you don't mind). -- fg^TC 12:39, 24 October 2011 (UTC)

You have a dozen posts, have made snide comments, and used equally snide edit summaries. You're not trying to particpate in a discussion, you're trying to force an issue. There's a difference, and I, at least, can see it. I'm not saying that you don't have the right to an opinion, but I am saying that you don't have the right to jam it down other people's throats. Sven Manguard Wha? 12:46, 24 October 2011 (UTC)

O.o -- fg^TC 12:48, 24 October 2011 (UTC)

I snapped at you and I apologize for it. Since it is clear that we have both apparently come to the conclusion that any further debate between the two of use would not be productive, I think it best if I take my leave from this discussion. Sven Manguard Wha? 14:09, 24 October 2011 (UTC)

The strength in my opposition is based on the fact that (and some of this might just be my personal opinion):

• I still don't see ANY STRONG argument for having this functionality
• we should not spend efforts on things that are not supported by such arguments

So you still have to show me what exactly the benefit of this functionality would be (apart from saving those who want to share articles that way the sec copy-pasting a url into a field at facebook). Toshio Yamaguchi (talk) 13:03, 24 October 2011 (UTC)

Share buttons would actively encourage readers to share Wikipedia content. Elsewhere on the net, users are used to seeing and using these buttons. Their popularity is evidence of their appeal/usage. Their familiarity could add a spontaneity to readers choice to share. This is something they may not have done without a quick-fire option to do so. Nothing Wikipedia is was supported by strong argument for it before it began. It was developed against a tide of ridicule (As I see it) and look how well that turned out! Sometimes good ideas don't need to have strong arguments in favour; they just need space to grow. -- fg^TC 13:19, 24 October 2011 (UTC)

"Elsewhere on the net, users are used to seeing and using these buttons."

That might be true, but is in my opinion still not a reason to implement this functionality. Furthermore again people can share Wikipedia content by pasting the url into the field at facebook. As far as I am aware, you have to be logged in to facebook anyway to share content like that, so you can also simply just paste the article url. And even if we provided share buttons, what exactly would Wikipedia gain through this functionality? Do you have any measures proving this would bring Wikipedia more active contributors or increase donations or something similar? What exactly would Wikipedia achieve through this? Toshio Yamaguchi (talk) 14:59, 24 October 2011 (UTC)

An increase in traffic and (over all else) the benefit is ease of use for readers and an encouraged sharing of knowledge. -- fg^TC 15:15, 24 October 2011 (UTC)

An increase in traffic! What more traffic do we need, seeing as Wikipedia currently has a site rank of 5? I still fail to see how difficult it is to type http://enwp.org/PAGENAME or copy/paste http://en.wikipedia.org/PAGENAME, and why we need to cater to the unskilled who still can't format bold text without a visual editor. →Στc. 00:47, 25 October 2011 (UTC)

I strongly disagree with the last sentiment there are many skilled professional people who are not very computer literate and the unfriendly interface is a big put off for them. Any idea why a site that is read by hundreds of millions is only edited by a few thousand people? S_peakF_ree ^(talk)_(contribs) 16:23, 26 October 2011 (UTC)

• Support - users already "share" our articles by copying and pasting URLs. Why not make this easier for them and allow sharing via all the usual means (Facebook, Redit, e-mail, etc)? They're doing it already but with more effort. Rklawton (talk) 11:45, 24 October 2011 (UTC)
• Support. Adding a share button doesn't magically turn Wikipedia into a social networking site. Times are changing, there is no need to stay in the dark ages of the internet. Ajraddatz (Talk) 14:12, 24 October 2011 (UTC)
• Oppose, why make it easier to WP:CANVASS? --SarekOfVulcan (talk) 14:23, 24 October 2011 (UTC)
• Suggestion Re: WP:CANVASS. I've searched the discussion and found no specific indication that this feature should or would be added to talk pages. If only added to article pages I (personally) doubt that a rise in canvassing would occur. Those who wish to rally support for their cause could and can do it with or without this feature. An increase in traffic (by any means) would bring an increase in ALL forms of traffic. We already deal with taking the rough with the smooth. Lets assume good faith. -- fg^TC 15:15, 24 October 2011 (UTC)
• Support Sharing knowledge is the whole point of Wikipedia, and it should be as easy as possible for readers to share what they have found in Wikipedia with their friends. The NYT isn't a social network just because it has this button (and I've never understood the anti-social-network hysteria here anyways). It is a Good Thing if people who love Wikipedia share Wikipedia with their friends, and we need to get out of the stone age in terms of technology and usability. Why make people copy-paste URLs if a button would do the same thing, but in a more accessible way? I know my grandma uses Facebook and reads Wikipedia, but I doubt she could paste a URL between the two. Calliopejen1 (talk) 17:51, 24 October 2011 (UTC)
• Support per Calliopejen1. Would make the site more usable for our readers. AGK [•] 21:56, 24 October 2011 (UTC)
• Oppose I believe it is not in line with Wikipedia's purposes. An article can already be shared with the simple copy-paste of a link, why waste time and resources implementing such a trivial feature? Zidanie5 (talk) 23:02, 24 October 2011 (UTC)
  • My understanding is that the Wikipedia software already supports this feature, and that all we have to do is just turn it out. A Quest For Knowledge (talk) 00:10, 25 October 2011 (UTC)
• Oppose Per Sven Manguard, DGG, and others. We are not a social networking site; we do not need to use social networking to drive traffic into our website; these share buttons are creepy. Users can already share Wikipedia articles on Facebook by pasting the URL into their current status. Solve this non-problem with Greasemonkey if you have to. causa sui (talk) 23:54, 24 October 2011 (UTC)
• Oppose Wikipedia content on any topic of interest is easily found using search engines. There's no reason to push specific articles onto Facebook. Being "liked" is not a useful measurement of article quality, and we already know that popularity does not equal importance. I don't see any net benefit to the project.   Will Beback  talk  00:21, 25 October 2011 (UTC)
• If it will truly benefit the readers without damaging the content, let's do it, but I have my doubts. My main concerns regard privacy and entanglement. If we do this, I'd much rather we do it in a way that completely avoids any means by which third parties can track our readers in any fashion; I'm confident that we can avoid that, but I'd strongly prefer a solution on our end that's within our control. Beyond that, we've historically made a point of avoiding advertising and other propositions that might benefit funding and readership in the short term, for fear that they will damage our long-term goals of providing a neutral, comprehensive, quality encyclopedia. Will adding this feature compromise that in any way? Just as important, will it look like we've compromised it? Is this something our readers actually want? How will it affect their opinion of the site? – Luna Santin (talk) 01:05, 25 October 2011 (UTC)

Revoking unconditional support. Conditional support only Re: Neutrality concerns expressed in sub-section below. The condition is that if the feature were supported NO buttons would be supplied or specified by default but that Wikipedia simply adds support for a list of user-added buttons to be created. Wikipedia would then not be supporting or stifling any third-party social-network. I would like to see the feature but only if it does not compromise Wikipedia's neutrality. -- fg^TC 02:02, 25 October 2011 (UTC)

I think this is a good idea; it allows readers and editors to tailor their WP experience to their own desires about whether to have a share button and if so where they'd like to share to. If the process of actually creating the button was complicated for some reason, you'd think that a reasonably perceptive business would have a staff member spend an afternoon writing some free wikipedia-compatible code for its users. AgnosticAphid talk 18:01, 25 October 2011 (UTC)

• Oppose. DQ and Sarek have raised a very important concern. An automated way of telling people off-site to "look at this" will easily become an automated way of canvassing on an unprecedented scale. Just imagine an influx of fans, unconcerned about our policies, into RfCs and AfDs. Yes, I know that people can do this already. But this proposal would automate the process in a new way, and the opening it creates will be filled. Wikipedia already comes up near the top of search engine results for a given topic. Any increased readership will be offset by disruption by people who come here not because they are interested in reading an article, but because someone told them to follow a link. --Tryptofish (talk) 17:23, 25 October 2011 (UTC)

Share with which services?

Parallel question, and one that doesn't seem to be getting much attention here: supposing that we do add a "share" button, who is it going to share with? Which social media services would be included or excluded from this feature? On what basis? – Luna Santin (talk) 00:34, 25 October 2011 (UTC)

I sort of mentioned that earlier. Several years ago, we'd be sharing on Myspace, and if you asked my friends earlier this year where we'd be sharing ten years from now, most of them would say Google+. There's tons of Social networking websites, many rise and fall all the time, and while Facebook is currently popular, it's still just the "in-thing" and not something universal or unending (which this site is gonna do it's damndest to do). Choosing that one site over the others is playing favorites and is not neutral, and it kinda smacks of buzzword-ism, "Hey, Facebook is popular right now, so we gotta use it too because future." Facebook is only one facet of social networking, and we cannot determine whether it will succeed or fail, but we will be giving it non-neutral support if we provide it a feature that we do not provide other sites. Ian.thomson (talk) 00:45, 25 October 2011 (UTC)

Interesting argument (seems a valid concern). Ian, are you suggesting that either all or none should be supported? Or do you oppose any support? Genuine interest here. I'm not pulling your chain. -- fg^TC 00:54, 25 October 2011 (UTC)

@Ian, agreed, adding a social networking feature could have the same effect on Wikipedia as if we were to put banner ads on the site. (Arguably, the share "feature" would be an ad.) Adding a "share" button would be a breach of our neutral point of view policy. That should also be taken into account before such a "feature" is added. Alpha_Quadrant ^(talk) 00:58, 25 October 2011 (UTC)

Why not just use the same ones Wikipedia Signpost does?[13] We already have a precedent for this. Let's just follow Signpost's example. A Quest For Knowledge (talk) 00:54, 25 October 2011 (UTC)

It would be impossible to support all of them, and it'd be too much of a hassle to go with only the notable ones. As for the Signpost suggestion, I'd agree except "The Signpost is an independent publication which is not affiliated with the Wikimedia Foundation." I'm not sure that really sets a precedent any more than a user essay. Ian.thomson (talk) 01:02, 25 October 2011 (UTC)

Withdrawing unconditional support re neutrality concerns. -- fg^TC 01:52, 25 October 2011 (UTC)

Maybe the signpost isn't affiliated with the Foundation. But that doesn't mean that it's not a useful starting point for which social networking sites we could include. I agree that including support for all, or even all notable, social networking websites would be a futile and vexatious exercise. But there's got to be some way to include enough different websites to be universally useful while not trying to have support for 500 websites. Could we take a poll every 6 months to see what users' favorite networks are? Or maybe we could base inclusion on the network's number of users (if this can be readily determined)? Just throwing some ideas out there, I know there are some issues with these suggestions. AgnosticAphid talk 17:54, 25 October 2011 (UTC)

I don't really know enough about coding to make some of these statements. TheDJ makes it sound like it'd be easy enough to make something with support for 500 websites. So maybe this isn't an issue. AgnosticAphid talk 19:43, 25 October 2011 (UTC)

• Doesn't using Facebook/Google+/whatever logos also breach the policy on non-free content? MER-C 04:09, 25 October 2011 (UTC)

I think they would be applicably licensed for use. -- fg^TC 04:20, 25 October 2011 (UTC)

Well, if we followed the Signpost example, there wouldn't need to be a logo. I don't think that merely having the plain text "Facebook" or whatever would raise advertising concerns. But I'm no expert. AgnosticAphid talk 17:47, 25 October 2011 (UTC)

Actually, I was wrong, the Signpost does indeed have logos. But if this is a sticking point they hardly seem necessary. AgnosticAphid talk 17:49, 25 October 2011 (UTC)

I'm quite sure that is rather new... They used to be text only. —TheDJ (talk • contribs) 19:17, 25 October 2011 (UTC)

• • How, specifically? --Cybercobra (talk) 08:33, 25 October 2011 (UTC)

It is not possible to explicitly license a logo for use on Wikipedia. Content used on Wikipedia must have been released under a free license which grants anyone the permission to use it for any purpose (including commercial use; see Resolution:Licensing policy). Toshio Yamaguchi (talk) 09:44, 25 October 2011 (UTC)

Those policies are all related to content. this would be site-specific UI, not content, which has never been a question before. Specifically, these icons would not appear in database dumps, so all existing policies and arguments for/against are irrelevant. ▫ JohnnyMrNinja 14:15, 25 October 2011 (UTC)

I see wholly no reason why we can't support all 300+ services that exist in the world. Just requires a bit of smart programming. If addthis can build it, then we can build it too. The most popular 4 would be easy accessible, the rest reachable via an 'other' option + ajax search dialog. If you use one of the 'other' options, you get a cookie, that ups the priority of that server next time you visit. Easy peasy. Seems fair enough to me, no neutrality issues there. We could even make it a seperate service for other OSS/Free/NGO projects. —TheDJ (talk • contribs) 19:17, 25 October 2011 (UTC)

Daughter pages

I would like to have a "supplementary information" page to another page, but I am not sure on what the guideline is. Can I do the "main_page/extra_page" trick like on user-pages or do I have to make a self-standing page? Basically, I have a page with large cladograms ("family trees" but for species) that I would like to hide unless the user wants to see them (table collapsable collapsed messes up the formatting). Thanks --Squidonius (talk) 05:03, 22 October 2011 (UTC)

• Oppose technical implementaion for now. I definitely support using it for taxonomic purposes, but it would cause too much confusion. However, I weakly support using it non-technically (like Software/feature without an actual link back to Software from Software/feature) provided that they are supplemented with appropriate redirects, as it can definitely be useful for organizational purposes. There are still, however, many other things like page moves that need to be resolved.Jasper Deng (talk) 05:09, 22 October 2011 (UTC)

It seems you (Squidonius) are not so much proposing this as asking for guidance. This isn't really the right place to ask I think (but I don't know (other than the article talk page) where the right place would be; Maybe a helpdesk?). However a possibility to solve your issue would be to contain the cladograms (must look that word up later) in scrolling divs. That way each could take up just a few lines but be fully viewable without leaving the page. Further to this each could (since they don't spread far horizontally) could reside next to others thus shortening the page as a whole. -- fg^TC 06:21, 22 October 2011 (UTC)

I put an example here -- fg^TC 06:33, 22 October 2011 (UTC)

Thanks for checking! That is a good idea, however, the problem is not only of space but also that there is a limit on number of templates per page and Bacterial phyla has gone over that. So given than the name/sub-name option may cause technical problems, I suppose that making a normal article for each tree is the only option... --Squidonius (talk) 07:25, 22 October 2011 (UTC)

Ah I see. Good luck. -- fg^TC 18:42, 22 October 2011 (UTC)

Subpages are disabled in mainspace, so if you create Foo/Data page you will get a separate article with that title. Note that wp:Chemistry has been using supplementary information pages for years :Methanol (data page), Arsine (data page), Tryptophan (data page). Yoenit (talk) 08:04, 22 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 Δ. 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| 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. --MASEM (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. --MASEM (t) 23:20, 26 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| 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. --MASEM (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. --MASEM (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)

Δ 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^TC 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. — 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. --MASEM (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^TC 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 #Δ proposed task #18. – 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)

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.[14][15] 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 .<ref>[http://www.uuchurch.org/history/middle-years]“The Middle Years,” (March 2011).</ref> . to <ref>[http://www.uuchurch.org/history/middle-years The Middle Years | University Unitarian Church]“The Middle Years,” (March 2011).</ref> ).

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)

Δ proposed task #1

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [16]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may undertake edits to articles to remove links to images which have been deleted (example, first line of diff)

On behalf of Δ, --Hammersoft (talk) 17:28, 24 October 2011 (UTC)

• 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| 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 [17]) perform this task, rather than another bot operator who is less likely to draw criticism? — 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? — 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. — 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 Wikipedia: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: Wikipedia:RFAR#Request for clarification: Δ. Uʔ (talk) 18:08, 26 October 2011 (UTC)

Δ proposed task #2

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [18]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ 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 (example, first line of diff)

On behalf of Δ, --Hammersoft (talk) 17:28, 24 October 2011 (UTC)

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. — 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. — 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. — 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)
• Oppose as it stands. Could support if only those replacements as agreed upon for AWB (see Wikipedia: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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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)

Δ proposed task #3

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [19]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may undertake edits to remove external links where such links were used as a failed attempt to include an image in an infobox (example, first line of diff)

On behalf of Δ, --Hammersoft (talk) 17:28, 24 October 2011 (UTC)

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)
• 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). --_{Piotr Konieczny aka Prokonsul Piotrus| 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

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [20]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may undertake edits to move content existing below category tags on an article to a position above the category tags in accordance with Wikipedia:CAT#Categorizing_pages. (example, bottom portion of diff)

On behalf of Δ, --Hammersoft (talk) 17:29, 24 October 2011 (UTC)

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 Wikipedia:CAT#Categorizing_pages 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. — 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 Wikipedia:CAT#Categorizing_pages. 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. — 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? — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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)

• 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 <talk> 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)

Δ proposed task #5

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [21]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may undertake edits to apply appropriate reflist template parameters when stylization to fix layout is appropriate. (example: before and after)

On behalf of Δ, --Hammersoft (talk) 17:29, 24 October 2011 (UTC)

See WP:CITEVAR. It wouldn't be good for someone to change large numbers of articles automatically in this way. — 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. — 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. — 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). — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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? — 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)

Δ proposed task #6

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [22]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may undertake edits to remove white spaces as appropriate in accordance with Help:Whitespace. (example, first part of diff affecting infobox)

On behalf of Δ, --Hammersoft (talk) 20:50, 24 October 2011 (UTC)

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. — 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 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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? — 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

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [23]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may add {{dead link}} as appropriate to references where the link is dead. (example, second section of the diff (first green part))

On behalf of Δ, --Hammersoft (talk) 20:53, 24 October 2011 (UTC)

This should be done by a bot, there is no reason for him to do it manually. — 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. — 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. — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 18:04, 25 October 2011 (UTC)
• Support as long as the articles are offline for a reasonable period of time. -- Eraserhead1 <talk> 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) --MASEM (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)

Δ proposed task #8

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [24]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may replace <br style="clear:both;" /> with {{-}}. (example, fourteenth '+' sign in diff)

On behalf of Δ, --Hammersoft (talk) 21:02, 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:10, 24 October 2011 (UTC)

• Oppose - can at best make the HTML look extremely odd, or at worst possibly break HTML, where the <br> 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 <talk> 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)

Δ proposed task #9

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [25]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may replace "Image:" with "File:". (example, multiple examples in the diff)

On behalf of Δ, --Hammersoft (talk) 21:06, 24 October 2011 (UTC)

There is no reason to do this, they are completely equivalent. — 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. --MASEM (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. --MASEM (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 | 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... --_{Piotr Konieczny aka Prokonsul Piotrus| 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. --MASEM (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: - [26], so there's no particular reason it will ever need to be removed completely. Franamax (talk) 17:11, 26 October 2011 (UTC)

Δ proposed task #10

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [27]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may prod articles. (example)

On behalf of Δ, --Hammersoft (talk) 21:10, 24 October 2011 (UTC)

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. — 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. — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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. — 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. — 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 <talk> 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. — 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. — 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 Wikipedia: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. — 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. --MASEM (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. --MASEM (t) 17:39, 26 October 2011 (UTC)

Δ proposed task #11

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [28]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may change articles into redirects as appropriate. (example)

On behalf of Δ, --Hammersoft (talk) 21:16, 24 October 2011 (UTC)

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. — 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. — 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. --MASEM (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. --MASEM (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. — 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

• 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.

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)

• 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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 <talk> 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)

Δ proposed task #12

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [29]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may fix duplicate references. (example, under "3rd Verkhovna...")

On behalf of Δ, --Hammersoft (talk) 14:06, 25 October 2011 (UTC)

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. — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 18:10, 25 October 2011 (UTC)
• Support definitely useful. -- Eraserhead1 <talk> 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. <ref>1</ref> and <ref>1</ref> Δ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)

Δ proposed task #13

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [30]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may add titles to bare URLs and convert inline links to refs where needed. (example)

On behalf of Δ, --Hammersoft (talk) 14:11, 25 October 2011 (UTC)

• 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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 <talk> 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"[31]. 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)

Δ proposed task #14

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [32]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may add non-breaking spaces to units, in accordance with WP:NBSP . (example)

On behalf of Δ, --Hammersoft (talk) 14:17, 25 October 2011 (UTC)

• 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 <talk> 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

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [33]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may archive links (wayback, webcitation). (example) Per Δ, better example

On behalf of Δ, --Hammersoft (talk) 14:20, 25 October 2011 (UTC)

• 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). — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| 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. [34]. 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 accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [35]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may adjust the location of "  | " in templates to the beginning of the line, rather than the end, per convention established at Help:Infobox and Help:Designing infoboxes . (example)

On behalf of Δ, --Hammersoft (talk) 14:28, 25 October 2011 (UTC)

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). — 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 <talk> 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)

Δ proposed task #17

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [36]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may fix order of references so that the refs are sequential^[1][5][3] becomes^[1][3][5]. (example)

On behalf of Δ, --Hammersoft (talk) 14:31, 25 October 2011 (UTC)

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. — 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. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 18:15, 25 October 2011 (UTC) (talk) 16:04, 25 October 2011 (UTC)
• Support definitely positively useful. -- Eraserhead1 <talk> 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)

Δ proposed task #18

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [37]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may date maintenance templates. (for example {{POV|date=September 2011}})

On behalf of Δ, --Hammersoft (talk) 15:07, 25 October 2011 (UTC)

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. — 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? --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 18:15, 25 October 2011 (UTC)
• Support why not? -- Eraserhead1 <talk> 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. — 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)

Δ proposed task #19

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [38]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may fix the location of mal-placed templates (deadlink outside of ref, when it should be within etc.).

On behalf of Δ, --Hammersoft (talk) 15:09, 25 October 2011 (UTC)

• 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. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 18:16, 25 October 2011 (UTC)
• Support seems perfectly reasonable and non-controversial. -- Eraserhead1 <talk> 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

In accordance with

• The first bullet item of Δ's editing restrictions,
• Agreement by Δ for me to operate on his behalf in making requests in accordance with said restriction [39]
• and in compliance with other editing restrictions which may apply to this request

the following request for editing is being made:

Δ may combine templates as needed into {{multiple issues}}.

On behalf of Δ, --Hammersoft (talk) 15:12, 25 October 2011 (UTC)

• 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. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 18:16, 25 October 2011 (UTC)
• Support definitely useful. -- Eraserhead1 <talk> 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)

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

Δ is required to use descriptive edit summaries in undertaking WP:VPP-approved tasks to assist in community oversight and review. Δ is prohibited from using blanket edit summaries to describe edits which vary in task, nature or automation. A run of edits that use an identical blanket edit summary that occur within the same 24 hours are deemed to constitute a "pattern" in the context of his community editing restrictions. When executing a run of automatic or semi-automatic edits, Δ must provide reasonable indication of the editing operation(s) applied in his edit summaries. --Tristessa (talk) 22:30, 25 October 2011 (UTC)

• 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 <talk> 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 <talk> 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. — Carl (CBM · talk) 23:10, 25 October 2011 (UTC)

• Strong support --Guerillero | 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. --MASEM (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)

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. --MASEM (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. --MASEM (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). --MASEM (t) 02:10, 27 October 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. — Carl (CBM · talk) 20:06, 24 October 2011 (UTC)

• Shouldn't be at AN? Well, anyways, I support, but for 25 articles. ~~Ebe123~~ (+) ^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: [40] [41]. 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. — 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#Julian and Gregorian calendars 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)

  <moved next below>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)

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. — 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. — 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 Wikipedia:Administrators' noticeboard/Incidents/I have blocked Betacommand. — 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

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. — 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. --MASEM (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. (Template:DirkB 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. — 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)

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: Shared IP talk page archiving

As some of you already know, Steven Walling and I are currently running some A/B tests of common user warning templates. In the course of analyzing data from the first two tests, we've realized that shared IPs pose an extra challenge, because their talk pages are filled with dozens of warnings that are months or years old. That makes it all but impossible to tell whether or not our new messages are having any effect on those users.

Not only is this getting in the way of our current analysis, but it's probably hurting new editors inadvertently, too. Our hypothesis is that shared IP talk pages, which are cluttered with tons of old warnings, are probably discouraging good contributors (who click on the "You have new messages" banner and see a wall of warnings not meant for them) and encouraging bad-faith ones (who do the same and think it's okay to vandalize Wikipedia because everyone else seems to be doing it). This is just a theory, but it's one we can actually test empirically – in brief, we were thinking of dividing the list of shared IPs in half and setting up a vigorous archival system for the test group (possibly using MiszaBot III or a similar user talk archiving bot), so that their talk pages will only display the most current messages.

Does this sound like a good idea? If so, it would be great if we could get the assistance of a bot operator to help us set up archiving for some 1000+ shared IP talk pages, since that kind of thing would be not so fun to do by hand :) Let me know if you're interested!

And if you're interested in our template tests in general, you should feel free to sign up for our task force, which we're running with the gracious help of WikiProject User warnings. If you have ideas about other tests to run, we may just have the time and resources to try them out... Thanks, Maryana (WMF) (talk) 21:48, 25 October 2011 (UTC)

I always collapse the old warnings with {{Old IP top}} and {{Old IP bottom}}, but I agree. -- Eraserhead1 <talk> 21:52, 25 October 2011 (UTC)

Is it possible to mass nuke all old IP talk pages? If the page hasn't been edited in a long period of time the messages are irrelevant. Alpha_Quadrant ^(talk) 21:58, 25 October 2011 (UTC)

If we get somebody with a database dump to run some clever queries, we could easily produce a list of pages. Or I suppose we could start from transclusion lists for {{sharedip}} and the like. Dunno how practical is is, but it's certainly possible. – Luna Santin (talk) 00:42, 26 October 2011 (UTC)

I can do one better than that, I have access to the toolserver. just let me know what you need. ΔT _{^{The only constant}} 00:44, 26 October 2011 (UTC)

Personally, I'd just as soon delete the warnings -- how often is anyone ever going to take an interest in a wall of old warnings? I don't see any utility in keeping them around, but I could be missing something. What sort of schedule are we looking at? Bimonthly, maybe? I worry a little bit about triggering extra "new messages" banners. – Luna Santin (talk) 22:59, 25 October 2011 (UTC)

How we can set it. We can't nuke all IP pages at once. Mohamed Aden Ighe (talk) 23:22, 25 October 2011 (UTC)

I don't think we should nuke everything and start fresh just yet (though maybe after we see the numbers from a month-long test, we might want to have a discussion about the idea). A/B testing appeals to me because it will actually show us the effect, in quantitative terms, of walls of warnings. And that's good to know in general. It's not exactly a secret that the amount of warnings on user talk in English Wikipedia has skyrocketed over the past few years; what is still a bit of a mystery is what kind of an impact that's having on the community overall. If we see a huge difference between the two test groups, that will start to give us some clues.

As for how often to archive, I'm thinking even more vigorous than that: how about archiving every hour that there are no edits to the talk page? Is that too crazy? Remember, we're talking about shared IPs here, some of which change hands as often as every few minutes. Maryana (WMF) (talk) 23:47, 25 October 2011 (UTC)

1 hour is far too quick. I would say 30 days. While a shared IP could be used by several users concurrently, vandals on that address have a habit of returning. When I see an IP vandalize a certain article, or articles within a topic, then come back a few hours or days later, it is pretty obvious that it is the same person. Super-fast archiving would make it harder for us to monitor such behaviour. The overall idea is sound, however. Resolute 23:58, 25 October 2011 (UTC)

Agreed. It's entirely possible that shared IPs frequently represent multiple simultaneous readers, but in my own experience they very rarely represent multiple simultaneous editors -- in terms of editing, I'd say that changing hands even once or twice a day is fairly rare. That's not to say we can't consider IPs which do have multiple simultaneous editors, but there aren't very many of those. – Luna Santin (talk) 00:01, 26 October 2011 (UTC)

Ah, good point! Will have to think through this a bit more... my instinct is that a month is too long, though. Perhaps a week? I mean, after that long, does the warning even have any real reprimanding power anymore? ("You did something bad... a week ago! Stop this instant!") Maryana (WMF) (talk) 00:17, 26 October 2011 (UTC)

Also, as to the time between multiple editors, you're probably right that minutes is an exaggeration, but I've definitely seen my fair share of several hours' worth of difference. Just came across one in coding: compare this and this diff, both made on the same day by the same IP. Not the norm, but not uncommon, either. Maryana (WMF) (talk) 00:28, 26 October 2011 (UTC)

Touche. If you plan on using MiszaBot (or anything like it), I believe the wait time can be configured case-by-case. If this is adopted as a long-term strategy, we might look into some guidelines on setting varied archival rates, based on a quick glance at each IP's contribs in recent months; if it makes the research easier, though, defaulting to a week should be fine. – Luna Santin (talk) 00:40, 26 October 2011 (UTC)

You are possible forgetting one thing: If/When the warnings are to be removed, the "you got mail" banner should be removed as well. I don't know if this can be possible in the current version of MediaWiki, or if an feature request needs to be pushed onto the poor developers. _→AzaToth 00:50, 26 October 2011 (UTC)

I agree that IP talk pages covered in warnings are a bad thing and am impressed by this attempt at a solution. I am of the opinion that IP edits should be peer reviewed and realise this is hugely contentious but worth a mention.

Could ALL IP talk pages be patrolled by a bot with a specific task to rather than archive old warnings simply delete them? Warnings that have either worked or for some other reason not escalated past #2 could be blitzed after only a day (I think). Whereas warnings above #2 could be left in place for a week. I sincerely doubt that warnings more than two weeks old are going to deter anyone; whether the IP user they were meant for or a new vandal (assuming the warning was appropriate in the first place).

Perhaps the most prevalent issue here is the impression given to a new user allocated an IP with past warnings who's intentions are entirely honourable. As mentioned above they could be put off or even insulted into misbehaviour (some folk are sensitive). In this case, having a large friendly intro on EVERY IP talk page, that is never removed explaining that "being an IP...if warnings...not meant for you...blah blah blah" that really hits the message home would be enough to calm potentially bad reactions to all the old warnings (not suggesting that removal shouldn't happen but that this should accompany it). I know these messages are already used but they are far less obvious than some WARNINGS!!.

So in summary:

1. Good on you for thinking of how to improve the experience of casual users.
2. A bot used to clear rather than archive would be awesome if:
   1. It cleared different levels of warning at different intervals; leaving more severe warnings in place longer.
   2. It left in place a large friendly page top intro template saying "Hiya! " that is far more jazz-hands than any warnings below it.
3. That along with these actions there could be a reconsideration that IP edits could be peer reviewed before deploying or not. -- fg^TC 01:00, 26 October 2011 (UTC)

My threshold (personally) is 12 months. I've dealt with some unique IP addresses that love applying a very specific set of changes that they don't get the picture and aren't willing to conform to an already established consensus that has been brought to their attention multiple times. In the case of these IP addresses, they only show up for editing a TV series and vanish into the woodwork once the series is complete. Hasteur (talk) 21:50, 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)

Banning non-language character usernames

Hi there. This might have been discussed before, however I'd like to make the proposal and see if it floats. I believe names using characters that are not used in an everyday language, such as ʔ (recently adopted by User:ʔ), are... well... bad.

It's one thing if you had a name like User:兔子, those are actual characters in a written language, and I am in no way saying that we should do away characters from other languages, however it's an entirely different thing if you choose a name that exists in no language and appears on no keyboard. Windings, phonetic symbols, and the like are difficult to find, identify, or even name, and that presents a large number of communication difficulties. There is little to no redeeming factor that would outweigh the difficulty that these cause.

My proposal is that effective as of this gaining consensus, new accounts using such characters are to be prohibited (users would be asked to pick a new name, and blocked if they don't comply, as is done with other abusive names), but old accounts will be grandfathered in, but strongly encouraged to modify their usernames.

Thoughts? Sven Manguard Wha? 08:01, 26 October 2011 (UTC)

ʔ is an IPA symbol, so it can be surely used to express human sounds, and in this way is more universal than most other scripts, but surely it is a rather technical one. So it's not a "non-language character" as I read that. I'm not the first to use IPA symbols in a user name, by they way. If the proposal is to ban IPA symbols, there should be a widespread RfC, and all users who use these should be notified. And IPA itself is commonly used in Wikipedia, so I doubt there are any printing issues. My signature also contains a Latin character as suggested by WP:SIG#NL. Regards, Uʔ (talk) 08:09, 26 October 2011 (UTC)

When we try to convince IP editors to register and get a name, one of the reasons we give is to simplify communication. A name that cannot be easily typed in the way the user displays it does not simplify communication. HiLo48 (talk) 08:17, 26 October 2011 (UTC)

I cannot easily type Chinese, Arabic, and a few other languages as well. How fast can you type, say, Σ, א, خ, or 子? Uʔ (talk) 08:25, 26 October 2011 (UTC)

Yes, but other users come from other projects that either use those languages as primaries or are multilingual. That's why we don't ban all non-English characters. Sven Manguard Wha? 08:57, 26 October 2011 (UTC)

Are User:Σ and User:Δ, just to pick two obvious examples, or even User:Ü mainly editing on other projects? Uʔ (talk) 10:06, 26 October 2011 (UTC)

I don't immediately see how non-Latin usernames complicate communication. How often is it actually necessary to physically type an editor's username? If I want to write Uʔ's name in a discussion, I copypaste. If I want to visit his userpages, I click the links in his signature. If I want to view his contributions, I look at his last edit and use the link there. The fact that I can't type "ʔ" on my keyboard (and I really can't; I have no idea what combination of keystrokes I'd need) doesn't actually inconvenience me or prevent me from communicating with him. Since the username policy specifically states that non-Latin usernames are welcome, I tend to assume that the current consensus does not see them as disruptive. Yunshui 雲水 08:48, 26 October 2011 (UTC)

That assumes that he's already in the conversation. Sven Manguard Wha? 08:57, 26 October 2011 (UTC)

I should note that ʔ appears in the "IPA (English)" section of Wikipedia symbol insertion toolbar. If this information shocks someone into realizing their English can be written in IPA as well, then I may have contributed to their sum of knowledge a bit, I hope. There's no easy way to insert Chinese using Wikipedia's toolbar however. Uʔ (talk) 09:05, 26 October 2011 (UTC)

wɛl ðæts kwajt jusfəl. θæŋk ju. Yunshui 雲水 09:10, 26 October 2011 (UTC)

Two issues:

1. Most Asian characters for me are boxes so the topmost example of an acceptable user name is unreadable for me whereas the Glottal stop shows up just fine.
2. The bulk of our interactions on Wikipedia are such that we need rarely reference another user by name. As long as the wikilinking works it doesn't bother me if the letters don't even render. If I need to talk to Mr or Ms boxboxbox, I would (in most situations) just click their link and post to their page.

It is the limitation of my own PC that stops it from rendering some unusual characters. The fact that Mr boxboxbox and Ms boxboxbox are hard to distinguish is occasionally frustrating but as I already said, I see User Glottle stop and User Triangle just fine and the family boxboxbox are using accepted characters.

Since there is no way to be sure what viewers will be able to render what characters (outside a very limited selection), if this proposal carried any weight at all, we would have to ban the use of all unusual characters from the whole of Wikipedia. As long as people do good work and/or enjoy reading and can be contacted if needed, I really don't see a problem worth upsetting anyone over. Apart from anything, having a triangle for a name is really rather cool -- fg^TC 09:37, 26 October 2011 (UTC)

Yunshui - your posts have simply reinforced my point. You can type my user name directly with the keyboard.. The obvious abbreviation makes it even easier. While it is possible to copy and paste more complicated names, and do all sorts of other tricky things, why make it harder than it needs to be? (A work colleague told me recently that she needs someone to teach her about "this cut and paste thing", so don't assume skills.) HiLo48 (talk) 09:41, 26 October 2011 (UTC)

I think it should continue to be up to users' own discretion. No-one's obliged to use a user name anyway, so if you use one that makes it a bit harder to communicate with you, that's a downside that you're presumably prepared to accept. Allowing people to express their identity in ways that appeal to them (as long as they aren't offensive) is one of the things that keep community spirits up.--Kotniski (talk) 09:50, 26 October 2011 (UTC)

That's an odd response. Obviously the user with the weird name is comfortable with it, and "prepared to accept" it. It's other editors that things are being made harder for. HiLo48 (talk) 10:04, 26 October 2011 (UTC)

Yes... so since the user was under no obligation to provide a user name at all, we can't really complain if he/she provides one that isn't quite as convenient for us as it might have been.--Kotniski (talk) 10:08, 26 October 2011 (UTC)

So, having just brushed aside my point about who has to accept it, you now completely ignore the point I made earlier that one of the reasons we give when suggesting that editors register is to make it EASIER to communicate. HiLo48 (talk) 10:13, 26 October 2011 (UTC)

Yeah, let's ban all unusual characters and give all of us numbers... you can henceforth address me as User:78753965245671 09:49, 26 October 2011

And that response is just silly. (Or was it meant to be?) HiLo48 (talk) 10:04, 26 October 2011 (UTC)

(e/c)Good grief. Let's kill this proposal off and then dump it in WP:PEREN where it belongs (I'm sure we've had it a time or two before, but can't remember where off hand). Since we have global accounts, it makes no sense to ban characters which are part of a language (at least for those languages with WMF projects). Taking that as a given, there is no reason to ban non-language characters: They are no more (and often less) cryptic, hard to render/type, etc. than the foreign-language characters. --Philosopher ^{Let us reason together.} 10:11, 26 October 2011 (UTC)

That's a bad faith post. After several editors have given reasons above, you say "there is no reason". Quite insulting really. Disagree with them perhaps, but don't claim they don't exist. HiLo48 (talk) 10:16, 26 October 2011 (UTC)

Fine, there's no good reason, as demonstrated by the rest of my post. Jayron32 restates my point, below, in much more eloquent language. --Philosopher ^{Let us reason together.} 02:42, 27 October 2011 (UTC)

The proposal is to restrict freedom of expression for some users. In the grand scheme of things, perhaps, it is a comparatively minor restriction, but a restriction nonetheless. The benefits advanced for doing so seem mainly theoretical, rather than practical, and to the extent that they are practical, the justifications set forth for protecting some types of difficult-to-type names but not others are not convincing, to me, at any rate, and I happen to detest IPA characters. --Hobbes Goodyear (talk) 12:33, 26 October 2011 (UTC)

This is covered by WP:DICK, isn't it? If your user name is in Kanji because you're Japanese, that's not a problem. If you're using 〠 as your user name simply because you get a kick out of people having difficulty grokking or replying to your posts, then your standing amongst your peers will be negatively affected. There aren't really enough editors doing this to really justify a rule against it, and you'd imagine that editors who were doing it for kicks would likewise get a kick out of the community running around making special rules for them. Chris Cunningham (user:thumperward) - talk 12:41, 26 October 2011 (UTC)

Oppose, obviously. I understand the concern, but this is really venturing into instruction creep territory. Just leave people alone and let the magic of copy-and-paste take care of the "difficulty" of dealing with usernames like 兔子 or Δ or Zoë or whatever. ☂ (talk) 15:03, 26 October 2011 (UTC)

We used to block usernames for this, actually. The practice died out around the same time SUL was implemented. Here's a quick trip down memory lane:

• Wikipedia talk:Username policy/Archive 2#non-latin names
• Wikipedia talk:Username policy/Archive 2#Protest
• Wikipedia talk:Username policy/Archive 3#Non-latin characters and Unified Login
• Wikipedia talk:Username policy/Archive 4#Latin character server suggestion
• Wikipedia talk:Username policy/Archive 4#Latin character transliterations
• Wikipedia talk:Username policy/Archive 8#Non-latin usernames, revisited
• Wikipedia talk:Username policy/Archive 10#Introducing a term: The المستهلك Test
• Wikipedia talk:Username policy/Archive 17#disruptive use of non-Latin usernames

As you can see in archives 3 and 4, the arrival of SUL resulted in a nearly immediate reversal of the old policy. The question was brought up again as recently as August 2011, at Wikipedia talk:Username policy#RFC: Use of non-latin or unicode characters as usernames. – Luna Santin (talk) 21:30, 26 October 2011 (UTC)

• Comment I know this isn't exactly easy, but I would support banning non-Latin characters that look like Latin characters. Stuff like the dotless i, or maybe Greek letters like omicron, if that has a Unicode. Too easy for someone trying to make trouble to register a username that's not the same as an existing one, but looks the same. --Trovatore (talk) 21:38, 26 October 2011 (UTC)
  • WP:IMPERSONATOR forbids these already, and the software actually checks for similarities itself. I know because I had to find a wiki where User:Ü, who is not in SUL, was not registered before I could register User:Uʔ. If you're curious, you can't register User:? at all. Uʔ (talk) 21:58, 26 October 2011 (UTC)

User:☂ says, "…this is really venturing into instruction creep territory."

In fact I don't think it is. This isn't instruction creep because the concern being expressed here does not pertain to the content of articles. Bus stop (talk) 22:08, 26 October 2011 (UTC)

Facepalm. Uʔ (talk) 22:40, 26 October 2011 (UTC)

It's another concern entirely. The notion of "instruction creep" would never have arisen in the first place if we were not involved in the ostensible practice of writing an encyclopedia. Bus stop (talk) 22:56, 26 October 2011 (UTC)

This proposal will fail for the same reasons other, similar proposals have failed: (a) There is no clearly definable criterion for what an "uncommon" character is, or just how uncommon it has to be in order to be intolerable; (b) we have to tolerate lots of uncommon characters coming in through SUL from other wikis anyway, so the few users who choose uncommon characters here for frivolous reasons don't really add any significant weight to the problem, in proportion to the many who have them for the obviously legitimate reasons. Sure, choosing a hard-to-type name just for the fun of it may come across as annoying, but trying to stop people from being annoying by making rules about annoying behaviour is an exercise in futility. Fut.Perf. ☼ 23:01, 26 October 2011 (UTC)

Annoying is debatable. Editing Wikipedia is a political statement as it was demonstrated during the Italian Wikipedia strike. We should keep Wikipedia as open as possible while observing its primary role as an encyclopedia. Uʔ (talk) 23:31, 26 October 2011 (UTC)

Indeed, this proposal probably won't pass. We have a better chance of amending our signature policy to require that at least a portion of any signature must be in local-language characters on a given local-language wiki (English in this case since we have no jurisdiction over other wikis). In such a case, our example User:兔子 could have their signature appear as '兔子 (English alias)', giving other editors at least something to refer to them as. TechnoSymbiosis (talk) 23:35, 26 October 2011 (UTC)

That already exists; see WP:SIG#NL. Uʔ (talk) 23:40, 26 October 2011 (UTC)

I know about that section, but it has no weight. It's a suggestion out of courtesy and countless editors don't follow it. I'm suggesting it be required, rather than recommended. TechnoSymbiosis (talk) 23:45, 26 October 2011 (UTC)

I don't know if that's a good idea. Just consider the editor who makes only a few edits here like interwiki links, etc. After he makes his first talk page post, boom, an admin warning (or block) lands on their talk page requiring them to change their signature. Quite WP:BITE-y. Perhaps have Twinkle detect non-Latin characters in username and add a polite message alongside the welcome screen instead? I would support that. Uʔ (talk) 23:58, 26 October 2011 (UTC)

Oppose can we put this under WP:PEREN yet? This discussion happens every few weeks it seems. There's no conceivable reason to have this or way to enforce it. We already have to allow non-Latin characters because of WP:SUL; with all of the writing systems and whatnot, it is nearly impossible to, at first glance, tell if some character is part of another writing system which I am unfamiliar with, or is a non-linguistic symbol. Given the royal pain in enforcing such a proposed rule (does every admin have to scour through pages and pages of writing systems before deciding to block a username for containing non-language symbols?) and the lack of reason why a non-language symbol is somehow more of a problem than a username in Greek or Cyrillic or Japanese, I really don't see any reason why such a rule needs to exist. Let me state that again: There's no reason why a non-language symbol like ʔ or even ♠ is somehow more of a problem than, say, a Japanese character. Given that the latter are allowed, there's nothing disruptive about the former. --Jayron32 00:06, 27 October 2011 (UTC)

I did check for a WP:PEREN entry, before making my post above. ;) Might be time. – Luna Santin (talk) 00:08, 27 October 2011 (UTC)

• Oppose - Σ is a character in a written language. There's an old thread on WT:UN that may be relevant. →Στc. 01:45, 27 October 2011 (UTC)
• I oppose a specific criterion. However, I think common-sense should tell us that "User:ʔ" is confusing to the point of disruption, and should be forced to change.  Chzz  ►  03:27, 27 October 2011 (UTC)

Summarize user name policy on account creation screen?

In the above discussion, it occurred to me that the user name policy is not linked from the plain account creation screen. It might be linked from Outreach:ACIP or some other process. I suppose that is done intentionally as to avoid overwhelming the newbies. On the other hand, I've seen a few blocks for promo user names, so not giving any information beforehand seems to set up a WP:BITE trap for some. Perhaps a nutshell of the policy should be added to the account creation screen? Uʔ (talk) 23:31, 26 October 2011 (UTC)

• Support nothing much else to say. Well summarized. -- fg^TC 23:47, 26 October 2011 (UTC)
• Looks like MediaWiki:Fancycaptcha-createaccount? There is a link to the policy in "Simply choose a username", but it's hardly something people would notice. Could stand to make it more obvious. – Luna Santin (talk) 00:14, 27 October 2011 (UTC)
  • I was aware of that link, but I think it's not well contextualized and eclipsed by the one in the previous sentence. I didn't pay any attention to it when I registered my initial account. Because only "username" is linked there, a newbie would probably expect that link to provide a definition of "username" rather than rules of what's allowed and what not in it. If you consider that the "benefits" sentence is in bold and has its own link to a rather long page (Wikipedia:Why create an account?), the reader's attention surely has waned by the time they get back, assuming they're even inclined to read pages linked from that screen. Uʔ (talk) 00:42, 27 October 2011 (UTC)

Sounds like a possible problem with WP:TL;DR to address there. -- fg^TC 00:49, 27 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#First sentence should be italicized completely. – Luna Santin (talk) 20:35, 26 October 2011 (UTC)