This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
I believe the main page of Wikipedia could be make a great deal bolder with a couple of small changes. The top boxes (In the News) and (Today's Featured Article} are not bold enough - the headings should be in BOLD and ALL-CAPS and the typeface should be at least 2 points larger, with the blue news headlines possibly flashing or just scrolling along the top of the page in the manner of a news ticker, also there should be a much larger image on the page, and the font is a bit square, should be replaced for something a bit more fun. I think this would get more people keen to view more parts of the site. Horatio Snickers (talk) 16:31, 4 August 2013 (UTC)
Please let's not have any flashing or scrolling. Such techno-wankery was popular in the 1990s, but in the 2010s most serious web sites have realised that it's better to be designed by and for adults. Phil Bridger (talk) 21:50, 4 August 2013 (UTC)
The problem is that flashing and scrolling only serve to distract readers from the important thing, the content. If you lack the basic good taste to understand that then I suggest that you take a look at http://www.webpagesthatsuck.com for an expert opinion of such gimmicks. And I have no idea how old you are, which is why I said nothing about your age. Phil Bridger (talk) 20:14, 5 August 2013 (UTC)
I am developing condensed overviews of wikitext markup, in the form of reference card displays called "wp:helpboxes". Each helpbox is a condensed overview of features, summarized for power users, but with some explanation so new users begin to quickly see how wikitext is structured. For example, during edit, a user puts "{{wikitext}}" to see the format of wikitext markup. {{wikitext}}, will display:
The term "wikitext" refers to Wikipedia's wp:wiki markup language. Formats:
The concept is "wikitext in a nutshell box" (really small) because many users have complained that learning wikitext, tables, and common templates spans "hundreds and hundreds of help pages and tutorials" (as a long shaggy dog story), and it probably does. Instead, professionals (mathematicians) use reference cards, of formulas or computer language commands, as condensed reminders of format or syntax rules. For example, wikitables can also be summarized in a helpbox (just the basic table-cell styles).
{{wikitable}}, will display:
{{wikitable}}
So, I propose to expand this "helpbox" concept (ofreference card boxes) to show parameters of the 50-100 major templates, wp:parser functions, and calculation codes during edit-preview, so that power users will have instant reminders of template parameters and wikitext, and new users can see a pattern where a few dozen helpboxes would answer most of their questions about Wikipedia features, without worrying about the hundreds-and-hundreds of help-pages (which are fine when teaching Wikipedia classes in schoolrooms) but seem like endless "walls of text" which users must read before being able to edit. Does this concept seem workable? -Wikid77 (talk) 08:12, 4 August 2013 (UTC)
"Does this concept seem workable?" Yes, this seems very workable. I think this would be a great benefit to many editors. Thanks for coming up with such a helpful idea. 64.40.54.132 (talk) 02:07, 5 August 2013 (UTC)
Some complex topics require showing common subsets of features: In particular, the complexity of math-tags (Help:Math), which allow hundreds of symbols, will require the related helpbox(es) to show only a common subset of math-tags used for a typical formula or equation. Possibly the total can be split, where some helpboxes would be for specific types of mathematics, such as integral calculus, where set notation would be a link to another helpbox. I had forgotten how some areas of Wikipedia use hundreds of options. -Wikid7718:11, 8 August 2013 (UTC)
Including how their college was paid for individual entries
More for political persons, but I think all would find it interesting, if when it is cited that such and such a person attended a certain college or university, that, if it can be known, how did they afford to go to that (private) college or university: a grant, a scholarship, they worked their way through, or, it was just "paid" for.
If that information is known and pertinent, it's probably going to be included already; this doesn't require a substantive change to policy or practise. Ironholds (talk) 01:30, 5 August 2013 (UTC)
In most cases the tuition is 'just "paid" for' (did I miss some subtle inference here?) — by "daddy". How would that be "interesting"? ~ J. Johnson (JJ) (talk) 19:33, 8 August 2013 (UTC)
Sounds like an attempt to push some class related narrative. IE that having it paid for by family diminishes the achievement. Monty84519:44, 8 August 2013 (UTC)
Alternately, perhaps to show that many liberals sucked the teat of gov't backed student loans? I am hard pressed to imagine any kind of scenario that "all would find ... interesting". This seems a pointless topic. ~ J. Johnson (JJ) (talk) 20:06, 9 August 2013 (UTC)
I think you are interpreting this sort-of in the right way, with a bit of snark and sarcasm, and realizing the potential political implications.. however, I think recent events have flipped the other way, by pointing out the hypocrisy of politicians like Paul Ryan who used government funding as a child (namely social security) to pay for many things including his college education.. and yet now he allegedly wants to take away those very same benefits from others because it is in his opinion "a ponzi scheme". So, it's not necessarily negative propaganda towards 'liberals sucking on the teat of government' that people want to make a point of. In regards to the OP's suggestion, as others have said, if the funding of _anything_ is suitable in an encyclopediac NPOV way and can be cited from a RS, then it can be included. There need not be a special field or section for it. In most cases, I'd say it's unlikely to be available information or even if it was, it's likely to be of no interest; however, in some cases it may be of interest, important, and can be handled well. Centerone (talk) 00:15, 10 August 2013 (UTC)
As with every other quantum of information, do reliable sources cover it? Do we give it only the weight RS assign to it? This is not, in my opinion, a special case. DavidLeighEllis (talk) 23:55, 9 August 2013 (UTC)
I suspect that people who are trying to figure out how they will pay for their own tuition are interested in this, and that other people aren't. As usual, I think that David is right: if the reliable sources emphasize this, we should, too; if they ignore it, then we should, too. WhatamIdoing (talk) 04:52, 10 August 2013 (UTC)
Mass removal of old indefinite rangeblocks
This discussion is about how to handle indefinite blocks of certain IP ranges. Our guideline on this (an information page actually) WP:IPB#Guidelines indicates that IP addresses should almost never be indefinitely blocked and indicates that rangeblocks should be even more carefully considered. The question is here is when and how to review indefinite rangeblocks.
There were a number of issues raised. Some came to clear consensus, others less so. The consensus can be summarized as follows:
All indefinite rangeblocks should be reviewed at least once a year. No IP should be permanently blacklisted Consensus was clear on the first review, a bit more foggy on what to do after it "failed" a review, but doing it once a year or so seemed acceptable to most who commented on the issue.
Everyone would be welcome to participate in the reviews, but there are things only a checkuser can do and so any discussion should have a checkuser's involvement. Callanecc's proposal that CUs be the one to close all such discussions seems quite reasonable, but was too late in the discussion to gain consensus.
There was clear agreement that everyone would be welcome to monitor activity after a range block is lifted and that it would be very useful to have a bot show listings from the ranges in question. Exactly what the bot would do hasn't been determined.
On a personal note, I don't see how non-CU folks are going to be able to detect problems with registered users on these IP ranges. I don't see how a bot could help without creating privacy problems when it comes to registered users. But that's a problem for a later day. Hopefully there is a simple answer I'm missing.
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.
Currently, there are about 200 indefinite rangeblocks on various IPs, most of which are non-required now. A previous proposal on this Village Pump, which sought to remove these old rangeblocks under controlled conditions passed successfully. This proposal is to finalize all the various details on that proposal, and to carry forward with it.
TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)
The general agreement in the previous discussion was -
All rangeblocks beyond a certain time period will be reviewed.
The rangeblock is reverted unless there is strong reasons not to.
All reverted rangeblocks are placed in a special category for monitoring
After sufficient time of activity,
If the IPs are good faith, they are removed from the monitored list
If they continue with their vandal behaviour, they can be reblocked as the blocking admins see fit. If they get indefinite rangeblocked again, the rangeblock could again be reviewed after the time period in Step 1.
If there is any confusion or disagreement regarding the above "general agreement" steps, please start a new discussion section below on the same so that we can discuss them, and other possible alternatives.
TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)
Discussion
The sections below are for finalising and having discussion on the other ambiguous details that have been left out in the original discussion. Please feel free to add more sections, or more options to the ones already given, or to support, or have discussion on any of the options already mentioned.
TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)
In my opinion, indefinite rangeblocks should simply be prohibited entirely. Even for the most abusive sockpuppeteers or the widest open proxies, chances are, the IP's been reassigned. I would support a 2 year max for most cases, and a strict 5 year max in the most extreme cases. -- King of♥♦♣ ♠ 00:57, 26 June 2013 (UTC)
I think that an indefinite rangeblock might have a place if there are outstanding legal threats, or if there is vandalbots coming from that IP. Gross BLP violations may also be included. I must agree with the general sentiment that an indefinite rangeblock is a poor solution in general, however. Tazerdadog (talk) 04:35, 18 July 2013 (UTC)
Here is the list of all indefinite IP rangeblocks. With the exception of the Toolserver soft blocks, all will need to be reviewed. A couple of them seem to have been requested by the administrators of the IP ranges in question - perhaps we need a better process for documenting such requests in greater detail. — This, that and the other (talk)07:28, 29 June 2013 (UTC)
This whole series of proposals seems to be under the (mis)conception that indefinite means infinite. Indefinite length just means without defined length. The simplest answer I think, is just to allow discussions of indef rangeblocks by any editors, and review of indef rangeblocks by any admin... oh wait we already do allow that. So really all we need is a list of indef rangeblocks (auto-generated would be nice), and volunteers willing to look them over at their discretion. All the rest of these proposals really sound too WP:BURO to me. (For the closer: please treat this as oppose all the straw polls.) - jc3715:14, 1 August 2013 (UTC)
Time period before review
How much time should it be before the previous rangeblock is reviewed?
3 months
6 months
9 months
1 year
2 years
6-12 months - If the range is rotten it won't take long for problems to show up. In a /16-/18 or so i seem to recall seeing proxies popping up at about 6 month intervals. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
Wait, is this rangeblocks in general (I was originally thinking this was just the old indefs which should be lifted and then reviewed after 6-12 months)? If so, I would distinguish strongly between hosting and ISP blocks. ISP blocks should rarely longer than a few months before they should be reviewed. If we're talking hosting providers, a year or two for review after a first block, five years for repeat offenders. Rotten hosts tend to stay rotten hosts, and the useful to useless ratio for those ranges tends to be exceptionally unfavorable with very little activity. Sailsbystars (talk) 13:31, 25 June 2013 (UTC)
Basically I do not think we should be creating a list of 200 mostly unneeded range blocks, but I am not sure how a rangeblock can be reviewed without releasing it and seeing if any edits ensue. I would personally prefer an emphasis on helping rogue editors learn how to contribute positively instead of just blocking the IPs used, but I would opt for a standard 3 month review of all range blocks, so that unneeded ones did not accumulate. Apteva (talk) 18:45, 25 June 2013 (UTC)
Both ninjapirate and apteva are in the ballpark, I'm going to say 3 months on the first review and six months thereafter, with broad discretion given to whoever does the unblocking.Tazerdadog (talk) 19:50, 25 June 2013 (UTC)
12-18 months Sure, some will be free before then, but all should be reassigned within 12-18 months... Very few should "still" be an issue. I'd rather see less frequent and more thorough passes. Technical 13 (talk) 22:33, 25 June 2013 (UTC)
Why do you believe that all IPs are reassigned within 12–18 months? I know of some that haven't been reassigned for 18 years. WhatamIdoing (talk) 07:14, 26 June 2013 (UTC)
1 year or so before any mandatory review is required. This is not at all to say the current review process/procedures are affected by this either. This is just an additional review that should have no bearing, implied or otherwise, on current rangeblock procedure. Shadowjams (talk) 22:59, 25 June 2013 (UTC)
Indefinitely-blocked IPv6 ranges do not need a periodic review. IPv6 is too easy to acquire, and if some fixed period like 1 year had effect, then a determined troll with a thousand of IPv6 address blocks would be able to disrupt the system in a DDoS fashion. Incnis Mrsi (talk) 05:31, 14 July 2013 (UTC)
1 year. I would be opposed to an automatic removal of bans, partially because of concerns like Incnis Mrsi raised, but I think one year is a reasonable amount of time to take a fresh look at IP blocks. Andrew32700:29, 16 July 2013 (UTC)
1 year generally seems to be a good time frame. However the group of users reviewing the blocks should have the discretion to set a longer duration, up to maximum of 3 years when soft blocking only (I'm thinking specifically of school blocks which can generally be longer term without much drama, remembering that there is always WP:ACC). Callanecc (talk • contribs • logs) 05:59, 17 July 2013 (UTC)
1 year would even be OK with two provided as per Shadowjams that this is a mandatory review - others can specifically request one in the meantime. ϢereSpielChequers22:07, 17 July 2013 (UTC)
Who participate in the reviews
Which group of users will participate in the reviews before the old rangeblock is lifted?
Bureaucrats only
A specialised elected/selected group of trusted editors (may be chosen along with one of the other options)
Administrators only
Administrators + Rollbackers
Administrators + Reviewers
Autoconfirmed
Everyone
One of the other categories + a group of trusted users
Specialised/ selected groups - Checking the range involves proxy-checking skills, which some users have and some admins have. That's the main source of rotten ranges requiring long term rangeblocks Or I could run for admin, since I'm not aware of any other specialised non-admin users. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
Specialised Group: Namely I say we give ArbCom a bit more to do. The Arbs are bound to have a CU on the team if it's needed or they can just ping one. I mean a CU is hardly going to refuse to help our top line of nitwits editors now are they? MM(Report findings)(Past espionage)13:00, 25 June 2013 (UTC)
Specialized group. I'm not too concerned with this detail. Elected/selected volunteers, arbcom, or admins. I'm switching to Everyone. We could also put up regular, recurring RfCs and invite comments by Autoconfirmed users. Could be fun. NinjaRobotPirate (talk) 13:39, 25 June 2013 (UTC) (update: 13:28, 26 June 2013 (UTC))
Everyone. The person reviewing the IP should be the person responsible for monitoring that IP. If you can take responsibility for the monitoring, you should have the authority to decide the review (within reason and policy)Tazerdadog (talk) 19:53, 25 June 2013 (UTC)
Specialised/selected group of trusted users that should be given a smaller package of the admin tools. Rights that should be included are the ability to (un)block (single|range), check-user, override title blacklist, noratelimit, at least to start. These are the minimum tools needed to complete these tasks, and if the users are trusted/elected, it shouldn't be an issue. Technical 13 (talk) 22:42, 25 June 2013 (UTC)
Everyone, but of course more weight should be given to the opinions of checkusers and skilled proxy checkers. -- King of♥♦♣ ♠ 00:52, 26 June 2013 (UTC)
Everyone of course. Seems like a nobrainer. I can't believe there's even a suggestion that an appeal process like this would exclude outside input wholesale. Shadowjams (talk) 05:27, 26 June 2013 (UTC)
Checkusers, because checkusers are the only people that can actually monitor the behaviour of an IP range. All the rest of us can judge is the quality of the anonymous edits inside the range.—Kww(talk) 23:37, 29 June 2013 (UTC)
Everyone or a selected group. However the review should be commented on during discussion and closed by a CheckUser who can check the quality of all edits from the IP/range. Callanecc (talk • contribs • logs) 06:02, 17 July 2013 (UTC)
Which group of users will monitor the activity after the old rangeblock is lifted?
Administrators only
Administrators + Rollbackers
Administrators + Reviewers
Autoconfirmed
Everyone
One of the other categories + a group of trusted users
Everyone - Problems can be reported to WP:AIV, WP:ANI and/or WP:OP like any normal disruption. The same group involved in reviewing the blocks above can then look for complaints that resulted from monitored ranges. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
Everyone should pitch in, but the responsibility ultimately lies with the reviewers of the specific range unblock here. Just a point to mention. I am working under the assumption that we will be monitoring the activity of the recently unblocked users at a particular location so we can keep an eye out for the ones who might be going back to bad faith edits [Waiting for the normal blocking process appears to be counter-intuitive to me for such cases.] If not monitoring them (specially) is what others have in mind, we can clarify that with a discussion. TheOriginalSoni (talk) 22:14, 25 June 2013 (UTC)
Everyone - Problems can be reported to WP:AIV, WP:ANI and/or WP:OP like any normal disruption. The same group involved in reviewing the blocks above can then look for complaints that resulted from monitored ranges. Technical 13 (talk) 22:43, 25 June 2013 (UTC)
Everyone - admins will need to make the ultimate decision, but most of the monitering work can be done even by anons who regularly edit without creating an account. עוד מישהוOd Mishehu21:44, 2 July 2013 (UTC)
Everyone IPs are reported as normal. Perhaps a bot can be set up to leave a comment that the IP reported is from a monitored range. And it flags that an IP from a monitored range has been reported on a page devoted to the reviews. Callanecc (talk • contribs • logs) 06:05, 17 July 2013 (UTC)
How are the changes monitored?
How should the changes be monitored? Through a WikiProject, something similar to the pending changes (a special category), or a bot? Discuss below TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)
Bot existing tools are a bit of a pain in the tuchus for checking this sort of thing, it would be nice to have a page listing contributions from these ranges. Sailsbystars (talk) 09:33, 25 June 2013 (UTC)
Unsure I'm not convinced that using a bot for this is the appropriate course of action. Let me think about it some more and see if there may not be a better alternative. Technical 13 (talk) 22:44, 25 June 2013 (UTC)
Bot - Seems like an easy answer. It should be mentioned that most of the load would be offline anyway. Simple monitoring of the block log would be enough. Shadowjams (talk) 05:19, 26 June 2013 (UTC)
What should be done with the worst case rangeblocks? Should we have a blacklist for them, or give them a little WP:ROPE and reblock after bad-faith edits after every review?
Some combination of the above. Blocks shouldn't be permanent (in case ranges change hands), but certain repeat offenders (e.g. theplanet hosting) should be named, shamed, and blocked at the slightest hint of trouble. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
WP:ROPE as this rule states that you can give them so long before you hang them. If they still don't get the picture after a 2 year block on the situation then they're just not going to get it ever. MM(Report findings)(Past espionage)13:11, 25 June 2013 (UTC)
3/6/12 month review period, as above. Open to supporting longer periods, too. Permanent blacklists seem too punitive. IP blocks can and do change ownership. NinjaRobotPirate (talk) 13:44, 25 June 2013 (UTC)
Repeat offenders can go on a separate list that has no probationary period. At that point, the only problem becomes workload. If reviewed yearly or biennially, workload should be manageable. I dislike the idea of a permanent block for an entire IP range. If we all get an IPv6 address tattooed to us at birth, this may change, but, for now, IP addresses are not people. NinjaRobotPirate (talk) 15:32, 25 June 2013 (UTC)
I don't think permablocks are the answer either, but for bad hosting providers, they seem fairly stable over periods much longer than 12 months. The amount of workload involved is quite extensive. A thorough and proper check of an IP range can easily take an hour. I don't know our total number of rangeblocks, but I'd guess it's in the thousands. For annual reviewing, it would be equivalent to one or more full-time real job. Sailsbystars (talk) 15:44, 25 June 2013 (UTC)
SoSoni could you clarify if you mean for all of the subpoints of this proposal apply to all IPs, or just the ones that currently are under an indef block? If so, I agree that checking the 200 or so wouldn't be a huge problem. Sailsbystars (talk) 19:21, 25 June 2013 (UTC)
Yeah. That's my understanding. Some of them are easy. Voluntary blocks, commercial proxies, etc don't require much effort to validate. Professional spammers and determined vandals (GNAA/4chan) will be where most of our efforts go, I think. They may actively try to hide their nefarious intent. For something like The Anonymizer, you just make sure it's still running and at the specified IP range. NinjaRobotPirate (talk) 19:48, 25 June 2013 (UTC)
Just the indefinite ones. I thought it was clear from my header. Also, if there was no indef-block, the block would go away anyways. (Assuming no admins block for a very long period of time, in which case, we might have to check all blocks larger than our review period too) TheOriginalSoni (talk) 20:04, 25 June 2013 (UTC)
Well, yes, but the current practice has moved to 2-5 year rangeblocks for disruptive hosting ranges. Hence why I'm a little hesitant about some of the proposed remedies if they would make review more frequently. This practice seems to have been fairly successful, but it would be nice if it had endorsement from the broader community. Sailsbystars (talk) 21:08, 25 June 2013 (UTC)
Blacklists should be extremely rare, and probably limited to stuff like outstanding legal threats, and maybe gross intentional violations on a BLP beyond petty vandalism. (e.g. Joe Shmoe is a rapist...) Tazerdadog (talk) 20:01, 25 June 2013 (UTC)
ROPE. Keep repeating the 1-year blocks, it's not too much work. Eventually they'll either give up or their ISP will reallocate that block to someone else. -- King of♥♦♣ ♠ 04:36, 8 July 2013 (UTC)
Give them ROPE, however allow the monitors to block for periods longer than a year (max of 3 years) for the most abusive ranges, where there is a long history of blocks to show that one year probably won't work. Callanecc (talk • contribs • logs) 06:07, 17 July 2013 (UTC)
Additional Proposal
Following Sailsbystars' concerns at the above section, I propose that After the expiration of the said review period for definite rangeblocks, they will be undergoing a the same (review) process that other indefinite rangeblocks have. So if the review time is decided to be 6 months, then ordinarily, all definite-blocks older than 6 months will also get reviewed under the same rationale as the indef blocks. TheOriginalSoni (talk) 22:20, 25 June 2013 (UTC)
Meh, I see this as more of an on-going process and not a circular thing. It's either going to be the same person on the other end of the IP or it's not... After 12-18 months, "most" IPs should have changed hands at least a few times. I don't see any reason not to assume good faith and let the IP start with a clean slate for each pass. Technical 13 (talk) 22:47, 25 June 2013 (UTC)
Comment - I'm not thrilled about the idea of complicating this specific question with additional issues like this. The question of if a definite rangeblock of 3 years is worse than an indefinite one is unclear. My gut instinct is to leave it aside, although after some thought I think that erasing the distinction between indefinite (which always seems like a cop out to me) and definite but long, is a good thing. Shadowjams (talk) 05:25, 26 June 2013 (UTC)
This seems eminently logical. I can't really see any reason why it wouldn't work like this, except for workload. Considering that, we might need to re-think the frequency of reviews. NinjaRobotPirate (talk) 17:50, 26 June 2013 (UTC)
I don't think workload would be an issue, if the period is 1 year. 6 months might be a bit too frequent, though. -- King of♥♦♣ ♠ 23:23, 7 July 2013 (UTC)
Comment My concerns would be allayed if we distinguished between hosting IPs and ISP IPs. For the ISP IPs (or corporate filter webhosts or really, most IPs), I have no problems whatsoever with limiting those to 3-6 months. Web hosts, however, tend to be rather static, and have a.) much lower IP contribution rate than ISP IPs (I did a little experiment once and came up with a ratio of either 10 or 100x more edits from the ISP range) and b.) low helpful to harmful contribution ratio and c.) never NEED to be edited from. Based on experience, certain hosting ranges have earned 2-5 year blocks, and nothing of value was lost. An aside, I realize this is a bit of instruction creep and would be difficult to manage due to the fact that blocks can't be sorted by the block log notes (at least as far as I'm aware). Sailsbystars (talk) 21:11, 26 June 2013 (UTC)
Examples of an ISP IP would be ones from ComcastorVerizon in the USA, British Telecom in the UK, or Orange SA in France. Cell providers, government or uni IPs would fall under this category as well. Examples of hosting providers would be SoftLayer, Rackspace Hosting, or Go Daddy. Basically, under normal circumstances, all of us edit from an ISP of one sort or another. All of these involve a computer sitting on a desk somewhere connected to the internet. With hosting providers, the computers are all sitting in a data center somewhere with no human at them. Under normal circumstances, most edits from webhosts are from people trying to escape scrutiny or evade a block/ban as they involve an extra effort beyond what one normally uses to connect to the web(e.g. anonymizing services, proxies, some VPNs, on the rare occasion one own's server). Hope this helps? Sailsbystars (talk) 05:13, 27 June 2013 (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.
Final Note - If there are further topics of discussion, please add them as a section above this line.
How about a "Wikipedians in prison" program?
Original Poster has tabled this discussion in favor of getting the WikiMedia Foundation involved. Nothing to see here, move along Hasteur (talk) 15:22, 14 August 2013 (UTC)
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.
There is no end to the work to be done on Wikipedia, and convicted criminals serving prison sentences have plenty of time on their hands. Perhaps we could start a program to give those in minimum security prisons, where they tend to have more amenities, the opportunity to edit Wikipedia as part of their rehabilitation. Cheers! bd2412T16:24, 7 August 2013 (UTC)
How about some more details. Are you talking about giving donor money to purchase computers and internet access for inmates? Are you talking about curent editors volunteering and running programs inside correctional facilities? If so which facilities? Flesh out your plan please.--159.221.32.10 (talk) 16:43, 7 August 2013 (UTC)
I have not reached those issues, but I think that Wikipedia editing could be introduced through programs that already exist to teach prisoners various life skills, and by the people who are already presenting these programs. My understanding is that, to the extent prisoners currently have internet access, it is usually restricted to a limited range of websites - those that allow the prisoner to pursue educational goals, for example. Adding Wikipedia to the accessible sites would be the job of whoever is regulating access to other sites. Within Wikipedia, there would be a mentoring/monitoring project to assist prison participants with constructive editing and curtail non-constructive edits. bd2412T17:19, 7 August 2013 (UTC)
Just some advice from one who has previously conducted one of those existing programs. This will remain a theoretical exercize unless you find people willing to arrange and conduct programs within individual facilities.--159.221.32.10 (talk) 17:33, 7 August 2013 (UTC)
Minimum security harbors embezzlers, inside traders, and market manipulators that have unique expertise in the subtle truth spinning that drives Wikipedia's contentious topics. Also there should be a death row initiative that somehow increases an editor's credibility in inverse proportion to the time they have left, the logic being that they'll grow increasingly motivated to leave a positive impact on the world. Equazcion(talk) 16:50, 7 Aug 2013 (UTC)
It was a joke. Unclench. Equazcion(talk) 17:21, 7 Aug 2013 (UTC)
Oppose. I feel that those serving prison terms might be less likely to support WP:NPOV. I also think this sends the wrong message to law abiding citizens.Bus stop (talk) 16:58, 7 August 2013 (UTC)
I agree there may be a higher incidence of behavioural issues, and that's why this should include strict mentoring by other editors, along with regular collaboration with the prison personnel. As for the message to law abiding citizens, uhm, aren't prisoners meant to be rehabilitated, and not simply punished? --cyclopiaspeak!17:03, 7 August 2013 (UTC)
Haven't there been similar programmes with children? They wreak even more havoc than I could imagine minimum security prisoners would. FunkMonk (talk) 17:11, 7 August 2013 (UTC)
I asked the question to BD2412, but feel free to touch on it Cyclopia. What form do you see this taking? Are you talking about purchasing hardware? Are you talking about in facility programs? If you don't intend to go face to face inside a facility, how do you see prisoner recruiting taking place. Take it at least one step from goal to theoretical plan.--159.221.32.10 (talk) 17:16, 7 August 2013 (UTC)
I think BD was referring to a general welcome/get-the-message-out/mentoring sort of thing, no hardware etc. I have to think prisoners would embrace anonymity and not not admit they were editing from prison, but I don't see any particular reason to oppose. Anyone can edit and anyone can be welcomed and mentored to edit. Equazcion(talk) 17:20, 7 Aug 2013 (UTC)
If prisoners are able to edit anonymously, then for all we know there are many who already are. I suspect we can trace ip addresses to prisons as we have with schools (and Congress). bd2412T17:23, 7 August 2013 (UTC)
I don't think there's any reason to tag prisoners that way. If they want to voluntarily announce it they will. PS. When I said "anonymity" I didn't mean IP editing, but simply lack of self-identification as a prison inmate. I doubt they'd want to identify as such whether editing from an account or an IP. Equazcion(talk) 17:25, 7 Aug 2013 (UTC)
There may be some benefits to the prisoners, however. Constructive participation in a collaborative project like Wikipedia might, for example, be the kind of evidence of good behavior that reflects well in parole board hearings and the like. bd2412T19:04, 7 August 2013 (UTC)
Support. This would also most likely have the advantage of improving the racial diversity of Wikipedia editors. We're keen to help people edit Wikipedia when they are disadvantaged by their nation of birth; why not people who are disadvantaged in other ways too, regardless of nation? --Demiurge1000 (talk) 19:12, 7 August 2013 (UTC)
There are so many things wrong with this comment that I don't even know where to begin. Any other social venue, you'd get your ass kicked out the door.Volunteer Marek21:26, 7 August 2013 (UTC)
Neutral Those editors who may be incarcerated probably won't have access to the breadth and quality of sources that are available in the outside world. What purpose does creating this program do other than to paint a bright red bulls eye on contributors for anybody having a bad day to shoot at? If there are editors in prison that are contributing productively what perceived benefit would there be in having those editors stand up and claim their special badge? Yes there might be a valid reason for WikiMedia Foundation to investigate and provide a way for inmates to contribute their knowledge, but en.WP is not here to correct great social injustices. Reccomend this proposal be tabled here and opened at the foundation's proposals/ideas pump. Hasteur (talk) 20:08, 7 August 2013 (UTC)
too stupid to even begin a serious discussion of Maybe there are some people in jail who are literate enough and honest enough and well-behaved enough and who have access to sufficient resources to write material from. But do we really want to be able to advertise this as "the encyclopedia written by murderers, thieves, and con men"? If we're that desperate for contributors the cause is lost. Mangoe (talk) 20:46, 7 August 2013 (UTC)
Mangoe, are you saying that somehow a murderer, thief or con man is less capable of editing an open access enyclopedia than any other member of the public? Horatio Snickers (talk) 20:54, 7 August 2013 (UTC)
Come on, Snickers: if that's how you (mis)read what I said, maybe you should think about whether you're cut out for this. Mangoe (talk) 21:16, 7 August 2013 (UTC)
Mangoe, I'd like to be able to advertise this as "the encyclopedia where also prisoners can help us to build the sum of all human knowledge, and it helps them rehabilitate to work in a functional society". Non-punitive penal labour exists, just like many convicted criminals are, in many nations, able to do volunteer work instead of serve in prison. The volunteer associations who take in these criminals are surely not tainted by it: on the contrary, it is part of their social mission to rehabilitate criminals. If your concern is instead, more generally, that murderers can edit Wikipedia, we already had that in the open: Anders Behring Breivik had an account here. --cyclopiaspeak!11:00, 8 August 2013 (UTC)
If "Wikipedia is not therapy", still less is it a means for such rehabilitation. I want Wikipedia to be, and I think Wikipedia needs to be, "the free encyclopedia you can trust." A program like this would knock that trust down still further, and I seriously doubt we are capable of the kind of supervision needed to make that trust possible. Mangoe (talk) 11:26, 8 August 2013 (UTC)
We're not therapy, true. But here we have on one hand a pool of people with a lot of idle time on their hands, that could help us -and on the other hand, by helping us they could help themselves. A structured program is exactly what you want if you want more trust: after all, prisoners with Internet access are probably editing WP right now: wouldn't you prefer them, for trust, to be mentored and known, instead of being anonymous? I share some doubts on the capability of supervision as well, but I don't want to be pessimist from start, and I see this as, at least, possible and worth considering.--cyclopiaspeak!11:39, 8 August 2013 (UTC)
Mangoe, I still don't understand what your point is. Regardless of what people may think of them, what skills does a prisoner lack that a non-prisoner have when it comes to editing "the encyclopedia anyone can edit". Your original point seemed to be saying that anyone who is currently serving in prison is severely unlikely to be able to edit WP (something I would challenge entirely), and that even for those who could, we ought not to enourage this (in case they damaged the enyclopedia with their pointy fingers of crime). Is that what you are saying? Horatio Snickers (talk) 17:29, 8 August 2013 (UTC)
Support Edit conflict* Many of Wikipedia's editors are editing from prison anyway, and many who are not currently may end up in prison in the future. I support not only the project to encourage jailbirds to edit Wikipedia, but also, should current Wikipedia editors find themselves in the nick, they ought to encourage their fellow prisoners to start editing as well. Horatio Snickers (talk) 20:50, 7 August 2013 (UTC)
I never meet a Wikipedian who edited out of prison in the 10 years I been active here. Stop throwing false accusations about the community, calling us criminals. Secretaccount21:02, 7 August 2013 (UTC)
Good anecdote. Unfortunately, that's a bit like saying "and everyone I asked agrees with me", and doesn't prove anything. And how many of the 120,000+ active registered users have you been talking to? And which ones of them did you enquire as to their current living conditions, availability of bread and water, etc? And given the nature of internet withdrawal in prisons, and the 41,000 mobile phones the British Prison service have removed from prisoners - I'd say it's likely that a good quantity of Wikipedians are editing from behind bars. Horatio Snickers (talk) 17:24, 8 August 2013 (UTC)
Support. Despite my joke above I just wanted to officially support this, mostly to offset some stupid comment(s) above. I have my doubts that this would work, but I see no reason to oppose it, nor to say prisoners don't have the necessary knowledge or resources to edit. Not all editing requires heavy research, and anyway, the proposal specifically regards minimum-security inmates who are generally in for white-collar crimes. They'll likely have both skills and access to research material. Anyone is already free to edit and any project to attract new editors is fine. Equazcion(talk) 21:23, 7 Aug 2013 (UTC)
Comment. Prisoners don't normally have internet access even though they are allowed computers. Too much risk of child and criminal interaction.--Canoe1967 (talk) 21:28, 7 August 2013 (UTC)
Support there are lots of open prisons, and also areas where supervised access is given. Most editors use on line resources for research so no change there. There are some really 'primitive' responses above. It would be a useful programme, suggest Jimbo or someone contacts a few national authorities to try and experiment or two ----SnowdedTALK22:07, 7 August 2013 (UTC)
While this seems interesting, it seems that there are 2 problems mentioned but not addressed above: if prisoners are usually highly limited in what they can access, won't they be unable to access most source documents? More importantly, doesn't it seem likely that Wikipedia itself would probably be pretty high on a "restricted" list, given that we house articles on subjects that are usually considered problematic, like hyperviolence and wanton sexuality (so to speak), including some fairly explicit images. Isn't it likely that Wikipedia is also blocked? Qwyrxian (talk) 22:17, 7 August 2013 (UTC)
There is a lot of editing that can be done with no need for source materials - fixing common grammatical errors, improving article structure, even reverting obvious vandalism. bd2412T22:20, 7 August 2013 (UTC)
Also, I am sure all prisons have a library (even if not a very good one), and one can imagine more literate inmates spending rather a lot of time there, since there is presumably little else to do. Too many existing Wikipedia editors get most of their material online and are just too busy or lazy or whatever to bother with real paper sources. Prisoners might be different there. Regarding filtering/blocking, I don't know, but Wikipedia seems to be very rarely blocked by common filters except in school settings, and even then relatively rarely. Even fairly aggressive filters that block things they think are "forums" or "social media" or "streaming media content", don't block Wikipedia. Rightly or wrongly, they seem to imagine it is a sober reference work. --Demiurge1000 (talk) 00:19, 8 August 2013 (UTC)
Doesn't seem like Wikipedia's mission. Look, I have nothing against prisoners editing, per se. If some willing souls want to organize something like this on their own, I'll wish them the best. But I'm uncomfortable with Wikipedia in the role of social reformer. Just doesn't seem very closely related to the goal of encyclopedia-writing. --Trovatore (talk) 22:30, 7 August 2013 (UTC)
I do not oppose this, but I think the best way would be on a prison-by-prison basis where a person who is an experienced editor starts a contribution program at a prison, a program that they are willing to manage in conjunction with prison management. I do not think this would work well without an individual managing an individual program. Personally, I would not be willing to do this. Another option would be to target half-way houses where people are trying to re-integrate into society. Another way of approaching this would be to introduce wikipedia editing into a computer literacy course within a prison or prison system. I am less pessimistic about edit quality than some; I think there is more a perception of inmates being mad dogs than is justified by reality, particularly those in prison for white collar crimes or possession of small amounts of marijuana or other controlled substances. --User:Ceyockey (talk to me) 22:40, 7 August 2013 (UTC)
Prisoners aren't nearly as bad as kids =D (seriously though). Equazcion(talk) 22:57, 7 Aug 2013 (UTC)
It depends, would this be more of a 21st century chain gang, cleaning up after vandals and so on, or would this be a drive to improve articles of interest to prisoners, like pushing pruno to featured status? Mark Arsten (talk) 23:03, 7 August 2013 (UTC)
Why presume that articles of interest to prisoners would be articles having to do with being in prison? The interests of prisoners are likely to be as diverse as the interests of people in general. bd2412T23:59, 7 August 2013 (UTC)
The rather well-educated Howard Marks, sentenced to 25 years for in his own opinion "transporting beneficial herbs from place to place", found that legal topics are of particular interest to prisoners in the USA. --Demiurge1000 (talk) 00:12, 8 August 2013 (UTC)
Oppose until it is made clear where exactly this is being proposed for. Just the USA? Or will we start with Latin American, African and Asian prisoners first? I might support if the proposal was a lot clearer about where and with what types of prisoners. Cannabis offenders editing cannabis articles is okay, IMO, but pedophiles editing pedophile articles isnt. Thanks, ♫ SqueakBoxtalkcontribs23:04, 7 August 2013 (UTC)
Statistically, there's every chance that some prisoners are already editors. The conversation above is full of amazing assumptions. Believe it or not, not all prisoners are paedophiles! Obviously conditions vary a lot from country to country and from prison to prison. I know from working briefly in the field that many prisoners have Internet access, and could be fully trusted to be responsible editors. Their crimes are irrelevant to that activity. HiLo48 (talk) 11:14, 8 August 2013 (UTC)
Isupport the general idea of a possible program like this; however, correctional institutions tend to have a strict monitoring policy for inmate contact with the outside world. What this would mean is that in order for correctional institutions to agree to this idea, we would have to give them oversight abilities. I'm opposed to giving oversight just on this basis, as it does not follow our protocol for such things. Technical 13 (talk) 11:45, 8 August 2013 (UTC)
"Oversight abilities" does not necessarily mean admin powers, as any Wikipedian can check the edits of any other Wikipedian. If a prisoner were to engage in bad behavior, authorities within the institution would have more direct means to address that than to block them. bd2412T12:28, 8 August 2013 (UTC)
Support. Without reading all of the above. It could be therapeutic for them as well as giving the project some fresh knowledge. I think they can order books into their libraries so they may be a better source than the net if they are restricted from online sources. They probably have more time than us as well. (inside joke)--Canoe1967 (talk) 12:08, 8 August 2013 (UTC)
This is an excellent point that I had not considered prior. Equazcion(talk) 17:43, 8 Aug 2013 (UTC)
I could see supporting an actual fleshed-put proposal to do this in a way that made sense. But what we have here is so hopelessly vague there is little point in even discussing it. Come back when you have some specifics regarding scope, funding, legality, the slightest idea of what this is trying to accomplish, etc. Beeblebrox (talk) 17:11, 8 August 2013 (UTC)
You could always discuss those things here. I think there's kinda a point. Just a thought. I mean, this isadiscussion, and if you could see supporting it in some form, maybe think about what would make you support it and offer those suggestions. Like, instead of forcing one guy to keep come back with the particular details that he hopes everyone will like. Like, discuss. Like, instead of treating everything here like a spoonfed yes/no proposition. Like, yeah. Just saying. I mean, yeah. Equazcion(talk) 17:37, 8 Aug 2013 (UTC)
I think Beeblebrox has a point. So far discussion is quite evenly split; a clearer idea of what to propose the WMF (because WMF has to be involved, I suppose, if we want to do this seriously) perhaps would help getting some consensus either way, clarifying general doubts of opposers and fleshing out what really supporters expect from this. I know little about the correctional system in English-speaking countries (or even mine, FWIW) but someone above said they have some experience, so perhaps may help sketching practical suggestions. In any case I suspect the first thing to do is to contact associations who assist inmates to inquiry about the general feasibility of this, what to expect and what not. --cyclopiaspeak!17:55, 8 August 2013 (UTC)
That wasn't his point and if it were then it's not a good one. His point was that the intentions are vague, while you're saying the feasibility should be determined first. The intentions are vague because it's just a simple ground-level idea presented for brainstorming, and feasibility efforts probably won't be taken seriously until some discussion of the general idea takes place. Proposals tend not to get off the ground because of this circular psychology. People expect details to be laid out before they say yes or no, when this page isn't necessarily for yes or no questions, but for brainstorming ("fleshing out") ideas as well. It's a systemic problem. Idea Lab was started in order to combat that tendency but it gets little participation because people would rather just vote on stuff they see here than actually participate in the development of ideas. In fact the existence of Idea Lab probably gives people the mistaken license to treat everything here like a vote. Equazcion(talk) 18:06, 8 Aug 2013 (UTC)
I for one neither support nor oppose. I just don't see evidence of anyone who truly understands the challenges you're talking about in this proposal. Please take this sincerely, I mean this 100%. Anyone who wants to take the lead in this should really seek out an existing community program at a nearby prison to volunteer. Someone with real life experience dealing with both inmates, and corrections bureaucrats would probably be needed to even develop a proper proposal.--159.221.32.10 (talk) 19:18, 8 August 2013 (UTC)
So basically, you support it. You just doubt it'll work. Equazcion(talk) 19:32, 8 Aug 2013 (UTC)
I'm fairly apathetic on Wikipedia these days. I do support the fact that if a sincere effort is put into this, those editors who actually try to get this going will get a valuable real world education. If someone really intends to pound the pavement to get this going they'll learn something. If someone just wants to create a wikiproject page, it'll just end up a dead page. I'm meerly curious to see if anyone really has the needed ambition for this.--159.221.32.10 (talk) 19:44, 8 August 2013 (UTC)
Just for kicks let's assume for the time being that we're trying to determine whether it's a potentially good or bad idea. Basically, you support it. You don't think anyone here will put in the necessary level of effort, but that aside, you support the idea. Equazcion(talk) 20:09, 8 Aug 2013 (UTC)
I wouldn't say I support it. I just don't oppose. In a social level I think there are far better ways one could support the rehabilitation of inmates then asking them to gnome wikipedia articles. and I think there would be fairly low interest on the inmate side.--159.221.32.10 (talk) 20:37, 8 August 2013 (UTC)
Support general concept: Many people serve time in prison and would benefit from doing research and writing on topics of interest; I doubt any incarcerated person could be more of a pain in the ass than the average internet troll already is! They could point to their positive work as part of their education and rehabilitation. Imagine what a Nelson Mandela could have done with internet access during his period of incarceration. Montanabw(talk)17:57, 8 August 2013 (UTC)
Future of Wikipedia
Support concept (or humor). Most inmates are illiterate, as reason they did not have high-paid jobs. Also, morale would already be low, with prison depression, so expect less mania than others. However, "Camp Cupcake" or other minimum-security facilities would likely have educated inmates. The restriction in source-access would be a good exercise in "parental controls" for Wikipedia. Of course, the whole issue of talking with underage users would certainly prevent prisoners from using Wikipedia, but it is an interesting concept. At least by discussing it, we could write more articles about prison life, prison art, and prison blues. -Wikid77 (talk) 19:01, 8 August 2013 (UTC)
I think a program aimed at minimum-security prisoners could yield literate participants. I would say again, just because people are in prison doesn't mean they lack knowledge of other areas of life. I don't think "talking with underage users" is a problem, since we ourselves don't really know which users are underage, and there are plenty of people who are in prison for things that having absolutely nothing to do with dealings with minors. bd2412T23:55, 8 August 2013 (UTC)
Even in many western democracies, prisoners can be very much subject to the whims of the guards and or prison administration. What safe guards would there be to protect us from a figure of authority at the prison from having the prisoners push a particular point of view or otherwise violate NPOV? Monty84519:50, 8 August 2013 (UTC)
The same safeguards that are in place to protect us from any figure of authority having the inhabitants of any institution push a particular POV. Teachers, parents, churches, corporations, Chinese labor camps, etc. Equazcion(talk) 20:09, 8 Aug 2013 (UTC)
Neutral but possible suggestions for individuals: I don't think that there is really any real way for Wikipedia or the Wikimedia foundation to support such an effort, nor would I think it could provide a measurable benefit to prisoners. I would recommend that anybody who wants to support the education and rehabilitation of people in prison to look into one of many programs such as Books Through Bars and Jail Guitar Doors. I especially recommend looking into the actual website for Books Through Bars because they have a list of other similar programs all over the places, as well as information on how to start your own similar program. There are also (very few) things like the Bard Prison Initiative which "is one of the only college degree granting programs available in U.S. prisons." I saw a documentary or news program showing the Bard Prison Initiative in action a while back and it appeared to be a VERY good program to me. I would implore that anybody interested in these topics who are either staff or students at any of our fine educational institutions look into starting a similar program and/or at very least a Books Through Bars type program. Clearly there are ample resources for unwanted educational and reading materials and educational programs at each of our institutions that can support such efforts. In addition, people at companies may be able to further support book programs simply by diverting things like Tyvek envelopes from incoming mail for reuse by the book programs for shipping purposes. Centerone (talk) 23:15, 8 August 2013 (UTC)
In addition, it's obvious that the above programs' Wikipedia pages need some work. If you feel these things are important, then help with editing the pages and other pages in these and similar categories. The better developed such pages are, the more people may be able to find good information out about such programs, and possibly get involved with and/or replicate them. Centerone (talk) 23:32, 8 August 2013 (UTC)
Very strong oppose with some clarity as to why this idea can never be implemented I don't think the OP has taken enough time to research this proposal and the impact it could have on the inmate population and Wikipedia itself. I asked a correctional officer for their input on this and their immediate reaction had a great deal of validity. Inmates (even in minimum security prisons) use any and all routes to continue misbehavior. For this reason the inmate population in the state of California does not have access to the internet. Communication between and from inmates is highly controlled. Cell phones are confiscated regularly and in some cases, uniformed and non uniformed staff have been arrested for smuggling in these devices. This just creates an issue that puts too many individuals at risk. It is also impossible to implement if the Department of Corrections already has a policy against inmates accessing the internet.--MarkJust ask!WERTEADR/N00:21, 9 August 2013 (UTC)
Of course, one benefit that Wikipedia has over many other potential internet venues is that it is very easy to see every word that a Wikipedian is putting on the site. bd2412T01:33, 9 August 2013 (UTC)
That is not entirely true. The idea also would never be allowed by corrections for the very reason that it gives inmates access to thousands of e-mails to others for whatever reason they choose. You really haven't thought this through, have you?--MarkJust ask!WERTEADR/N01:38, 9 August 2013 (UTC)
So, then what you're proposing is a program that would need someone to design and manage it, someone to work with developing the program, find and work with the prisons, people to work with the inmates, people to train those who don't know how to use them, how to use computers, how to edit wikipedia, how to do research that doesn't violate policies, how to work with other editors, then editors would need to vet all their work, prison staff to monitor all their communications, prison staff to maintain all the computers, and... what would be the benefit TO THE INMATES for this? Would they earn money? Would they get an education that could help them when they get out of prison? Would editing wikipedia somehow help them rehabilitate so that when they get out of prison they don't reoffend? Would they enjoy this so much that they would want to do it during their free time? And who or what program or organization would pay for all this additional staff? This comes across to me like "hey, look, there are all these idle people in prison, let's use them as slave labour to make wikipedia better!" Centerone (talk) 02:14, 9 August 2013 (UTC)
I don't think he was suggesting slave labor. Besides...prisoners are allowed to work in prisons. Everything else you said was pretty much on the nose...but you forgot the hurdle of overcoming the fact that most US states don't even allow internet access for prisoners. Don't know about the UK.--MarkJust ask!WERTEADR/N02:20, 9 August 2013 (UTC)
Obviously, we are not going to march into prisons and demand they give all of their inmates internet access. However, to the extent that there are facilities where some inmates are allowed internet access (a condition which already suggests that said inmates have earned a certain amount of trust), I think learning to work productively in the collaborative environment of Wikipedia would offer a benefit for those who are interested in trying it out. I do not envision Wikipedians bearing any cost other than training people who are already working with prisoners on how to edit Wikipedia, and offering the same online project support that we already offer to many other kinds of institutions, such as schools and museums. As for the question, "Would they enjoy this so much that they would want to do it during their free time?" - well, isn't that why all of us edit? bd2412T02:45, 9 August 2013 (UTC)
If you don't understand the logistics (and clearly you do not) it isn't the best idea to propose something that has a snowballs chance. I hate to tell you this, but consensus only allows for decisions on Wikipedia. Just agreeing to allow this does not mean a single state run corrections facility would ever approve it. There are too many variables. It also seems you are not to clear on how many institutions allow internet access. Perhaps that is what we should be looking at, as it seems to me that this proposal hinges on that alone.--MarkJust ask!WERTEADR/N02:54, 9 August 2013 (UTC)
Actually, we have an article - Internet in prisons - which indicates that some U.S. federal prisoners are getting limited internet access. Just to get a sense of your base of knowledge, may I ask, Mark, how many people have you trained in editing Wikipedia? bd2412T02:59, 9 August 2013 (UTC)
(edit conflict) How many inmates have you trained? Yeah, no, this isn't about me or you. If your proposal cannot stand on its own with out having to go the direction of personalizing it, then you are not standing on firm ground. As it turns out: "nearly all states prohibit Internet use by inmates. Limiting technology based access to educational opportunities". Even Federal prisons limit access through something called the Trust Fund Limited Inmate Computer System (TRULINCS), which is to only access e-mail messages alone. What about the UK? Anyone?--MarkJust ask!WERTEADR/N03:06, 9 August 2013 (UTC)
One of the reasons why we have this proposal space at all is so that ideas can be put out there, to be addressed by those who have the knowledge to do so. It is unproductive to respond to ideas with repeated snarky gibes like "You really haven't thought this through, have you?" Please try to make your points without resorting to such snideness. Now, to answer your question, as a law student I fulfilled my pro bono requirement by assisting convicted felons seeking the restoration of their civil rights. These were not inmates, but they were people who had served prison sentences, sometimes lengthy ones. I talked them through the process and the paperwork. Some were barely literate, and some were well-read and well-spoken. I have also, as it happens, trained institutional groups in editing Wikipedia, including the archivists of the Smithsonian Institution. As a former law clerk of the United States Court of Appeals for the Federal Circuit, I obtained clearances for Wikipedia to use resources of the Federal Judicial Center and the General Services Administration. I know how to train editors, and how to train people to train editors. I also know how to deal with federal bureaucracies. That's what I bring to the table here. That, and an idea. I am not surprised that there are barriers to bringing about something like this. If I had the attitude that potential difficulties should prevent things from going forward, I probably wouldn't have taken up editing Wikipedia at all. Indeed, if the hurdles were all that mattered, Wikipedia wouldn't exist at all. bd2412T03:33, 9 August 2013 (UTC)
If you can't take the heat, get out of the kitchen. ""You really haven't thought this through, have you?"" is not uncivil. It is in fact clear that you have not done your research before proposing something that is nearly impossible. And after all that prose above, plainly you have never trained an inmate. But if you are thinking I am now going to give you personal information here you are sadly mistaken. For all of your comments above, it is clear you are just blowing me off as someone who does not have "the knowledge" to address this proposal. I believe that I have demonstrated I do. In fact, I believe it is you who lack the knowledge to have any made this proposal. It sounded good so you made the proposal, but a reading of your posts makes it clear you were not prepared to answer very basic questions in regards to internet access in prisons. Great about all your experience, and even greater that you take such an approach to institutions sharing Wikipedia, but you cannot seriously be comparing the Smithsonian Institute with the US prison system. If so, you may want to look further into some of the issues I have raised.--MarkJust ask!WERTEADR/N03:48, 9 August 2013 (UTC)
I'm not saying your gibes are uncivil (I was going to, but I withdrew it); they are snarky and unnecessary. I am, however, grateful for the issues having been raised, and I will look into them further. bd2412T03:55, 9 August 2013 (UTC)
Comment. We also wish to think about protecting our IP editors. They are more vulnerable. We should make sure the institutions are aware that editors do get in heated discussions here. We could even have a custom signature for inmates so that editors are aware of this in discussions.--Canoe1967 (talk) 05:29, 9 August 2013 (UTC)
Comment - I'm currently neutral, mainly because I don't understand why we should encourage the participation of prisoners over any other sector of society. The proposer suggests that one of their attributes is the enormous amount of time they have to spare. Have they? Or do prisoners have to spend as much time working and doing chores as the rest of us?--Ykraps (talk) 18:17, 9 August 2013 (UTC)
Excellent headline grabbing idea that is inherently pointless. If folk in prison have internet access and want to play here then they will. If not then not. Good thinking behind the PR element. We can do it without lifting a finger because we do it already. This is zero cost PR! FiddleFaddle06:29, 9 August 2013 (UTC)
Or potentially infinitely expensive PR (from when we have to hire a PR firm to clean up the messes made when someone gets a bee in their bonnet that we're facilitating "Criminals" interacting with minors. As I said before, this is best tabled from the English Wikipedia and opened at the WikiMedia Foundation. OP is strongly encouraged to end this charade (or very cleverly disguised Orange Is the New Black social media advertisment) and move on. Hasteur (talk) 16:32, 9 August 2013 (UTC)
I am "strongly encouraged" by the fact that support for the proposition clearly outweighs opposition to it. I will, indeed, take this proposal up with the Foundation. Cheers! bd2412T17:02, 9 August 2013 (UTC)
Oppose Short of suddenly taking advertisements, or announcing a merger with Wikileaks, I can think of no possible idea that would make more destructive inroads on our public reputation than this one. --Orange Mike | Talk17:56, 9 August 2013 (UTC)
PR and those afraid of it tend to hinder evolution so. Equazcion(talk) 00:35, 10 Aug 2013 (UTC)
Strong Oppose Strongly As per OrangeMike and -Mark J.It will be a disaster for our public reputation. Prisoners will be under surveillance in Jails and there editing or any internet access is most likely is monitored(Most Prisons do not allow internet Access to there Prisoners).Whether they can edit freely is doubtful even if allowed .But no one has anything if any Prisoner is allowed and wishes to edit Wikipedia on his own accord. He can edit just as any other editor and is judged only based on his edits. But feel Wikipedia or Foundation should not get involved into this.Pharaoh of the Wizards (talk) 18:19, 9 August 2013 (UTC)
oppose. Nothing stops people in prison editing now, if they have the hardware, the access to WP, the access to sources, the time, the motivation. If they don't then I don't see what we could do to help. Or if we could help any such resources (including editor time) could be far more easily, cheaply and less contentiously used elsewhere – in schools for example.--JohnBlackburnewordsdeeds19:44, 9 August 2013 (UTC)
Oppose Colbert/Onion/Kafkaesque proposal that will lead to nothing except holding Wikipedia out as a laughingstock to the world. While incarceration is not an absolute bar to participation, this is hardly something that should be publicly encouraged. DavidLeighEllis (talk) 23:44, 9 August 2013 (UTC)
Support To start with, we should set up a speech recognition program so that if Wikipedians wish to use their "one phone call" to add some new information to the police department's article, they will be able to do so conveniently and quickly. Shii(tock)20:38, 10 August 2013 (UTC)
"I got my one phone call! Hello, Wikipediaphone? Edit article Springfield Police Department (Illinois). Paragraph 1 ... Insert new line. Text. 'Springfield are pigs' Save!!!" *click* Shii(tock)21:00, 10 August 2013 (UTC)
In light of the conversation above, I agree with the commentators who have suggested tabling this proposal; I will withdraw until I can gather more information on the practical aspects of such a program, and can offer a proposal that answers all of the questions that have been raised in this discussion. Cheers! bd2412T21:01, 10 August 2013 (UTC)
Your rationale was that prisoners "have plenty of time on their hands". That would also apply to sailors deployed at sea, and folks in critical care facilities, but all of these have substantial shortcomings. If you want to identify possible editors you should probably focus on finding individuals with time, not classes of people. In case anyone is interested I count 13 opposers (some "strong") and nine supporters (but two likely only sarcastically). ~ J. Johnson (JJ) (talk) 22:32, 10 August 2013 (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.
Desysop / reconfirmation RfA proposal
First of all, it should be clear that while some 50 people participated, the number of people that did participate is in no way large enough to provide a consensus to create a mechanism for de-admining. WP:CDARFC had more than 400 participants. Further, this proposal saw a number of amendments, a few of which got significant traction. Thus, many of the supports here were for different things and, in a number of cases, it's not 100% clear what some editors were supporting. That said, the supports had about a two-thirds majority which is certainly strong enough that the proposal shouldn't be shut down at this stage.
As such, I'm going to suggest that 28bytes take the community input here and work with others as he sees fit (though especially with Bbb23) to create a formal proposal for an up/down vote. Once the proposal is ready, it should be advertised at least as widely as WP:CDARFC was advertised and a standard RfC should be held. I'd further urge that three closers be found (advertising at WP:AN) so that the RfC is closed by the majority of the triumvirate rather than a single editor. It would be best if this triumvirate was found before the RfC was officially started.
Finally, I'd urge 28bytes (and others) to read the issues raised by the opposers and attempt to address their issues where possible. Hobit (talk) 21:58, 16 August 2013 (UTC)
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.
I've seen the discussion on the bureaucrats' noticeboard regarding a bureaucrat-led desysopping process, and I thought I would take a break from my break to offer a concrete proposal that I hope addresses some of the frustrations the community has about administrator accountability without encouraging an "open season" on administrators who have to make difficult and sometimes unpopular decisions.
Here is my idea for a 'crat-led "simple desysop" process:
Any active bureaucrat can select an administrator for a reconfirmation RfA if they are persuaded that a "vote of confidence" by the community is needed to ensure that the administrator retains the trust of their fellow editors.
If selected, the administrator will be asked to run a reconfirmation RfA within one month. If they decline to do so, a bureaucrat will remove their sysop flag, which they may regain in the future through a successful RfA.
At the reconfirmation RfA, the selected administrator will need to gain the support of a simple majority of their colleagues, although the closing bureaucrat will be given discretion to discount bad faith supports or opposes. If the reconfirmation RfA is unsuccessful, the closing bureaucrat will remove the administrator's sysop flag.
If any community member (including the administrator in question) objects to the close, they may appeal to ArbCom, who will decide whether the close was a reasonable exercise of bureaucrat discretion.
To ensure the integrity of the process, these safeguards would be included:
An administrator may only be selected for a reconfirmation RfA once. If they pass the reconfirmation RfA, any future concerns about that admin's conduct must be handled through the existing processes (RfC/user and ArbCom.)
Each individual bureaucrat may only make 3 reconfirmation selections in a calendar year.
The bureaucrat who selects a candidate for reconfirmation cannot close that reconfirmation RfA.
If no bureaucrat feels a reconfirmation RfA is warranted, the community retains the right to use the existing processes (RfC/user and ArbCom) to address administrator conduct.
If the bureaucrat corps in general is slow to select administrators for reconfirmation, the community is free to nominate for bureaucratship (via the existing RfB process) any editors they feel would be more (or less) willing to select administrators for reconfirmation RfAs.
I think this proposal strikes the right balance between (on one hand) the community's legitimate desire to hold administrators accountable for poor conduct or decision-making without long, tedious ArbCom cases and (on the other hand) administrators' legitimate desire not to be subject to constant, frivolous "recall"-like processes that sap everyone's time and energy and encourage drama and pitchforks. 28bytes (talk) 15:53, 13 July 2013 (UTC)
Discussion
Questions - 1. Why does your proposal place the power to call a no confidence vote in a single Crat (seems pretty powerful, as is, as it will be essentially a no confidence vote by that Crat that starts the process)?
2. Are there standard criteria for the each Crat to apply in calling the vote?
My thinking was there should be some quick way of getting the process started, and that bureaucrats would not tend to make such selections frivolously, especially as they would only be able to make three selections per year (safeguard #2.) And if they do make a frivolous selection, the community gets the chance to say so by retaining the selected administrator in the reconfirmation RfA; that administrator would then be insulated against any additional selections for the rest of his or her career (safeguard #1). But as I commented to AlanBbb23 below, a two-crat trigger sounds like a good compromise. 28bytes (talk) 16:47, 13 July 2013 (UTC)
Thanks I see your cmt to Bbb23. Please cmt on criteria? The last ques is just something you are bound to have to deal with, but I am really interested in criteria? Alanscottwalker (talk) 16:55, 13 July 2013 (UTC)
I didn't have any formal criteria in mind; rather, the editor(s) who felt an administrator should run for reconfirmation would need to make their case for why the administrator is not meeting the standards the community expects. Reasons could be a refusal to answer reasonable queries about their admin actions (per WP:ADMINACCT), a large number of admin actions that were overturned by the community (e.g. poor blocks), noticeable WP:BATTLEGROUND behavior (e.g. picking fights with other editors, nursing grudges, etc.) 28bytes (talk) 17:25, 13 July 2013 (UTC)
Strong Support this is best proposal yet and we've simply got to do something about the sordid mess we're in. Hopefully 28bytes can come up with an RFA equivalent. PumpkinSkytalk16:11, 13 July 2013 (UTC)
Comment. I agree with PS that this is best proposal yet, or at least the best I've seen. However, I'll reserve support or opposition until I decide whether any proposal is needed, whether I can support the final proposal, and whether the change will eliminate the rancor among some members of the community. Here are my tentative comments:
Along the lines of what Alan said, I would prefer two crats select an admin for reconfirmation, not just one. There wouldn't have to be a consensus among the crats, just a minimum of two who agree it's needed.
Only auto-confirmed users may vote at a reconfirmation RfA.
If an administrator objects to a negative close and they choose to appeal to ArbCom, their sysop flag will not be removed pending a decision by ArbCom, and ArbCom will handle the appeal on an expedited basis.
A crat may select for reconfirmation only two admins per year, not three.
Number 5 in the second box is unnecessary and should be struck.
Those all seem like reasonable amendments to me. The two-crat rule in particular makes sense, as it's important to strike a balance between not concentrating power in the hands of one person vs. not devolving into a death-by-committee situation where nothing gets ever done. 28bytes (talk) 16:47, 13 July 2013 (UTC)
Support preferably as modified by Bbb23. I would add to it that the same two crats can act together only once in a calendar year. Normal rules of conflict of interest to apply as regards the nominating crats and the admin. And no admin shall be subject to this within a year of election, or within six months of being subjected to action by ArbCom (time to find feet, time to reform).--Wehwalt (talk) 16:34, 13 July 2013 (UTC)
Support with two Crats modification. Maybe some minor tweaks to how many times, how many times the two can act together, etc. Needs more thought, but this is a reasonable basis to start a change. I strongly support the simple majority rule, which I think will compensate for previously blocked "haters" piling on. Hopefully this would be a rare event, but just having it available can restore faith in the community re: admin accountability. Dennis Brown | 2¢ | WER16:56, 13 July 2013 (UTC)
Support. At this point, I do not see how this proposal can harm if accepted, however some modifications are desirable (Bbb23's suggestions are a good starting point).--Ymblanter (talk) 17:06, 13 July 2013 (UTC)
Support: There needs to be an organized and logical system to do this, as opposed to random mobs with pitchforks and torches. Montanabw(talk)00:41, 14 July 2013 (UTC)
Oppose this proposal isn't really much different from the failed WP:CDA proposal from a few years ago, except the acceptance requirement has been changed from 10 editors in good standing to one bureaucrat, and the success threshold is much lower. Bureaucrats aren't selected for this situation, of course. The problem with reverse-RfA desysopping proposals is that admins who do work in controversial areas tend to make enemies, even if the work they do is great, and that those enemies will vote against them in an RfA. This will, in turn, reduce the number of admins prepared to get involved in controversial areas, exacerbating a problem we have already. The fact that this proposal has come from angry protests over a block of an editor who has plenty of sympathisers prepared to make noise on their behalf is not encouraging in this respect, as those sympathisers would doubtless love to use this process to get revenge on the blocking admin. RfA is not generally considered to do a very good job of selecting new admins, so it's difficult to justify using it on existing ones, especially ones who have done something controversial recently. The proposal seems to require that only admins can vote in recall RfAs, or that only their votes will be counted, which isn't going to inspire much confidence in the results. Hut 8.518:16, 13 July 2013 (UTC)
I have the following experience which happened on the Russian Wikipedia several years ago. I passed RFA with smth like 92% support, then started to do dirty jobs like closing old AfDs where there was no consensus or dealing with disrupting users with a large contribution in the article space and many vocal friends; I have also served half a year as an arb. After a year, I voluntarily stood a reconfirmation vote and was reconfirmed with 97% support. I dom not think anybody who is doing their job properly should be afraid of reconfirmation. I also do not think someone who can not pass reconfirmation (meaning is not able to secure 70% supports, or 50% as originally proposed) is fit to act as admin, because it means their admin actions have no support and are not perceived as legitimate.--Ymblanter (talk) 07:32, 15 July 2013 (UTC)
LoL… ru.wikipedia is notorious for its contempt to any written policy and a government based on social hierarchy and servility, at least it was notorious for these vices when Ymblanter’s previous persona was active. I do not think such comparison of communities has any merit. Incnis Mrsi (talk) 09:00, 15 July 2013 (UTC)
Experiences on different wikis don't necessarily translate, as they will have different communities, cultures and standards. The experience of the few people who have chosen to have reconfirmation RfAs on the English Wikipedia has been rather worse than yours. I am aware of the following that could reasonably be called reconfirmation RfAs: Wikipedia:Requests for adminship/SarekOfVulcan 2 (72% support down from 87% in their first RfA), Wikipedia:Requests for adminship/HJ Mitchell 3 (95% up from 85%), Wikipedia:Requests for adminship/Herostratus 2 (62% down from 79% and unsuccessful), Wikipedia:Requests for adminship/Crzrussian 2 (86% down from 99%), Wikipedia:Requests for adminship/^demon 3 (61% down from 99%). All but one lot some support. I recommend reading the closing bureaucrat's rationale in the ^demon RfA justifying the use of a lower threshold. The closure of an RfA cannot ever be anything more than a reflection of the opinion of the people who participated in it, which is going to disproportionally include people with strong opinions of the candidate, whether positive or negative. As I said above this proposal grew out of a thread about getting revenge for a controversial block, so the idea that it won't be used to further grudges is not tenable. Hut 8.514:17, 15 July 2013 (UTC)
Support, with the two-crat threshold for the initiation of the process. In response to Hut 8.5, I would expect the two bureaucrats to use good judgement -- and not call for a desysopping discussion solely on the basis of unpopular actions in controversial areas. --Orlady (talk) 18:48, 13 July 2013 (UTC)
The criterion for a bureaucrat to open a reconfirmation doesn't say about what the admin is supposed to have done, only that there is some perceived need for a reconfirmation. Hut 8.519:20, 13 July 2013 (UTC)
Oppose Though a possible addition, the entire RFA process from nomination to desysop must be dealt with as a single entity (✉→BWilkins←✎) 23:05, 13 July 2013 (UTC)
Proposed tweaks
I would instead of one bureaucrat a maximum of three times, say three crats acting together. Those crats cannot act in combination more than once in a calendar year but may join with other combinations of crats. Normal rules of conflict of interest apply.
Crats who have not used their powers significantly (either closed an RfA or done some quantity of other work) in a given time period may not act at all, let's say one year.
No admin shall be subject to this within one year of election, or within six months after being the subject of action by the Arbitration Committee (i.e., no double jeopardy). PumpkinSkytalk18:44, 13 July 2013 (UTC)
What will be the standing procedure for attempting to "persuade a bureaucrat that a 'vote of confidence' by the community is needed"? :)John Cline (talk) 19:05, 13 July 2013 (UTC)
I have been saying for years that Community de-adminship is a must-have feature, and this is an interesting idea. What strikes me as notable is the nomination process by bureaucrats, and the fact that 'crats were not elected to do this type of work and have answered no questions about it, etc. Since the role of the bureaucrat or bureaucrats is larger than it was in the failed 2010 Cda proposal, and since I have not seen any of that membergroup go on record as for or against such responsibilities, I will poll them on their board. If they aren't in favor, this proposal is moot. Jusdafax21:35, 13 July 2013 (UTC)
A question and modification: First, do you propose any sort of unit of measure to determine if a reconfirmation RFA is warranted, or is this pretty much based on the whims of the one or two crats? Second, and in the interest of protecting admins from harassment via this process, I would suggest that no admin should be forced through this process more than once in a specific and long period of time - I'd say three years or even longer, or even only once for any admin. Nobody should be forced to run the gauntlet repeatedly until certain elements bully their hated admin off Wikipedia. Any further concerns within the 'protected' time frame should be directed to arbcom.Resolute23:59, 13 July 2013 (UTC)
Additionally, how do you expect the reconfirmation vote to work? Since he individual in the prisoner's box is already an admin, it is the votes opposing continued adminship that matters, rather than overall support. Would be be a simply 50%+1 vote?Resolute00:05, 14 July 2013 (UTC)
Striking most as these concerns were already addressed in the proposal. I read it, but my utter failure to have it stick in my mind was just pointed out to me. Resolute02:20, 14 July 2013 (UTC)
An important point has been raised at the 'crat noticeboard in the comment section of the poll I have added. Not only should the 'crats approve this proposal to expand their Bureaucrat rights, the Wikipedia community at large should be asked to approve this concept as well, which I imagine would involve a Wiki-wide Rfc. Jusdafax01:29, 14 July 2013 (UTC)
That's a good idea, Jusdafax, and I expect that will be the next step, after people are done finalising the wording and have confirmed the 'crats are interested in taking on the task. -- Diannaa (talk) 02:16, 14 July 2013 (UTC)
Support. Anything to change the current system. Too many entrenched power players. Minor tweak would be to make the revote same percentage as normal. But I'll take anything...TCO (talk) 05:35, 14 July 2013 (UTC)
Support. A good admin-removal system is something Wikipedia has been oddly lacking for forever. This might not be perfect, but it is a good starting point that could be refined to smooth things out as we gain experience with it. —Scott5114↗[EXACT CHANGE ONLY]08:46, 14 July 2013 (UTC)
Support, preferring the reconfirmation threshold being 70% +1 support, the minimum threshold for an RfA to pass. Non-English Wikipedia often select administrators with time limits, e.g. 2-3 years, and I would favor e.g. 4 years as a time limit. I often see weird decisions inflicted on the community by administratorsmade in 2007-2008. Kiefer.Wolfowitz08:51, 14 July 2013 (UTC)
Currently there is no threshold "percentage of support, but as a general descriptive rule of thumb most requests above ~80% approval pass and most below ~70% fail." I imagine the same would be for reconfirmation, rather than having two slightly different processes? ·addshore·talk to me!11:37, 15 July 2013 (UTC)
Oppose Bureaucrats have been selected for their ability to read and follow consensus in decisions, and for generally being uncontroversial, I don't see why they would be granted such an ability over any other grouping. Bureaucrats have not been selected on the basis of their ability to pick admin requiring review, and they do not necessarily encounter most admins. If this was enabled, when there is perceived bad admin decision, everyone will race to the bureaucrats to try and badger them into a review, increasing drama, IRWolfie- (talk) 09:24, 14 July 2013 (UTC)
Support Some sort of recall process is necessary. Although some sort of amendment might be appropriate, I'd rather see this get through and then be tweaked than get the whole thing prevented because of focus on details.--Peter cohen (talk) 11:37, 14 July 2013 (UTC)
Support Good work from 28bytes on coming up with a carefully considered desysopping procedure. I'm happy with this proposal; if any changes need to be made they can be discussed and implemented accordingly. I've never been convinced by arguments stating that the "bureaucrats weren't selected to do this"; the role of bureaucrat can change, just as the role of admin has changed over the years...adminship has changed since I became one, with there being technical abilities that admins have now that they didn't have when I started (for example, the ability to hand out userrights); using that argument, only people who have been made admins in the past year have been selected for everything the position is capable of currently. Let's give this a try. Acalamari11:40, 14 July 2013 (UTC)
Strong oppose. I oppose every proposal which gives the community the authority to remove an administrator. The community (or, better, a subset thereof) have repeatedly demonstrated they are unable to ever let go of grudges. And admins sometimes need to make hard calls which disappoint some people. So, if one of these proposals ever passed, we'd have a lot people, those who feel an admin was ever unfair to them or their friends, who'd jump at the opportunity to get back at him (we're already seeing it: whenever an admin's action is questioned on a noticeboard, there is always someone crying "let's desysop him") and we'd end up with sysops doing what's expedient instead of what's right. SalvioLet's talk about it!11:57, 14 July 2013 (UTC)
Strong support: (and I say that without any block history) - Any further changes to give better results can be modified over time -- Nbound (talk) 12:34, 14 July 2013 (UTC)
Support - I've never been fond of the admin for life policy. This seem like a solid proposal to address some of the community's lack of confidence in ARBCOM, and to enforce admins' accountability to the community and the project. I have a great deal of respect for some of the users in the oppose column, and for the difficult and thankless jobs that our volunteer admins undertake. However, I firmly believe that the status quo really needs to go. If those opposing have a better, more workable solution, let them bring it forward. I also want to add, that I agree with the second part of Kiefer.Wolfowitz's comment. I am strongly in favor of terms, with a reconfirmation vote needed to extend those terms. - MrX15:15, 14 July 2013 (UTC), 15:20, 14 July 2013 (UTC)
Strong support - This seems like a very reasonable, workable proposal with appropriate checks and balances. Per several others above, including Bbb. Keilana|Parlez ici17:02, 14 July 2013 (UTC)
Conditional support - This might break the logjam that makes being an Admin something of an embarrassment for the level-headed, but it would probably be a good idea to term-limit the bureaucrats (requiring re-election every 2-3 years or so) to prevent this from becoming yet another cabal for everyone to complain about. I also think having more than one 'crat sign on (publicly) to each challenge would be wise. --SB_Johnny | talk✌ 18:16, 14 July 2013 (UTC)
While i have in the past supported a community-based process for desysopping, I'm not really comfortable with repurposing the crats as arbiters who issue orders to admins demanding that they must go through such a process or lose their adminship. Traditionally the duties of a crat have not really involved bold decision making, quite the opposite. The job was given this title specifically to make it seem boring and unglamorous, which it undoubtedly is. They are expected to act only after a clear consensus has been established, not to open procedures against members of the community, admin or no. Frankly I'd rather see it come from the other direction, (the broader community) this just seems like it would reinforce the idea that crats "outrank" admins in some way when really they are just a subset of admins who do a few particular tasks that are rather dry and boring in almost all cases. And what if there was concern about <gasp> one of the crats themselves? What then? There are only what, thirty or so of them? Beeblebrox (talk) 18:29, 14 July 2013 (UTC)
Oppose per Salvio, Hut 8.5 and Beeblebrox. The benefits of the proposal, original or modified, seem to be outweighed by its disadvantages. De728631 (talk) 18:41, 14 July 2013 (UTC)
Question - I'm inclined to support, but concerned about process step 4 (first box). Absent the exceedingly unlikely case of 100% support, virtually all decisions will be appealed to ArbCom. If if passes with say, 90% support, then there are ten to twenty who opposed who might decide to appeal to ArbCom. What do they have to lose? If it fails on a close call, the admin in question might appeal, but that's acceptable to me. If it fails miserably, say only 10% support, and the admin accepts it, there may still be someone who deices to appeal to ArbCom. What's there to lose? I suggest:
If the admin loses the reconfirmation vote, and accepts the decisions, no one should be able to appeal.
If the admin wins the reconfirmation vote, no appeal would be allowed (except possibly for procedural errors, such as conducting the poll without notice)
If both of these tweaks are accepted, then my next request can be ignored, but if one or both are rejected, I request clarification of the term "Community member". Does it include IPs? Does it include editor ineligible to vote in the reconfirmation poll? Does it include editors eligible to vote, but who did not vote? Does it allow an editor to support reconfirmation, then request ArbCom review of a passing close? Finally, does ArbCom have to take this on, or is it simply a proposed case they can accept or reject?--SPhilbrick(Talk)20:10, 14 July 2013 (UTC)
Support With or without the tweaks. Admins need to be more accountable, and this seems like a good way to handle it. We have 35 crats, which means that almost 100 admins can be reconfirmed each year, if needed. This leaves room to cover any problematic case that should arise, and ArbCom could deal with other conduct matters. As I said sometime before, neither Jimbo nor ArbCom are needed to desysop people. Wikidata does it the community-way, the Spanish Wikipedia does it the community way, and they work. No frivolous requests are made, and when they are, the community shows that the notion of justice is still present, and no sysop gets their tools taken if there isn't a good reason. — ΛΧΣ2103:36, 15 July 2013 (UTC)
After much reflection, oppose. I think we call this a "no-win" scenario. I agree that the scenario Hut 8.5 mentions is likely - admins will be less likely to do the "dirty work" because they would fear getting voted down by people that they've blocked/topic banned/etc, thus less would get done. But I also see the need for the community to be able to handle things on their own. A win-win scenario is something I don't have any ideas on, I'm afraid. StevenZhangHelp resolve disputes!04:09, 15 July 2013 (UTC)
Support in principle, with some reservations about the details. I'd prefer Bbb23's revised procedure as of 16:31, 13 July 2013, as well as PumpkinSky's and SPhilbrick's suggestions. -- King of♥♦♣ ♠ 05:02, 15 July 2013 (UTC)
Reservations. In principle, there should be an easy method to force RfA reconfirmation (easy in terms of process, not threshold). Putting the question back into the hands of the community in a formal short (week) process is good. Less concerned about the checks on bureaucrats doing this, more concerned that bureaucrats will be too hesitant. Reservations because I think that the real issues is applications of Blocks and Unblocks, and because we should first have a robust forum of Block/Unblock review. This process is likely to lead to complicated blocks/unblocks being reviewed in terms to the person performing the action, where is would be preferable to first examine community opinion on the block/unblock action. Current noticeboards are not suitable locations to conduct community review of anything. I recommend something more like DRV. Note that at DRV, few admins are repeatedly reviewed, that it has an excellent function of encouraging behavioral refinement. If admins learned to block/unblock better, the outcome would be far better than desysopping a few of the more adventurous admins. --SmokeyJoe (talk) 05:43, 15 July 2013 (UTC)
Oppose per Gatoclass, likely to lead to harassment of bureaucrats. Also that engaging in this means the bureaucrat will put his reputation on the line. Instead, prefer that a forced reconfirmation RfA should require a RFC/U. Perhaps authorise RfC/U closers to determine whether a RfA reconfirmation is required. --SmokeyJoe (talk) 22:47, 16 July 2013 (UTC)
Sorry, no. Like most such proposals that rely heavily on bureaucrat discretion, this one is problematic because of the damage it is likely to do to the 'crats and their ability to carry out their current responsibilities. While in theory the three-nominations-per-year cap is designed to suggest a restraint on overuse of this procedure, it is not the steep speed bump that we might hope. There are 36 bureaucrats on enwiki; that's enough to nominate 108 admins for this process every year, which is just over twice a week. (Even if we arbitrarily declare half of them totally inactive, we're left with a weekly circus.) Every borderline-controversial admin action will have to be debated twice: once on AN(/I), and again on the bureaucrats' noticeboard. Much of the latter discussion will probably take the form of lobbying for any 'crats with remaining nomination capacity to take the case. Come to think of it, there will probably be a lot of off-noticeboard and off-wiki lobbying-bordering-on-harrassment of 'crats. The 'crats – who until now have generally performed their specific roles with a minimum of fuss and with wide community approval – will of necessity be obliged to play politics; like the ArbCom they will be abused during and after every proposed case, accepted or not.
As well, we have the problem of setting up the 'crats to (willingly and wittingly or otherwise) usurp a responsibility of ArbCom. We will be putting unelected, non-term-limited functionaries in the place of ArbCom, and we will be empowering them to make these decisions as individuals (or twosomes, depending on the variant of this proposal) rather than seeking even a bare majority of their colleagues' approval. The test to be applied in any ArbCom review is not whether or not the resolution imposed was the best or most reasonable response, but only whether it meets the much broader, lower threshold of "a reasonable exercise of bureaucrat discretion". Since the process can only produce a yes/no, desysop/not decision, there is no room for flexibility—the time-limited withdrawal of tools, topic bans, interaction bans, etc. which often represent measured and reasonable attempts to resolve inter-editor conflicts without resorting to the nuclear option. In any review, the ArbCom is left in the unpalatable position of either endorsing a (possibly) sub-optimal decision, or overturning a bureaucrat's call and thereby calling that 'crat's judgement into question.
As a matter of fundamental fairness, this proposal shares with it the usual problem associated with all the instant-community-desysop protocols, in that it's like your boss waiting for you to screw up before scheduling your performance review for the next day. And given the binary nature of the process, your boss' only options are to let you carry on exactly as you were, or to fire you immediately. If the goal is simply to desysop more admins, it will work. If the purpose is to have a fair evaluation of admins, it is badly broken. A lot of the comments I made a couple of years ago at Wikipedia:Community de-adminship/RfC#Flaws in this process noted by TenOfAllTrades apply to this proposal as well. TenOfAllTrades(talk) 13:54, 15 July 2013 (UTC)
What 36 crats? Some haven't edited in ages, others haven't done crat work in years. For active crats you have maybe 6.PumpkinSkytalk22:11, 16 July 2013 (UTC)
Oppose as long as there's no way to accurately distinguish between "the community" and "a walled garden of mutually cooperating editors with an axe to grind". I'm not opposed to a community-led desysop procedure in general, but this ain't it. --Jayron3200:16, 16 July 2013 (UTC)
Oppose Wikipedia must not become a popularity contest where those with lots of friends can get away with anything.Doc James (talk · contribs · email) (if I write on your page reply on mine) 14:55, 16 July 2013 (UTC)
Yes, Doc J, precisely. That's why we need this, so we don't have abusive admins running amok, being protected by their admin buddies, because they know arbcom is gutless.PumpkinSkytalk22:12, 16 July 2013 (UTC)
Support with the change to needing 2 crats, not just one. As someone says above, this can't really do much harm, given the fairly high threshold required to set it off. Given our very small number of active 'crats, I'd be surprised to see this used more than a couple of times a year. While I'd prefer a large scale RfA overhaul that would also significantly increase the number of admins and/or unbundle the tools, this does address one part of the (perceived? real?) problem with the administrator system. Qwyrxian (talk) 22:51, 16 July 2013 (UTC)
Support Some form of community desysopping process is better than nothing, and this seems reasonable enough. wctaiwan (talk) 15:48, 18 July 2013 (UTC)
Oppose: I do believe that some sort of community desysopping process is needed. However, this proposal in my opinion only exacerbates the current problems that have long been addressed in RfAs. If the community is able determine an RfA process that doesn't lead to a RfA needs [major] reform discussion, then I would say that this would be a very sound proposal. But that is not the case. We need to fix the current problems in the RfA process first before moving on to proposals that involves RfAs. Elockid(Talk)16:20, 18 July 2013 (UTC)
Strong support. It's not 100% perfect, but it's probably as close as we are ever going to get. Personally I'd prefer the bureaucrats handling all of it with only small necessary community input, but that's unrealistic. Wizardman19:07, 18 July 2013 (UTC)
As a further note, I'm actually offended by the "harassment of crats" opposes. We all went through not only RfA hell, but RfB hell, and there's a few ex-arbs on the crat list too. I think we can handle a bit of whining. Wizardman19:11, 18 July 2013 (UTC)
Support I could not have expressed my sentiments any better than Wizardman just did. It may not be perfect but it is a strong and significant step closer to reform adminship. We can always have more discussions to tweak the existing setup, if required. TheOriginalSoni (talk) 07:31, 19 July 2013 (UTC)
Support The simple majority seems suitably conservative. I don't agree with the arbitrary 3-per-year-per-bureaucrat limit but meh. A modest proposal that may give the community a modicum of admin-control. --Anthonyhcole (talk · contribs · email) 20:19, 21 July 2013 (UTC)
Oppose as proposed. (At the very least it should be 3 bureaucrats and not the same combination for 2 years. But I'm not sure if I would even support that.) And last I remember, I thought bureaucrats wanted their job to only be (mostly) binary choices, such as: push button or do not push button. I'd like to hear what they think before this is closed. And won't this make passing an RFB almost impossible? - jc3715:41, 1 August 2013 (UTC)
Comment from non-admin: I like the idea of reconfirmation, but I don't exactly like the proposal here as it stands. I think it should be more factual and based on data. What use has the admin made of the tools? How many good deletions and blocks has the admin made vs. bad (controversial is not bad)? Are they properly protecting pages and performing edit requests to such pages? I think that 50% of the final decision should be made on such factual information, stuff that a bot or tool could summarize quickly for all of those interested in contributing to the discussion on the admin it question. Something similar to Scnottywong's adminscore tool, but specifically designed for how well the tools are being used as opposed to how well it is speculated that they "may" use the tools. The other 50% should be community support. Technical 13 (talk) 15:26, 3 August 2013 (UTC)
Oppose The issue arises with sufficient infrequency that the exclusive jurisdiction of the Arbitration Committee is not problematic. Community discussions on such highly disputed and dramaturgical matters are likely to result in more heat than light. DavidLeighEllis (talk) 00:03, 10 August 2013 (UTC)
Another proposal
We have procedures in place for sanctions as discussion on WP:AN. De-adminship should be treated as a privilege and removal should be considered a sanction, thus WP:AN should be able to remove these privileges. Trolls and people who think they've been wronged by the admin could start a thread, but the community can get the discussion in their favour (consensus to keep administrator privileges) Remember that RfA selects administrators? If the community has no trust in a sysop, they should be free to de-RfA. ~~Ebe123~~ → report11:35, 21 July 2013 (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.
Short articles for people with slow Internet?
I keep reading about how access to Wikipedia is expanding to areas where people were never able to access the Internet before, but long articles may be problematic for these people. If they only want a brief overview, is it possible to give them that and then the option to wait and wait or have problems as they try to access the real article?— Vchimpanzee· talk·contributions·20:20, 9 August 2013 (UTC)
I have at times had to edit wikipedia on a dialup (home in a dead zone without high speed internet). My suggestion here is to (if it doesn't already) tweak the underlying programming to let the text and navigation links (edit, etc..) load first, and then the images; folks with slow dialup often need to suppress images or at least start reading while images load. Text comes up pretty decently, my headache ont he dialup was that the article tended to load both text and images halfway, then hang... which was a real pain when I wanted to get the damn "edit" button to come up so I would work on text. Montanabw(talk)21:40, 9 August 2013 (UTC)
It might be a useful option to be able to quickly load just the info box and lede section. Particularly if, like me, you have to use a lot of zoom to even see the words. But then I'd also appreciate shorter articles for people with slow brains. Although I can't think why. Martinevans123 (talk) 21:56, 9 August 2013 (UTC)
But only if one could also get the damn "edit" button to some up; for me on the dialup, I usually had no trouble getting the lede and the infobox in fairly short order 9for a dialup), it was the tools and the rest of the text that was the problem. It was particularly a PITA (pain in the ass) when using "preview". Montanabw(talk)22:36, 9 August 2013 (UTC)
Isn't the solution locally based tho? People at home could choose to browse mobile wikipedia just by adding a .m. Or you could choose to tell your browser to not load images, this is all local to your computer and browser. Centerone (talk) 22:06, 9 August 2013 (UTC)
The problem with using WP preferences or continually changing your browser prefs is that if, like me, you edit from multiple locations (fast work, medium-speed coffee shop, slow home dialup) you are having to change the prefs every time you log on, AND this would only help experinced editors, not the casual reader or new editor who doesn't know all this stuff. Montanabw(talk)22:36, 9 August 2013 (UTC)
Text loading times are generally minimal. Disabling autoloading of inline images in browser preferences will normally result in significant speed improvements. DavidLeighEllis (talk) 23:52, 9 August 2013 (UTC)
Allegedly a lot of internet access in developing world areas is via the cellphone/mobile broadband network. So, they would probably automatically default to mobile wikipedia. Centerone (talk) 16:06, 10 August 2013 (UTC)
Cellphone/mobile broadband (like the one I'm on right now) does not default to identifying the browser as mobile. This is like saying my phone will suddenly start receiving full wiki instead of mobile if I switch to cable WiFi. That is a browser setting. There is no real difference in how data is sent and received regardless of what "kind" of connection you use. After a few switches and routers, all packets end up routing through roughly the same topology. I think this proposal really needs to understand how TCP, packets+headers, HTML+css, browsers and extra GETs work to see how "large articles" are hardly the problem for Internet users of developing countries. For me (with a bunch of gadgets and js), VP page took 94 requests for a total of 900 Kb over almost 10 sec. How much of that was actual page content? — HELLKNOWZ ▎TALK19:57, 10 August 2013 (UTC)
My phone ALWAYS defaults to mobile wikipedia, even if I specifically manually enter the standard wikipedia url. It does this no matter what browser I use (I've tried several.) It does this no matter whether I am on a wifi or cell network. I figure wikipedia is sensing that the device/browser is a mobile device/browser and is sending me the mobile site/code. It's not the network that something travels over that determines what is sent, but rather how the site is coded and how it determines what is sent based on what type of browser is calling for it. Centerone (talk) 21:55, 12 August 2013 (UTC)
Ironically, there are many parts of the third world with better high speed internet than parts of rural America. Where you have no landline phones and it's all mobile, access is actually better, I suspect. Which is mind-boggling. As far as long articles on a mobile go, this probably a situation where writing very good leads per WP:LEAD is the simple solution; a good summary and those who care to scroll down further can scroll down further... so is the issue really speed, or are we actually discussing mobile access? Montanabw(talk)20:14, 10 August 2013 (UTC)
The whole idea is that people in that part of the world would have a very hard time getting to large articles. But if it were possible to just dispaly the lede, that sounds like it would work.— Vchimpanzee· talk·contributions·19:31, 12 August 2013 (UTC)
It would be nice to have an option to "load by sections" meaning that an initial page load would only load the lead section and Table of Contents, then the user could click a section link to load that section without loading the rest of the article, or select a "load next section" option. --User:Ceyockey (talk to me) 22:43, 12 August 2013 (UTC)
frankly, even the most ridiculously long articles TEXT will load almost instantly on even the slowest connections. The bulk of slowdown is in layout and image loading. Having an alternate skin that has minimal (no?) layouts that allow the text to render as soon as downloaded, and that defers loading of images should be easy to do.(IE, don't have nested tables, don't have a lot of divs, dont use complex CSS that requires later elements to render correctly) Also remove most of the wiki tools, menus, etc which can be a huge percentage of overhead on articles and for 99% of users completely irrelevant. Those canbe loaded on demand, or in separate pages, or only when editing etc. Gaijin42 (talk) 23:13, 12 August 2013 (UTC)
There is always simple wikipedia for simple, short articles on a whole variety of subjects. I am not sure starving ppl in Africa or elsewhere are those likely to have mobile phones or they would sell them for food but millions or billions of non starving 3rd world ppl are accessing Internet for the 1st time through their phones and now is the time to be thinking of how to make wikipedias accessible to these ppl, the images and formatting not the text will indeed be the issue here. Thanks, ♫ SqueakBoxtalkcontribs23:24, 12 August 2013 (UTC)
I dont doubt the high penetration, most ppl in Africa though arent starving and the ones who are are in certain rural places, where its the young kids who are the most vulnerable. Thanks, ♫ SqueakBoxtalkcontribs00:01, 13 August 2013 (UTC)
Perhaps a better place can be found to discuss Help:Mobile access and similar questions, but indeed many long articles are inconvenient to read, due to various combinations of slow connection, small screen, and user ignorance. Wikitechnical solutions are more numerous than either individually effective or well coordinated. But I've long thought too few editors are sensitive to the questions raised in WP:TOOBIG and more ought to be done about that. Jim.henderson (talk) 23:32, 12 August 2013 (UTC)
Mobile has been experimenting with this for sometime in our alpha mode (https://en.m.wikipedia.org/wiki/Special:MobileOptions?mobileaction=beta). This is still very very buggy but the general idea is to load pages via ajax when clicked on. The page is rendered and section content is only injected into the DOM via JavaScript when a section is toggled open. We have also been discussing for some time about only serving the lead section and section headings in the content on page load to reduce the HTML payload sent over the wire. For non-JavaScript users clicking a section heading whilst not logged in would take them to some form of sub page which just has the section content for the given section. Revision id would be passed to ensure no weirdness on changing pages. I'd encourage anyone to take an interest in this either by contacting us on the mobile-l mailing list or joining our irc room, it's been sitting in alpha for some time due to lack of interest from anyone. Jdlrobson (talk) 23:45, 16 August 2013 (UTC)
Tweak account creation page?
I've had a few new editors at OTRS (example 2013081510010485) who for some reason or other fail to get the signup page to work for them. I usually direct them to http://toolserver.org/~acc/ and that often solves the problem. Could we have that link on the signup page, as an alternative way for account creation, if the page fails to work? Ronhjones (Talk)20:21, 16 August 2013 (UTC)
The existing "Can't see the image? Request an account" text on the page is MediaWiki:Createacct-imgcaptcha-help, and the URL is MediaWiki:Createacct-captcha-help-url. Someone with admin rights on enwiki can change the URL alone, and/or the help message to make it more general. Note users who don't have JavaScript enabled don't see this nicely-boxed FancyCAPTCHA, they instead get the help text in MediaWiki:fancycaptcha-createaccount which was recently reset to default from a wall of text; maybe those no-JavaScript users are the ones having problems. If you discern some pattern to the problems people are having, please share it, thanks! -- S Page (WMF) (talk) 21:38, 16 August 2013 (UTC)
For now, I would also prefer to keep it linked on the wiki page linked to from the signup page rather than hardcoded in the account creation interface. Not just because the wiki page has valuable info, but because the toolserver is quite unreliable, and is slowly but surely being replaced. Steven Walling (WMF) • talk02:54, 17 August 2013 (UTC)
Watch what you say about other projects. I must object to this oversimplified and rude characterization of toolserver: it has been chronically unsupported by WMF, and underfunded to boot. Now it's apparently unfunded during the critical period since the servers were found to need replacement, and forced to make do, while the vainglorious WMFlabs erstwhile toolserver replacement functionalities s l o w l y (and unsurely, by the way) come online. Toolserver deserves way more respect than it's been getting. Might as well kick the dog, then complain that it whines too much, and doesn't lick your face anymore. --Lexein (talk) 19:21, 17 August 2013 (UTC)
Getty Museum Just Made 4,600 Incredible Images Free to Download and Use
Let's slurp these now Free (attribution required) images onto Commons ASAP, preferably directly from Getty to WMFLabs/Commons. Should use Getty's keywords for categorization, where these aren't already in Commons
Build a tool/script to permit editors to manually approve one-by-one semi-automated insertion of these Commons images into artwork and/or artist pages, where such pages exist.
Would the wikipedia foundation ever consider expanding it's mission to include social media?
Would the wikipedia foundation ever consider expanding it's mission to social media?
I was on facebook the other day talking about very sensitive mental health topics and then I got an ad for a mental health degree pop up on my sidebar...This is going too far...Would Wikipedia foundation be able to create an open source social networking site, is it feasible, would donations be enough? When I'm on facebook I feel like I'm being watched by the NSA but it just happens to be facebook which is the actor not the NSA. It would cost a lot of money I know...I'm broke but I would still donate to the cause as much as I could...Facebook will now be going after me :-(. Thanks guys, I know this is an outlandish idea but why not..Look at what wikipedia has done in changing the way encyclopedias are structured and made a huge difference in the world...Jimmy Wales deserves a nobel prize.Dounai99 (talk) 16:36, 23 August 2013 (UTC) (talk) 15:36, 23 August 2013 (UTC)
The wiki software is free and open source. Anyone who can obtain a domain name can begin a wiki-based social media site. bd2412T16:42, 23 August 2013 (UTC)
Wikimedia Foundation is a non-profit educational foundation. Creating a social media website would be a violation of the rules under which it operates, since there is no educational purpose or value in Facebook equivalents. --Orange Mike | Talk18:03, 23 August 2013 (UTC)
That makes sense...I wasn't that familiar with the mission statement of the foundation...Just a thought and doesn't hurt to ask I guess.Dounai99 (talk) 18:29, 23 August 2013 (UTC)
Among Facebook's many competitors, Google+ is the biggest I know of that doesn't advertize much. Of course we are watched, since being watched is the main purpose of social networks and it's also an important part of what Wikipedia is about. Jim.henderson (talk) 18:42, 23 August 2013 (UTC)
The diaspora looks amazing. It ties into facebook and twitter and google plus I think but is free of prying eyes and eerily based ads based on what you are posting and chatting about. Thanks guys, it doesn't look it's widespread yet but hopefully it will be. Identi has more users but less functions than facebook so not sure about that..Dounai99 (talk) 19:16, 23 August 2013 (UTC)
The Wikipedia Library is an open research hub, a place for organizing our amazing community of research and reference experts to collaborate and help improve the encyclopedia.
Connect editors with their local library and freely accessible resources
Partner to provide free access to paywalled publications, databases, universities, and libraries
Build relationships among our community of editors, libraries, and librarians
Facilitate research for Wikipedians, helping editors to find and use sources
Promote broader open access in publishing and research
Sign up to receive announcements and news about resource donations and partnerships: Sign up
Come and create your profile, and see how we can leverage your talent, expertise, and dedication: Join in
Is it possible that the visual editor can insert hidden comments as we do in the source? They should appear on the page in either <!-- Comment --> notation or appear in a user-defined color, or both, all which should be definable through a dropdown menu with checkboxes, with the option to show and hide them. Thanks. 2602:304:59B8:3279:8CA0:1CFC:C72E:8DD0 (talk) 21:22, 24 August 2013 (UTC)
Several requests have been made at WP:VE/F for the feature, but its not something the devs have gotten too. It should be a feature (in some form), but it isn't here yet. Chris857 (talk) 21:29, 24 August 2013 (UTC)
This is T51603 and is listed as "high enhancement", which I think means that we'll get it sooner rather than later... but I'm not sure what month "sooner" means. It doesn't seem like a super complicated thing to do, so maybe it will happen in the next few weeks or so. Whatamidoing (WMF) (talk) 03:59, 25 August 2013 (UTC)
RfC: Are the Category:Wikipedians and its subcategories appropriate for Wikipedia
I propose an "Up and Coming" class for Topics to promote improvement of quality articles.The symbol for this would be similar to the others but with an arrow pointing up. I was also thinking of it being colored to orange and yellow. This class would be if a main topic has 2/3 of its articles upto GA but not 1/3. That way the broader topics that do have significant ammount of GAs are recognized as a quality topic, and promote it on its respected wikiproject's main page so familiar editors can turn it into a featured/Good topic.
I personally find this idea really beneficial as I'm sure there are topics out their we see have large ammount of GAs but not enough to be recognized by wikipedia. This will make it official.Lucia Black (talk) 22:26, 30 August 2013 (UTC)
A rather questionable essay...but I'm uneasy about "B-class" topic as it would imply all articles will have to be B-class or higher. The class is meant to be for any topic that has 2/3 or more GAs and the 1/3 of the topics could be any class, such as start-A. Maybe a better name such as the Ambitious-class or forthcoming-class.Lucia Black (talk) 01:07, 5 September 2013 (UTC)
Special templates for most frequent speedy deletes
Haunting talk pages as I am wont to do, I see a lot of "Why was my article deleted?" message to Admins from people whose first edits on WP is to set up an article for themselves and/or their company. They usually do not do a very good job as they don't understand about secondary sources or conflicts of interests. That is pretty consistent.
But what is also consistent is the way their inquiries are dismissed when they come to ask "What happened?" They are frequently told that their article was promotional and (in my words), don't let the door hit you on the way out. They rarely return and this is their lingering impression of Wikipedia.
Because I see this happening so frequently, I think it might be useful to create a template that we could add to SPA who come to WP for business reasons and don't really understand that WP is an encyclopedia and not a directory. It could list the most common reasons for deletions and then references to the relevant WP policies that they should consider if they want to put in the time to rewrite their articles.
It seems like this would a) save time for Admins, especially those involved in deleting articles, from having to repeat the same explanation over and over again and b) it would seek to answer the most common questions business people have and be a fuller reply that just "It was too self-promotional". It could be put on the User's Talk Page either for all business-related deletions or after they've sought out Admins to complain.
I can also see this expanded to have specialized templates for musicians whose pages are deleted, other entertainers who are not notable (yet) and other topics that have articles that are frequently created only to be deleted.
If there is support for this, I can see the first step is to learn how to create a template or have some smart editor create something suitable. Then, adoption would be a secondary issue. LizRead!Talk!20:12, 1 September 2013 (UTC)
Please see a couple changes I proposed here. (To not lose the thread, it might be best to reply there; I'm only leaving a note here to attract audience that could be familiar with the subject). Gryllida10:44, 3 September 2013 (UTC)
My take on an AfD reform
Hello. I know this is a recurring topic, but I have not heard of anything similar to the approach I drafted below, so here I go.
After spending some time on Wiktionary, I started to think about our deletion processes, specifically WP:AfD. In my opinion, AfD is broken, for reasons including:
Editors, and especially new ones, often make poor arguments like "Keep: notable", "Delete: non-notable" or "Keep: 50,000 hits on Google" (without actually examining the results). I also often see comments like "Keep: you should have read WP:BEFORE" or "Delete, WP:EXISTENCE", which I cannot help but think is a variant of the fallacy fallacy (you did not follow Due Process™, therefore the article should be kept). People throw at each other essays like WP:SNOWFLAKEorWP:HAMMER and claim that articles are to be deemed notable as long as we can assume that sources exist, without actually showing a single one — even though that contradicts WP:BURDEN, which is policy.
Nobody can ever agree what "consensus" means and how it differs from "the majority of editors". Despite the mantra that "AfD is not a vote", the headcount usually isamajor influence in the final decision; or shall I say "headcount of non-refuted arguments". And because head count, well, counts, people waste time on accusing each other of sock- or meatpuppetry, questioning each other's good faith and other quasi-ad-personam arguments.
The above is further fuelled by the fact that administrators, who are supposed to be assessing consensus and closing discussions, are overwhelmed. This prompts non-admins to do it instead, and non-admins are sometimes less knowledgeable about policies, and often more skewed towards inclusionism, cherry-picking arguments for "keep" to justify a speedy closure. To counter this tendency, discussion-closing rules should be more rigid and unambiguous.
Many AfDs just lay there for a full week without even two comments from anyone other than a nominator, which leads discussions to be relisted; this further keeps the backlog from shrinking.
The name "Articles for deletion" sends the wrong message — that the most important thing is whether this or that article be deleted, while in fact the most important issue should be whether we can find good sources to cover a particular topic, which is the the primary inclusion criterion for the main namespace. A name focusing on deletion breeds myths like "I can has deletion?", and is another factor that can make discussions very personal ("I worked on this article very hard! Please do not delete it!!!"). We should be explicit about the merits on which we base deletions.
Wiktionary has two processes that can result in a deletion of a page in the main namespace: one (Requests for Deletion) is for violations of more technical policies (what constitutes a "word" with a distinct meaning, and such), while the other (Requests for Verification) deals with deciding whether a term is established in a given language, finding sources and examples of usage. I think we ought to have something similar to the latter process: a deletion venue dealing exclusively with verifiability/notability (which I, by the way, see as two ways of describing basically the same concept).
The process will be: 0) an editor finds a poorly sourced article of doubtful notability; 1) they put a notice on the article and start a discussion on a "Requests for immediate verification" noticeboard, stating a reason (which may be optional if there are literally no or few actual sources - not just external links - in the article) and possibly a potential merge target, if a good one exists; 2) the article sits there for some period of time: editors who notice it find sources about the topic and post them in the discussion page; 3) when enough sources are found to write a sourced article of about Start-class quality, the article is kept (preferaby, the article should already improve to that point); otherwise it is merged (if there is a good target and sources only for a stub) or deleted (if not even that).
What will change (aside from the name):
WP:BEFORE will no longer be argued about, because the whole process will be about doing what WP:BEFORE tells you to do anyway: finding sources to establish standalone notability.
Head count will be much less relevant. Votes (enough of the "!vote" doublethink) like "Keep: passes WP:AUTHOR" will be invalid and struck out when not paired with a reliable source covering the subject in depth. While this may simply shift the focus of the discussion to whether a given source is "reliable" and "in depth" or not, I think these concepts are somewhat better established, and the debates should at worst stay at the same level of merit (I am thinking mostly about WP:FRINGE here). Ideally, there would be no vote labels at all, just a bunch of sources and descriptions of what they state (or reports like "I failed to find any sources in [Google, my university library, etc.]").
The discussion period may be longer, a few months even — although early "keep" closures should be permissible, on conditions similar to WP:HEY. Closing rules should leave little room for interpretation, to avoid arguments about justification of a particular closure.
This verification process could also be applied to stale userspace drafts; in case of a successful verification, the article is launched.
This is a rough sketch of the idea, details may change. I will not even promise a standalone proposal page. But please tell me what you think. Keφr15:46, 4 September 2013 (UTC)
Wouldn't every article with {{notability}} tag (i.e. "editor finds a poorly sourced article of doubtful notability") qualify for "Requests for immediate verification"? — HELLKNOWZ ▎TALK16:26, 4 September 2013 (UTC)
Hello I am Dounai99..I was a previous editor and contributor about 1.5 years ago on Wikipedia. I enjoyed it in the beginning but as time went on I noticed the only people who were neighborly were the staff of wikipedia, the tearoom and others in that light. I only met one person who was willing to give me a guiding hand (a veteran to the site) and who I could bounce ideas off and who would give me hints and tips that a wiki staff couldn't do. There were the angels or fairies whatever they're called who would come and and help fix grammar and word usage as well as to do difficult tasks in regards to graphics/graphs and the such that a beginner couldn't do. The rest of the people I met were not neighborly, overly competitive, not wanting to colloborate, mean and said they didn't want to become too "friendly" because it would hurt the mission of objectivity in case of a dispute. While this last part may be true does it really have to be this way. I sincerely hope the tone and culture of Wiki has changed since 2 years ago and that it's more of a community now..Because isn't that supposed to be what the site is all about? A beginner is so naive and wanting to get involved and then they berated by the more mean style veterans who probably look down upon them because they don't know anything. Beginners should be treated with kid gloves in many cases I think and as they grow and develop keep reducing the thickness of the gloves until they are confident, skilled and a veteran. These are just my thoughts on the subject. What do others think? I will keep updating this paragraph as I feel the current Wikipedia and see if things have changed. Dounai99 (talk) 16:32, 23 August 2013 (UTC) (talk) 14:26, 23 August 2013 (UTC)
My personal experience is quite different. When I started editing, more experienced users where watching my edits, checking that they were valuable and policing my mistakes. However, they quickly gave me their trust and were always available for discussions from then on (looking back I understand their actions very well, in particular when, as an experienced editor you have to fight frequent vandalism). Wikipedia is not a tchat website so it is true that you don't spend most of the time discussing with people (it is not the goal isn't it?) but from time to time, I have enlightened discussion with people sharing my interests and whose goal is for the common good, i.e. making articles better. Like everything in life, editing wikipedia is a question of motivation. This motivation you can draw from various sources: some people find it in making article GA or FA, others value more discussions and team work. Personally, I am proud to make article better and always think that thanks to this more of the human knowledge is freely and easily accessible everywhere. This is certainly grandiose but motivates me. And of course I like to tchat from time to time on what I edit with other people. As far as I can tell, there are very few mean people and many simply reflect your attitude to them. Because there are like you and me: most want to share, discuss and see their work recognized by their peers. Barnstars are good for that ! Iry-Hor (talk) 11:43, 30 August 2013 (UTC)
I agree that many editors can be combative and harsh, and not necessarily open / friendly. I have found that people often seem put off by friendly / good faith gestures. This is a culture thing. It's so massive that I don't have a specific suggestion as to how to fix it, but I don't think it's hopeless either. A collegial atmosphere is one I sincerely hope we achieve. Perhaps unfortunately, it is the responsibility of those who are already being nice to make things better, by setting a good example. I suggest that you continue to be nice and to spread WikiLove to all the peoples of the wiki. I'm sure karma-related concerns come into play somewhere; if you treat others with lots of love and understanding hopefully others will do the same to you. I do think we look to one another for standards of how to act; if you place a welcoming, handwritten message on a new user's talk page, for example, other editors will notice and think about doing that in the future. So it's that typical advice about enacting change - start with yourself, set a good standard, and be confident in what you're doing. Hopefully others will take notice. CaseyPenk (talk) 16:27, 6 September 2013 (UTC)
Enable talk page auto-archiving by default
I recently encountered a spate of problems which would not have existed if MiszaBot (or something like it) had been enabled by default.
AtTalk:Traditional Chinese medicine, archives were done manually until MiszaBot was turned on in 2011. However the bot configuration was botched, causing new threads to be added to the very beginning of the archives starting from 2004. Such was the situation until today.
Recently on Talk:Rupert Sheldrake a new user added a comment to an old unrelated thread. This caused some confusion, with one other user responding thinking that the comment related to the thread topic, which it didn't.
This new user continued adding comments to old threads, not realizing that there was essentially no correlation between those discussions and the current article, as the article had changed significantly since then.
Seeing that the talk page had not been cleaned for a while, I took it upon myself to create another archive. However out of bad luck this happened during the subsequent comments by the new user; the new archive started immediately after the new user's first comment. I ended up copying the new comments individually to the cleaned talk page.
Again, all of these problems arise from the default setting of "precarious manual labor" for archiving.
It may be objected that many articles are low-discussion with little need for auto-archiving. Well that's fine, the default bot settings can conservatively target that case.
To cover the case of higher-volume discussion in a user-friendly way, there should be a note at the top of talk pages briefly describing how to tweak the relevant bot parameters. Vzaak (talk) 21:20, 1 September 2013 (UTC)
This is basically already planned. WP:Flow will change the talk page structure, and one feature is that only the most recent/unread comments will display, and the much older stuff will "fall off the page" (not display unless you click on 'load more' or scroll down to see them, or something like that). This results in essentially automagic archiving, plus has the benefit that when you link to a conversation, the link is permanently valid, because the conversation isn't hidden on some other page by a bot. WhatamIdoing (talk) 05:19, 2 September 2013 (UTC)
I just tried the prototype; I have doubts that it will be deployed any time soon (or at all), so in the meantime perhaps enabling Misza by default is not such a bad idea after all. Vzaak (talk) 08:24, 2 September 2013 (UTC)
I think a human should be required to enable an archiving bot, simply because a bot can't tell whether a thread should be archived or not (ideally a thread with a years-old error report should remain visible until the error has been dealt with). And sometimes it can be a good idea to respond to very old comments, like at Talk:Viola#Audio Examples. Overall, I just don't think the great majority of articles change quickly enough for this to be of much use. Graham8713:38, 2 September 2013 (UTC)
The first part of this comment is an argument against archiving bots altogether. We have to assume auto-archiving is widely used for reasons which outweigh these concerns and which are not completely mistaken. I anticipated and answered the latter objection in the OP. This is not an abstract issue; the OP shows in concrete terms problems that stem from manually archiving even for low-traffic pages. Vzaak (talk) 14:49, 2 September 2013 (UTC)
To me a nice feature to have would be an expandable banner saying X messages have been archived since MM/DD/YYYY. Expanding the banner would produce a table of contents with the last 50 archived message titles. Praemonitus (talk) 14:35, 2 September 2013 (UTC)
@Graham87: If a human is responsible for enabling auto-archiving, that doesn't mean a human is judging each thread to determine if it should be archived. Threads are then purely chosen based on age/lack of activity. Having to manually pick talk pages to be auto-archived doesn't address the issue you're describing. Yours is more of an argument for killing the archive bot altogether. You could say there are some articles more likely to develop long discussion pages with old sections of continued relevance; though I'd question that, we could simply make auto-archiving an opt-out process instead of opt-in. It's generally accepted that regular archiving is a good thing. Equazcion(talk) 14:41, 2 Sep 2013 (UTC)
Yeah, I guess you're right there. People are more likely to think "this is a ginormous page ... let's autoarchive it" than they are to go through each individual thread checking for unresolved issues (and I imagine many threads on active talk pages are resolved in fairly short order). Auto-archiving is an awful lot easier and less error-prone than manual archiving, despite its minor drawbacks – and I remember the days before automated archiving with dread. I think, if we're going to do this, it should be done veeeeery conservatively ... perhaps once a talk page has reached, say, 50 threads? Another thing to think about: should we use MiszaBot or ClueBot III? The latter bot has some advantages (automatic indexing, better handling of unsigned comments) but is IMO more difficult to use. I'll ping the authors of both the bots. Graham8716:32, 2 September 2013 (UTC)
ClueBot III (talk·contribs) has three advantages over the MiszaBot family: (i) its operator, Cobi (talk·contribs), has been active more recently than Misza13 (talk·contribs) so it's more likely to be maintained; (ii) it fixes incoming links to sections so that they point to the archive instead of the parent page; (iii) it updates an archive index without relying on other bots (such as Legobot (talk·contribs), which has not updated archive indexes for about six months) to do this. See here for an example where ClueBot III fixes a link and updates an index. --Redrose64 (talk) 17:53, 2 September 2013 (UTC)
Support auto-archiving, either by ClueBot III (talk·contribs) or MiszaBot (talk·contribs). Who knows when Flow will be deployed, yet alone usable. Let's bring some more sanity to talk pages in the meantime. For new users, talk pages can be daunting - when there's so incredibly much content that it's difficult to navigate, people don't feel comfortable participating. This is an easy and straightforward way to make talk pages more reasonable. CaseyPenk (talk) 16:21, 6 September 2013 (UTC)
Softblock school IPs on sight as is done with open proxies
Delaying another "Manning" rename request to later than September 30?
Closing per wp:snow. Active editors on both sides have opposed, and arbcom has said they don't know when the final ruling will be given. I supported the delay, but I don't think we need to keep this open longer just for a foregone conclusion. --Obi-Wan Kenobi (talk) 23:39, 6 September 2013 (UTC)
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.
I raised issues in Talk:Bradley Manning/October 2013 move request about the title itself and the proposal. Wikipedia:Arbitration/Requests/Case/Manning naming dispute is now open. There are disputes and proposal changes on WP:COMMONNAMES and MOS:IDENTITY as far as I know. Also, there are too many editors expressing strong resentment toward use of "Bradley". Starting another request sooner than or on September 30 won't ease things, as I'm afraid. People will cite a policy or guideline that is still disputed, and that would not help the consensus a lot. One is confident that September 30 is the right time to open, but with everything happening right now, I think delaying to November would be my suggestion. One proposes October 3 as the date, which is also the final decision by ArbCom. --George Ho (talk) 15:40, 6 September 2013 (UTC)
Oppose We don't know when the Arbitration case will actually close, absent a special commitment from the committee to end it by that date, we should not plan other things around it. The case could go on for months. Monty84516:01, 6 September 2013 (UTC)
support, provide we have assurances from the committee that they will rule by October 3. I've also asked if they will consider ruling earlier. It's only 3 days, but the difference could be important.--Obi-Wan Kenobi (talk) 16:10, 6 September 2013 (UTC)
Has anyone asked them yet? Also, I note that Arbcom has set the "evidence due" date for September 19, 2013. Surely the best way to move up the decision date would be to first move the evidence due date up by a few days. Today is September 6; is there anything preventing the submission of all of the pertinent evidence by, say, September 12? bd2412T17:52, 6 September 2013 (UTC)
oppose attempting to synchronise with ArbCom. I can see reason in the requested 30 days to wait. I believe that the outcome of the previous discussion was the wrong outcome, but it was the outcome nonetheless. We shouldn't move before something has changed in a meaningful manner. The 30 days was an arbitrary time limit, hoping that that would provide enough time for that change to happen, without being too restricting. That however is now starting to happen. With the last move discussion, sources were rather widely over the map, as were editor opinions. When I look at the pardon request now, I can see that sources are clearly gravitating toward Chelsea. ([2]if anyone could replace that with a web-citation link that be grand. It seems down for me) If any more news comes out of it in the following days, that could seal the deal. I'm not sure if we should start a move discussion early, at a time the deal does seem sealed. On the one hand, yes, we should, since the 30 days limit is artificial anyway, and the underlying reasons would have been addressed. On the other, going against the closure might generate so much drama, that it isn't worth it anyway. But I don't see any reason to prolong. The outcome of the ArbCom case will not likely have much impact on the communities choice on how to name the article. With that, I see no added value for having the discussion later. Apart from that, it is all too common for an ArbCom case to miss its deadline. Do we really want to fix those, and take any delay on ArbComs side to automatically mean a delay for the move the discussion. I don't think so. Neither should you. Martijn Hoekstra (talk) 17:03, 6 September 2013 (UTC)
Support I am willing to wager that one of the things that does come out of ArbCom is a referral to sort out this locus of dispute by binding community RfC. Knowing that that is coming and that ArbCom will probably hand down some conduct modifying tools with respect to the dispute. Acting in advance of those tools being authorized leaves the playing field open for cowboy admins, passionate editor indians, and all sorts of miscreants running around and disrupting the primary purpose of Wikipedia for their own personal agendas. Hasteur (talk) 17:41, 6 September 2013 (UTC)
Oppose. It is not on Arbcom's agenda to do anything that would change or put in doubt the outcome a move request. The 30 days suggested by the closers is meaningless since it is a closers job to close a discussion, not to rename the days of the week or tell editors what they may do in the future. All said and done, this is just a question of when Wikipedia should correct an embarrassing error, and there's no argument that says later is better. Formerip (talk) 18:14, 6 September 2013 (UTC)
How so? The closer interpretted the consensus very accurately. The responsibility lies on administrators who violated WP:CAREFUL by moving "Bradley" and "Chelsea" back and forth without consensus first and left "Chelsea" as the previously-current title. --George Ho (talk) 18:27, 6 September 2013 (UTC)
@Formerip, are you aware that 30 days is a much shorter time than the usual period that would be accepted for a second RM following the close of the first? bd2412T18:38, 6 September 2013 (UTC)
There's no rule about how long a gap to leave before a second move request, and no need to create a rule. In most cases, there is of course no point in having move discussions in close succession, but this is obviously not most cases. What on earth do you think the advantages of an arbitrary waiting period would be? Formerip (talk) 20:21, 6 September 2013 (UTC)
I've spelled this out a few times, actually. Establishing this specific waiting periods gives time for heads to cool, for new evidence to develop in external uses by reliable sources, and for relevant internal policies to be clarified and amended as needed, and it avoids having editors vote against a newly proposed move on the grounds that it's "too soon" since the last proposal. Would you rather lose quickly, or prevail, with some patience? bd2412T20:27, 6 September 2013 (UTC)
Why is a specific waiting time needed? It's looking pretty close to over in terms of what sources are doing. I think heads are already cooled to the extent that there are surely not many people left who think "Bradley" can be successfully defended in the next discussion whenever it happens. There is no immediate prospect of any policy changes. What would we actually be waiting for? Formerip (talk) 20:42, 6 September 2013 (UTC)
A more intelligent, logical, convincing comment/argument, perhaps? Sadly, even an "intelligent" editor must be greatly skilled in communications field. Also, a person who is a great researcher of policies, and a person who knows how to explain arguments. Who else is aware of pending developments besides us here? --George Ho (talk) 20:48, 6 September 2013 (UTC)
It appears to be having the opposite effect than you intended, if your intent was to calm people down and reduce drama. Maybe you should lift it so we can move on? Artw (talk) 21:24, 6 September 2013 (UTC)
To the contrary, most editors who have weighed in on this provision - including those who opposed the name reversion in the RM discussion - are fine with it. Some editors have suggested that more time is needed, but the balance has been struck. bd2412T22:49, 6 September 2013 (UTC)
Funnily enough I don't see 'striking a balance' with editors who wish to keep the article as Bradley Manning that good a reason either. Artw (talk) 23:19, 6 September 2013 (UTC)
One of the things I find most interesting about this situation is that it is the editors who supported reverting to "Bradley Manning" who are now working the hardest on clarifying WP:TITLE to make that policy more conducive to moving the page to "Chelsea Manning". That is the kind of change that will resolve this matter to the satisfaction of those who actually want the title changed. Drama will beget drama; patience and hard work will lead to results. bd2412T23:37, 6 September 2013 (UTC)
Wikipedia is not a bureaucracy, but there IS a rule, which is called WP:CONSENSUS - if consensus of closing admins is to wait 30 days, and consensus of participants is that 30 days is a fair waiting period, that is what will happen. Clearly, consensus seems to not allow 3 MORE days, but c'est la vie. Think about it this way, since you are so doggedly determined to move this - what result are you hoping for? The earlier you do this, the WORSE your chances are. Clausewitz says "Let me sum up once more the last two principles. Their combination gives us a maxim which should take first place among all causes of victory in the modern art of war: 'Pursue one great decisive aim with force and determination.'" If you wait the 30 days, I believe the victory could be decisive, and the bulk of people who !voted for Bradley using COMMONNAME will !vote for Chelsea using COMMONNAME. If you start it tomorrow, with sources still more divided than not, people could claim "It's too early to be sure", and you will lose !votes, and the result could AGAIN be no-consensus - leading to another, longer, waiting period. If you wait, I can almost assure you victory. If you are impetuous, you may lose. Think about it.--Obi-Wan Kenobi (talk) 20:32, 6 September 2013 (UTC)
Oppose per Stephan Schulz. 30 September was the date suggested by the closing admins and any further delays are unacceptable as the overwhelming majority of RS are already using Chelsea. I'd also note that technically any editor is allowed to, at his or her own discretion, file an RM at any time, but some of us have agreed to wait until 30 September unless we achieve some sort of agreement to start earlier. Also, the arbitration committee doesn't make content decisions (or so they say) and doesn't make policy, and the issues cited in the request for arbitration will not really be relevant to the 2nd RM due to changes in how RS refer to the subject. Josh Gorand (talk) 18:23, 6 September 2013 (UTC)
Oppose I support a new RM opening on Sep 30th, if its a week long discussion the ArbCom will be in the middle of this and if appropriate ppl can wait till then to choose or change their choice♫ SqueakBoxtalkcontribs18:27, 6 September 2013 (UTC)
Strong oppose ArbCom have the power to temporarily bar page move discussions if they believe it would either interfere with a case or a ruling is required first, so there is no need to set up anti-injunctions. Timrollpickering (talk) 18:53, 6 September 2013 (UTC)
Comment - What happened to discussing disputed policies and guidelines? I can sense that all of you are discussing ArbCom as prime reason to oppose. --George Ho (talk) 19:02, 6 September 2013 (UTC)
Comment - Two comments actually.
The 30 day hold-off was not intended to accommodate Arbcom. We saw that there were numerous policies and guidelines being used in the discussion that didn't really support the arguments being made. Those policies are in the course of being amended, and a weighting of !votes taken in the light of policy at a later time might actually generate a consensus.
I don't expect Arbcom to rule on the title at all, because there isn't a clear-cut policy mandate about the title. Arbcom should be concerning itself with the wheel-warring, the consequences of screaming "BLP!" in conjunction with an edit when it isn't clear that BLP actually mandates the edit, whether editors that shout "transphobia" or "gay agenda" should receive sanctions, things like that. I certainly hope that no one expects them to rule on the title itself.
That was my understanding too - but the reason I support waiting, if possible, is because any rulings on editor/admin behavior will bear on the new discussion. If we start the discussion in advance of those rulings, the behavioral standards may not be clear and we may end up in Arbcom part II. Would be interested in your thoughts on this matter.--Obi-Wan Kenobi (talk) 20:04, 6 September 2013 (UTC)
I think that most admins are able to filter out clear misbehaviour. The key issue in my mind is that people should wait until something changes, either in policy or usage by reliable sources, that will actually allow a consensus to be reached. I don't think anything Arbcom should concern themselves with will have an impact.—Kww(talk) 22:08, 6 September 2013 (UTC)
Oppose any extensions on the moratorium against initiating a requested move. The main locus of the dispute, in my eyes, was the desire to administer this site in accordance with established rules. Arbitrarily delaying the page's move perverts policy as much as moving it against wp:commonname and consensus; simply serving a different master.—John Cline (talk) 23:18, 6 September 2013 (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.
...is always red. Bright red, square, and nine times out of ten meaning someone has reverted your edit. The appearance of that message bubble is not the best way to start a dispute resolution! It is like a red rag, a seeming challenge burning bright against the blue-and-white color scheme of everything else. That red is very agitating and I am certain quite a few an edit war started on more raised tones than necessary, because not only was a person's contribution rejected, but the news was presented with unnecessary visual aggression way. This is a classical instance of a 'bad start'
You might think 'oh it's only a little message bubble it's not a big deal'
Well that is not the mentality of an edit warrior! Little things take on an exxagerated significance in that kind of situation. An instanteneous red, small, angry start to an edit dispute will become a war. It's enough to make me not want to log in anymore, and just edit Anonymously. There is not a color that could make it worse than this, even if it were bright fuscia. — Preceding unsigned comment added by 85.211.96.68 (talk • contribs) 00:54, 31 August 2013
I think red was chosen because it is 1) very visible/hard to miss and 2) because it is similar to other notification design and therefor easy to understand (email notification on iphone, facebooknotification). I think you make a good argument that red is agitating, but i think that those 2 reasons are even more important and hope that people are already used to red notifications ;-) Peace! --Atlasowa (talk) 10:26, 31 August 2013 (UTC)
And for those reasons, I doubt the color will be changed globally. But if anyone wants to change the color for themselves, it should work to copy the following CSS rules to your common.css and adjust the color codes however you like:
I agree that red is agitating and makes one tense before even clicking on it. I support changing it to a more soothing yet still noticeable color, such as blue. CaseyPenk (talk) 16:22, 6 September 2013 (UTC)
Isn't red the classic color for notifications? It doesn't seem that most of the notifications that people receive are revert notices, but I may be wrong. Sure, the color could be softened a little, but red should probably remain the color of the notification button. APerson (talk!) 01:38, 8 September 2013 (UTC)
Just because it's a 'classic' notification color doesn't mean it's use is correct in this circumstance. And you just KNOW that when the notice pops up after you recently edited an article, it is almost certainly a revert notice. It could be argued that reverting is the laziest and most unconstructive way to deal with a situation, and it certainly FEELS that way when someone throws out your contribution. And Wikipedia just HAS to notify you about it, in bright RED (because it's classical). Not yellow, not orange - RED. It's not a notification anymore - it's an ALERT. And note the difference between the two, and how it is the first step to inducing the user to edit war. The user is not being notified - the user is being ALERTED, to soemthing that needs their urgent attention - their edit is reverted! — Preceding unsigned comment added by Nitrobutane (talk • contribs) 15:50, 23 September 2013 (UTC)
The bottom-up approach of building Wikipedia
I was thinking maybe I should post this message at Wikipedia:Requests for comment but in the end I decided to post here.
I think that the most steady way to develop Wikipedia is the bottom-up approach: First, gather the sources about that subject (article), so you have a solid foundation to build upon.
Imagine we develop the Berlin article. First, we must have a comprehensive list with (more or less) all the books about Berlin: books about the history of Berlin, about monuments of Berlin, about streets of Berlin, about economy of Berlin, etc. It's not important only for developing the article, but also in order provide to the readers more valuable resources for learning about the subject. Therefore, the foundation of an article should be it's "Bibliography" (or better: "Furhter reading") section. The lists can be improved by creating (subjective, or biased if you want, because we don't need 100% consensus on this) tops with the best books and the best authors who wrote about Berlin. When someone wants to know more about history of Berlin, it will be very helpful for them to know who are those considered to be the best historians who wrote about the city.
It's looks very strange for me to see that projects like meta:Wikicite and meta:WikiScholar exist while in the same time articles like London and Paris have only two or three books in their "Bibliography" sections!
Another thing: when a reader wants to learn about his own country (in my case it's Romania), I think it's very important for them to have available tops with the best specialists in his country: List of top 20 Romanian historians, top 20 Romanian mathematicians, top 20 Romanian physicists, architects, chemistry, cybernetics, etc. The lists can be further split: Top 10 Romanian historians of the 20th century, Top 10 Romanian historians of the 19th century, and do on. The only such list I'm aware of is the 100 Greatest Romanians, where they are all mixed together. It's good as a start, but we need much more. Of course it's not the Wikipedians job to create such tops, but Wikipedia editors can try to find such tops which are very valuable (in my view).
Also in the light of the same bottom-up approach, when I find interesting newspaper articles on a subject but I have no time to add information from it into Wikipedia, or I'm not sure where in a specific article to add it, I save the link to that newspaper article (or the essential information from that link) somewhere in the article's talk page, like for example at Talk:Television set#Sales, Talk:E-book reader#Sales, Talk:AMOLED#SalesorTalk:Watch#Sales. Later, someone else (or myself) can pick that information and add it to the article, at the right section. Also, sometimes you need to gather more such data about a single subject until you have enough to make a valuable sentence in the article. For example if the researchers discover a virus that fights against cancer today, that might not be so interesting, but if they discover such a thing every year for 20 consecutive years, then probably the fact is interesting enough and it's worth to add it into the article. This is not the best example, but my point is that collecting data in a corresponding page of an article (like for example in it's talk page) can help to gather relevant facts to add into the article. Sometimes the information is lost after a few years (broken links), so it's a very good idea to save it somewhere. I'm quite sure that some newspaper mentioned on their site the number of television sets sold in the year of 2002, but because no-one had the idea to save that link, now it's very hard to find that information.
On Romanian Wikipedia I am doing that a lot, and some people find it annoying but I really believe that's a good thing to do. When I gather too much information in the talk page of an article, I save it into a sub-page of that talk page, like for example at ro:Talk:Nicolae Ceaușescu/Bibliografie suplimentară ("Bibliografie suplimentară" means "Suplementary Bibliography" i.e. "Further reading"), so it won't bother the actual talk in the talk page. — Ark25 (talk) 05:51, 8 September 2013 (UTC)
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.
Create a new userright that allows editing protected pages in Template: namespace only. Timestamp for RFC bot 03:10, 10 September 2013 (UTC)
Incidentally, if the devs drag their feet about creating this new userright, I would also support a general "edit protected page" userright, too. Writ Keeper⚇♔03:34, 10 September 2013 (UTC)
While I support the proposal, I think there may be alternatives that don't require the creation of a new user right. Rather then propose one here, and create a set of dueling proposals that ensures the failure of both, I'll hope for the best on this one. Monty84503:47, 10 September 2013 (UTC)
Tentative Support- How will this right be given out? If the process is something like Wikipedia:Protected Page Editor ( with the tweaks to make it template only ) than I support. Editors given this right should be required to be familiar with how template sandboxes and testing works. In case it gets brought up again, a user right is a much better solution than the pending changes option as there are technical issues with that option. Specifically as I understand it pending changes cause the templates to be regenerated for all logged users, with all issues that lead to highly visible templates being protected in the first place. Likewise a pending change solution would encourage bad template maintenance practices such as using template sandboxes and testcases. See the previous RFC for more details on the concerns. PaleAqua (talk) 06:17, 10 September 2013 (UTC)
Oppose (Edit protected template userright)
oppose. The wrong solution to this problem. The great majority of fully-protected tpl's should very simply be semi'd. We don't need another user right sysops can give and take at whim. — Lfdder (talk) 10:19, 10 September 2013 (UTC)
I was about to propose the same. This proposal was posted here a bit hastily as a result of this discussion. This is a relatively "large" issue and a more appropriate, fully fleshed-out RfC page with rationale and details is in the drafting stage. Someone should close this for now. Any input from interested parties is welcome and requested at the talk page of the draft linked above. equazcion(talk) 11:01, 10 Sep 2013 (UTC)
What is the problem that this is attempting to solve? Protected templates should be edited with care, and probably not usually in a big hurry. In the current system, we have that protected templates can only be edited with at least two people signing off (unless edited directly by an admin, who has gone through the equivalent of a combined IRS audit and trial by ordeal). That seems reasonable to me. I understand that it's an annoyance to have to get an edit approved, but is it really a problem? Are there protected templates languishing in sub-optimal state? Maybe there are, but if not, do we need this? Herostratus (talk) 15:22, 10 September 2013 (UTC)
It's a problem because the people skilled in these matters often skip them entirely rather than deal with the annoyance. See this discussion. It also leads to people having to apply for adminship purely for this one purpose, ie. Wikipedia:Requests for adminship/Trappist the monk, but many others would rather not bother. The two-person requirement for each edit is de facto due to the current rights limitations, and was not intended nor was it ever decided on by the community to be beneficial. Just because there might not be anything "languishing" doesn't mean things haven't gone unimproved where that might have been beneficial. equazcion(talk) 15:27, 10 Sep 2013 (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.
Unintended links to disambiguation pages
From time to time a Bot informs me that I have created an unintended link to a disambiguation page, instead of to the article I had intended. For example, I may be including a list of place names where someone who is the subject of an article has lived. Usually, I click the links to check that they go to the intended article. But a month ago I missed one and it was the only one which went to a disambiguation page. The kind of unintended link would be putting a link to Birmingham assuming that the only article this would link to would be Birmingham, West Midlands, England.
Now the software developers for Wikipedia are clever people. So would it be possible for them to come up with something which will either highlight any links which go to disambiguation instead of to an ordinary article? Or an advance on this which would automatically fill in as Birmingham, England instead of Birmingham, Alabama if the article is about someone living in England and not in the USA? (A quick look in Perrennial Proposals did not show any similar suggestion.) -- Robert of Ramsor (talk) 21:36, 10 September 2013 (UTC)
This is a great idea; I agree this would be extremely useful. MediaWiki has similar functionality for redirects (see Wikipedia:Visualizing redirects) but it requires tweaks to one's .css page to implement. Ideally there would be options in Preferences to let users choose different colors for redirects and disambiguation pages. 28bytes (talk) 21:48, 10 September 2013 (UTC)
User:Anomie/linkclassifier.js will apparently independently color links to disambiguation pages, redirects, broken redirects, and pages up for deletion. equazcion(talk) 21:54, 10 Sep 2013 (UTC)
We have an ongoing problem with EL spam from low-mileage single-purpose editors [3]. Given that our existing infrastructure already supports limiting what low-mileage accounts can do, can we do anything to restrict their ability to add ELs (and nothing else)? I recognise that it could be a problem to distinguish EL spamming from valid reference adding, and that we might just turn overt EL spamming into more subtle ref spamming. Andy Dingley (talk) 09:05, 13 September 2013 (UTC)
Discretionary sanctions review
(This is a repeat of an earlier notice.) Since March 2013, various individual members of the Arbitration Committee have been reviewing the existing Discretionary sanctions process, with a view to (i) simplifying its operation and (ii) updating its procedures to reflect various clarification and amendment requests. An updated draft of the procedure is available for scrutiny and discussion here. AGK[•]16:47, 13 September 2013 (UTC)
I would like to have been able to {{ping|}} the user in that edit. Can the notification functionality be added to edit summaries? Is that being worked on? Thanks. Biosthmors (talk) 16:57, 13 September 2013 (UTC)
Speeding up the creation of references and external links
Some time ago I came with a proposal for asking online newspapers to come with a unified way for storing key data in their article's pages: title, author name, date and permalink (using maybe meta-info fields). It would be so nice if there would be some "Good practice" W3C standard for this, and if the newspapers would be encouraged to apply that standard in their articles. That would make it much easier for Wikipedia editors to create references and external links. But because that's not going to happen anytime soon, there is another solution for this: With a bookmarklet you can generate automatically a reference or an external link. That means the bookmarklet needs extra code added for every website in order to "learn" that particular website, and the code must be updated every time a website changes the way it's storing those key elements (title, author, date) in their HTML pages. I created such a bookmarklet, and I am using it very much (on Romanian Wikipedia), and it's saving me lots and lots of time. If more people find it useful, then we can make together such a script to handle the most well known websites. Those who would like to try it can find the script here: User:Ark25/RefScript.
I know there is Wikipedia:Cite4Wiki but it seems that it doesn't work very well: didn't find author name and date in the articles I tried it, and in my Firefox it doesn't even allow me to copy the text at this moment. On the other hand, the bookmarklet can generate references in many different ways, and it also can create external links.
In order to change the output of the script, you just have to change the last variable, from "sc" to "sr" or to "s".
For the moment, the script handles only a few sites (BBC, Ars Technica, TG Daily), but the good part is that everyone can teach the script how to handle a new website.
— Ark25 (talk) 01:57, 16 September 2013 (UTC)
See also User:Bazzargh/citemark, another bookmarklet - it's somewhat erratic in output (it tries to get as much info as possible, and then let the human decide which parts are wanted), but is often useful to me. (It doesn't seem to work on the BBC site currently, which is odd. It did previously!) –Quiddity (talk) 17:10, 16 September 2013 (UTC)
Relatively few talk pages are archived, and many have comments going back 10 years or more, typically relating to greatly different versions of the article. Is it possible to do a one-off exercise (or an annual one) archiving everything earlier than some specified date - I would propose perhaps January 1 2009? This would have to be automated, or very largely so. Johnbod (talk) 17:23, 17 September 2013 (UTC)
What would be the advantage of archiving the article talk pages? Are they too big to navigate? I find it handy to be able to reference the talk page. Stuffing it into an archive seems to be counterproductive except in cases were the talk page has become to large to be easily navigated. -- Whpq (talk) 17:30, 17 September 2013 (UTC)
Many are very long, and confusing to newcomers. They are also just full of crap; whatever else "ain't what it used to be" the standard of talk page contributions has gone up considerably over the years. Johnbod (talk) 02:05, 18 September 2013 (UTC)
Absolutely not. I frequently encounter articles with issues that have gone unresolved for years, yet also have old but relevant talk page discussion. Talk page archiving is a task that requires consideration of not just the age of comments, but their relevance to the current state of the article. Blindly sweeping them away is a terrible idea. — Scott•talk12:46, 19 September 2013 (UTC)
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.
Proposal: Allow confirmed or autoconfirmed users to pay a subscription (say $20/year) in order to gain a "sub-administrator" status, for which they will be given a subset of the privileges and tools available to administrators (perhaps the ability to edit protected pages) but denied others (such as ability to block users or IPs.)
Argument: The general idea behind this is that the yearly subscription is like a donation, only the donor can get something in return. An administrator would be able to revoke their powers without refund which, in addition to requiring confirmed or autoconfirmed users only, should prevent abuse of the privileges.
This would
serve as a source of revenue;
motivate low-mileage users by offering a little more freedom without having to run the gauntlet for adminship;
highlight uses who are enthusiastic contributors and;
SNOWBALL OPPOSE Yeah, that's a great big NO. We don't have a cause/effect relationship with donations to the project/foundation and any sort of privilege escalation. Wikipedia's supposed to be a Meritocracy (where the best editors are rewareded. Hasteur (talk) 17:31, 18 September 2013 (UTC)
No - As Hasteur points to, this idea is fundamentally at odds with many of the core Wikipedia principles, perhaps most fundamentally the egalitarian principle that Wikipedia is an encyclopedia that anyone can edit. This idea would privilege editors with the ability to pay money over ones that don't, putting editors (probably disproportionately from poorer countries) at a disadvantage. Zad6817:39, 18 September 2013 (UTC)
Comment: if I understand this correctly then there are two cases here: either the individuals can't qualify for administrative status, in which case the privileges would be inappropriate, or they can qualify, in which case why would they pay for the privilege. I don't think this would fly. Praemonitus (talk) 03:44, 19 September 2013 (UTC)
Wikipedia's administrative rights are assigned in order to benefit Wikipedia, not to benefit the receiving editor. Suggesting rights assignments as perks, no matter what they are given in exchange for (money or otherwise), runs contrary to the reason those rights exist. Any perceived benefit to the editor is incidental, vigorously discouraged, and arguably inaccurate. See Wikipedia:What adminship is not for more information. equazcion(talk) 08:13, 19 Sep 2013 (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.
Better access to Requests for Articles
1. To the best of my ability, I can find no way (other than using a C&P of the URL etc.) of getting to the site where areticles are requested when I am logged in. When I search for a topic that does not have a Wikipedia article, I don't get directed to that page. On the other hand, if I search while not logged in, I am invited to go to that page and make a suggestion (after checking that one doesn't already exist etc.). Why is there this discrepancy?
2. Why isn't there a notice that a non-existing article has a request for an article? That would save time going through all the steps (searching, logging out, getting to the correct request page, searching the request page to check that the request has not already been made, and then backing out upon discovering that it HAS been made). Kdammers (talk) 07:08, 19 September 2013 (UTC)
IPs can't create articles, so we get directed to WP:AFC when we try to create one by clicking on a redlink or searching a non-existent topic. Autoconfirmed users can create the article themselves without assistance, so there's no need to direct them to AFC. If you want to see what has already been requested, just go to the relevant section of WP:RA. I don't see where you've got the idea that users can only read WP:AFC when logged out. (If only IPs could read it, it wouldn't be a great deal of use since no autoconfirmed user would be able to see the requests and create the articles.) As with every wiki page it's readable by everyone, logged-out/logged-in/autoconfirmed/admin status just affects whether you can edit a page. 2.96.222.56 (talk) 09:24, 19 September 2013 (UTC)
RfC on proposal to merge WikiProjects characterized as "Fringe"
The idea here is to have a single Wikimania wiki (wikimania.wikimedia.org) for all conferences, instead of the current separate-wiki style (wikimania2012.wikimedia.org). This has been discussed at Meta:Wikimania project domain in 2011, but seems to have quickly ran outta gas.
Key issues addressed:
Q1: Organizers (alone) of a current conference needs to have absolute control over the conference wiki (aka being an admin).
A1: Wikimania wikis does not run as normal projects. Hence, all organizers shall easily be given admin rights (and former organizers removed) as it becomes necessary. The cycle continues.
Q2: What about archiving past wikis? What if we need to look back?
A2: Except for key pages (such as the Main Page), all other pages of each project could be created under the respective year's subpage. For example, all 2012 conference's pages would be under: http://wikimania.wikimedia.org/wiki/2012/page/page/etc. Additionally if necessary, any vital page requiring archiving could also be edit protected (cascading style too, if possible).
I am proposing that the WikiEditor's "Special characters" list of characters be displayed in the natural order of their origin, regardless of the language setting. - To clarify; the selector's display direction is dependent on the language set by the user in Preferences. In our case this defaults to English which is written from left to right (LTR). Thus, non-Latin languages like Hebrew and Arabic, which are written from right to left (RTL), are also displayed LTR. This is the equivalent of a display direction for Latin characters as J I H G F E D C B A. Proofreading documents which contain these characters, in addition to unfamiliarity, makes the task nearly impossible. The Bugzilla bug report link is below for anyone interested to comment. Ineuw12:42, 21 September 2013 (UTC)
Create it, then. For better or for worse, we have no Barnstar Approval Committee. But I think this is a good thing to reward for. (Although personally, I would use the "thank" feature.) Keφr11:34, 13 September 2013 (UTC)
Keφr, I was hoping I wouldn't have to learn how to make one, but maybe interest someone who could throw it together. Any suggestions? Thanks Hellknowz. Biosthmors (talk) 16:50, 13 September 2013 (UTC)
@Biosthmors: I have created many PUA (barnstars). Let me know if you think I may help. Most probably, I'll not create directly, but, I'll work on coding. --Tito☸Dutta18:20, 22 September 2013 (UTC)
Horizontal lists: make ordinals appear by default when using ordered lists
Since its inception, horizontal lists have become very popular. But during its creation, some insisted that the ordinals (numbers) do not appear when using a horizontal ordered list. This has never sat right with me. I propose that horizontal ordered lists show their ordinals by default, by means of deprecating the hnum class. Here is why:
Just as with using regular HTML lists, people expect ordinals to be shown when using ordered lists. The same principle should apply to horizontal lists: If one does not want to show ordinals, one should not use an ordered list to begin with.
Hiding the ordinals by default creates an accessibility issue... not for those with screenreaders, but ironically for the seeing. Where screen readers still read out the ordinals, they are hidden from view on the display. Why this is not seen as a valid accessibility issue is beyond me.
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.
Proposal: Close the Notability Noticeboard, and direct posters to one or more other, related, higher-traffic pages.
Background: The Notability Noticeboard exists to answer questions and draw attention to topics related to Notability, particularly with respect to determining whether a topic is notable (and often before an article for the topic has been created). Posts such as these arise often enough that there should be a place for them. However, almost from it's inception, the Notability Noticeboard has been plagued by inactivity and indifference on the parts of most experienced editors, and the problem has only gotten worse with time. The result is that a number of posts posed by (mostly new, inexperienced) editors, in what should be the proper place to gain notice, are going unanswered. That's a problem, and it shouldn't be allowed to persist.
More recent posts (following this AN/I post) have been answered, thanks to the efforts of a very few editors. This may give the superficial appearance of a functioning noticeboard, but it really just masks the problem. The noticeboard will continue to fail in its mission to draw notice to posts there as long as there are only a few experienced editors maintaining it.
As this problem has persisted for ages, any solution based upon attracting experienced editors to the board is likely to be temporary and insufficient. Given that, as well as the fact that posts concerning notability are addressed daily at several other locations, the most effective solution would seem to be to close the noticeboard, and direct potential posters to place their posts on another, higher-traffic board, where they might actually gain notice.
Notes:
The board itself will be retained for historical reference, but will accept no new posts, and will have a header and/or editnotice such as these, directing traffic elsewhere. (If you think the header or editnotice should be altered, please include your suggestions below.)
Wikiproject Notability and The Drawing Board exist, but both have become inactive. Jump-starting these, while a worthwhile goal in itself, should not be considered a solution to the noticeboard problem, for reasons similar to the above ("any solution based upon attracting experienced editors... is likely to be temporary and insufficient")
For further background, see this recent AN/I post, the original discussion which started the noticeboard, and these previous village pump discussions: 1, 2. Also see the discussion preceding the closing of the Drawing Board here.
Support - I've tried to help prop up the noticeboard for some time now, but its been to little avail. I support any proposal that gives the discussion of notability its proper attention, including this one. Buddy23Lee (talk) 23:05, 8 September 2013 (UTC)
Support - Notability, after an article is created seems to be primarily discussed at AFD as a result of a deletion nomination. It's been my experience that attempting to get any sort of reasonable discussion on notability on an article's talk page fails because most editors don't know about the discussion, and traffic to articles of borderline notability is likely to be very low and not receive much attention from the general editor population. I'd say that for topics for which articles have not been created, it might be viable to put it through AFC. But AFC itself has problems with quality control as it appears that anybody can review at AFC and there doesn't appear to be a mechanism there for discussion and consensus for notability. Please feel free to correct me if I got that all wrong as I am not too familiar with AFC processes. As for the notability noticeboard, it clearly isn't working.-- Whpq (talk) 21:52, 11 September 2013 (UTC)
If "AFD" was "Articles for Discussion" where merge / redirects could be used as a reason to nominate, I'd agree. But AFD has been hard fought to keep it only to nominations that require admin actions for deletion of content (attempts to make AFD for "Discussion" is a perennial proposal). --MASEM (t) 16:13, 13 September 2013 (UTC)
Support The noticeboard doesn't seem to see much use in the first place -- it's been around since 2009 and has only 15 archives, vs. the reliable sources noticeboard started in 2007 with over 150 archives -- and RSN's archives are actually significantly larger individually as well. Also, based on a quick skim of the current and archived discussions, at least half of the postings are either erroneously placed there or are merely advertisements for discussions ongoing at other pages. Add to that, that we now have AFC, where as-yet non-existent articles should be proposed, that further cuts down on the appropriate uses of this noticeboard. I would say it definitely can and should be closed, even though the intention was good. equazcion(talk) 22:19, 11 Sep 2013 (UTC)
Question and support. I just wonder where will we direct people. How about to WP:VPM? That one has enough traffic. And it's marked as miscellaneous so it can serve as a catch-all. Biosthmors (talk) 11:16, 13 September 2013 (UTC)
I've included a list of possible places to direct people in the header and editnotice linked in the first bullet point under "Notes:" above (here it is again). If I had to pick one, it would probably be the the Help desk, although I'd prefer to list several, because (as described in the AN/I post linked above) notability is regularly discussed at a number of venues (including: the AfC Help desk, the Teahouse, WP:3O, and WP:RFC), and posters have frequently confused the Notability Noticeboard for Requested articlesorArticles for Creation.
Thanks. I don't want us to put up a "historically inactive" template because I think that's a Debbie Downer that doesn't encourage people to contribute. I'd rather there just be a soft redirect to one spot, but all incoming links changed anyways. Notability is a central concept. So VPM seems fine still to me. Biosthmors (talk) 17:13, 13 September 2013 (UTC)
It is my understanding that a "soft redirect" page is typically blank, save for the link to the page it redirects to. I would much prefer something that includes links to the archives, and to the various other noticeboards (either through the "historical" template, or maybe through Template:Noticeboard links). However, if others believe WP:VPM would be a good place to direct posters, I wouldn't be opposed to also including a big notice at the top of the page to the effect of "Posts here will now be addressed at the Village Pump."
Oppose There is no good central place to draw discussion notability issues of an article before or after creation and where deletion may not be the option. AFD is not the solution when deletion is not the ultimate goal. Getting more editors involved to help answer is one step, and by getting them involved, we can weed out the misplaced requests better. (In my case, I thought I had the noticeboard on my watchlist but found only recently it had slipped off). Basically, this sounds more like just increasing participation rather than anything otherwise wrong with the board. --MASEM (t) 16:13, 13 September 2013 (UTC)
But with the consistent record of low participation (as seen in the archives), and the inactivity on WikiProject Notability, how do you propose to increase participation? I can't think of any ways to guarantee the significantly higher participation, now and in the future, that would be required to make the board worthwhile. And I'm not going to sit by and watch this "notice" board continue to deceive posters into thinking that their posts will actually be noticed if they place them there. I think everyone here would rather have a fully-functioning noticeboard, but nobody's come up with any good way to fix it. And a misleadingly dysfunctional noticeboard is much worse than no noticeboard at all (especially when the traffic there could easily be absorbed by other, better boards). I'll also point out that the two most frequent responders there (at least recently), who would be the most likely to have a good grasp of the sorry state of the noticeboard, were the first to support this proposal. It's not ideal, but it's the best solution presented so far. ʍw17:06, 13 September 2013 (UTC)
I agree; if from '09 to '13 participation (and btw, overall use) has been exceptionally low, efforts to increase participation are likely to provide only temporarily upticks. If there isn't fundamental interest in a board then things are not likely to change in the long run. equazcion(talk) 17:16, 13 Sep 2013 (UTC)
I'd still like to see any ideas Masem has for generating significantly more, lasting participation. Note that, statistically, despite an AN/I post to attract experienced editors to the board, and despite the valiant efforts of a few editors to address more of the posts there, the Notability Noticeboard still has less than a tenth of the traffic of the Reliable Sources Noticeboard (also illustrated by the archives), and less than a twentieth of the traffic of the BLP Noticeboard. ʍw14:05, 14 September 2013 (UTC)
Arguably, it's a chicken and egg problem - the board has low participation due to low visibility (compared to RS/N, BLP/N), and because it has low participation, it is not mentioned much outside of it or other notability-related areas (like WT:N). How you get more editors to it, I don't know short of spamming the link around. --MASEM (t) 15:14, 14 September 2013 (UTC)
The following discussion has been closed. Please do not modify it.
Comment: Given that a week's discussion has yielded the support of several editors (including all (both) of the current frequent Notability Noticeboard responders) but only one oppose, and that the rationale for that one oppose has proven to be flawed, I intend to implement the proposal within the next day or two (unless User:Masem can come up with a much more convincing argument against it). ʍw00:15, 14 September 2013 (UTC)
I doubt that would fly. You're the proposer, so you're hardly uninvolved enough to say who's arguments are valid, and definitely not to close this discussion. And I think it would take more than 5 participants in a discussion to close down a noticeboard. I had posted a link to this just this morning at the notability policy talk page. If you want to accelerate things maybe an RFC tag would help. equazcion(talk) 00:20, 14 Sep 2013 (UTC)
(edit conflict) I never claimed any arguments were "valid" (or invalid), just that there were flaws with the one oppose (although, every support could be said to have flaws too), and that both major participants in the board support the proposal. I could not find any guideline on how long a village pump proposal discussion should run; I figured a week was sufficient (the fact that there was only five responses further illustrates the lack of interest in the board). But if it's not, I'm fine with letting it run for a while longer, as long as it doesn't drag on and on aimlessly, like the noticeboard itself. How long do you think it should run? ʍw00:30, 14 September 2013 (UTC)
There's no hard and fast rule. You mainly just need more participation, not necessarily a minimum time period. They tend to go until there's an obvious outcome either for, against, or stalemate -- and you generally need to have an uninvolved administrator make the final assessment; you can't do that yourself. This probably hasn't gotten enough participation primarily because people don't know about it IMO. I'll list it in WP:CENT, that should get some eyes, and I'll let you decide if you want to add an RFC tag. equazcion(talk) 00:37, 14 Sep 2013 (UTC)
I'm well aware that I can't close the discussion of my own proposal; I never suggested I would do as much. What I want to do is stop posters being misled into posting at this dysfunctional board while we finish hammering out the details. If, by some miracle, someone comes up with a good way to fix the board, anything I do can be quickly and easily reverted, by anyone (that's why I insist on retaining the board, with prominent links to the archives: so that it can be easily reopened in the future if the problems are solved). ʍw00:48, 14 September 2013 (UTC)
Comment: Why is an RfC necessary, or even recommended? Preceding this discussion was a discussion at AN/I (linked above), where it was suggested that any real proposal to change or close the noticeboard take place here. Now that a discussion has taken place here, you're saying that there needs to be yet another discussion in yet another venue? Where does it end? And what about the posters who will be misled into posing there while we have discussion upon discussion and bask in the bureaucracy of it all. Perhaps I misunderstand the purpose of this page; I thought consensuses formed here were just as valid as those formed at an RfC or similar. ʍw00:48, 14 September 2013 (UTC)
RFC is just a tag you add to a discussion, that allows a link to be listed where more people can see. The discussion can continue here, and does not need to start somewhere else. Just add the RFC tag at the top of this section. equazcion(talk) 00:51, 14 Sep 2013 (UTC)
I feel like I've seen RfC's started as offshoots of previous discussions treated as completely new and separate discussions. If you only want the tag in order to draw more attention to this continuing discussion, I'm fine with that (and have added it accordingly). Although I'm not overly happy with the prospect of letting the board languish for another month. ʍw01:07, 14 September 2013 (UTC)
You could try and close it down now if you want. I'm sure not stopping you. In fact if you can get away with cutting through the red tape I'll applaud you. But knowing Wikipedia, I doubt the noticeboard would be allowed to stay closed for more than the time it takes for someone to find out you did so as the original proposer and with only 6 people supporting -- not to mention that it might be seen as "disruptive" enough for a warning. And yes I was only suggesting adding the RFC tag to the current discussion, not starting it over elsewhere. RFCs 'are sometimes started as separate discussions or even their own pages, but they don't necessarily need to be. equazcion(talk) 01:15, 14 Sep 2013 (UTC)
Too late; the tag is in place. We're bound by the infallible code of Wikipedia to wait an additional 30 days. Again, I'm not totally pessimistic: there's still a slight chance that someone will come up with a better solution, and now they have another month to do it. And with the attention being drawn to the board, more editors might start participating there, at least enough to maintain it for the duration of the RfC. But knowing Wikipedia, things aren't likely to work out that well. ʍw01:29, 14 September 2013 (UTC)
Just a note, there's nothing that says you're bound to wait 30 days once the RFC tag is there. You can remove it whenever you want. I wouldn't, if you want the best shot at getting an actionable outcome from this discussion; but you're perfectly allowed. equazcion(talk) 01:32, 14 Sep 2013 (UTC)
Support Discussions about whether an article should exist or not are addressed by WP:AFD and WP:DRV; discussions about whether particular content of an article is notable can go on the article talk page. NE Ent11:55, 14 September 2013 (UTC)
I will point out that AFD should not be considered a place for "discussions" about an article, only when one is assured action is absolutely needed. Yes, article talk pages are good for content, but when the notability of the article is in question (but where editors are not sure), there needs to be a way to reach a wider venue that is not AFD. --MASEM (t) 13:53, 14 September 2013 (UTC)
VPM would be the closest/most appropriate, but I believe that notability questions would be lost amid the wide array of topics that board discusses. The other suggestions don't seem appropriate (Drawing Board is pre-creation, and N/N was designed for discussing notability at any point in an article's history). Realistically, if N/N is closed down, the best place to discuss specific notability questions is at WT:N. --MASEM (t) 14:43, 14 September 2013 (UTC)
@Masem: The Drawing Board was not suggested as a place to direct the N/N traffic to; it's marked as historical anyway. By "my draft header", I was reffering to this. (Also, in case you haven't noticed, I've requested further clarification and background on your !vote above). ʍw15:00, 14 September 2013 (UTC)
The links in that header are fine, save that we're missing the case where you want to discuss the notability of an existing article but aren't sure if deletion is the answer (Hmm, maybe add something about merging there). This is a reflection on the problem with merges, redirects, and move requests - unlike deletion where a separate venue that is well advertised, the only place to discuss an article is on the talk page, and more often than not, you only get opinions of editors vested in the article in question which is immediately biased. You can tag an RFC to get more interest, but that's typically more trouble than its worth. This all comes around the perennial proposal of making AFD "Articles for Discussion" which never has achieved consensus. I feel we need a place for discussing issues that are otherwise stymed at the article talk page when it comes to notability and other facets, and maybe that's something N/N can be morphed into. --MASEM (t) 15:14, 14 September 2013 (UTC)
No matter what you try to do, the most likely outcome is that people will post their questions at the same place that they posted them before the creation of NN, i.e., at WT:N. (Article talk pages is an impossible discussion location when the question is about whether to create the page in the first place.) WhatamIdoing (talk) 05:18, 15 September 2013 (UTC)
I know nothing of the debate on the scope of AfD, and so can't comment on it. However, in situations where a merge/redirect discussion on the talkpage of a low traffic article isn't attracting enough comments to generate a real consensus, and WP:3O is inappropriate and an WP:RfC would be "more trouble than its worth", another good way to attract outside input is to notify the relevant WikiProjects (it really is too bad that WikiProject Notability is inactive). Or, in the case of BLPs (where I've most often seen such situations), we also have the BLP Noticeboard. ʍw15:43, 14 September 2013 (UTC)
The problem with Wikiprojects is that when it comes to notability and retaining articles, there is an implicit bias without strong reasoning for keeping such articles regardless of the arguments (this is not universal across all WP's, but a default assumption). --MASEM (t) 15:48, 14 September 2013 (UTC)
Where all else fails, you still have the option of WP:RfC, which, "trouble" that it may be, is all but purpose-made for such situations (nice to know it's good for something other than dragging out village pump discussions). ʍw15:55, 14 September 2013 (UTC)
Truth is, thinking about it, I'm not even entirely sure why a discussion would be required on the notability of a topic. It doesn't generally help with the development of an article -- RSN is where you go for assessment of sources, while this is just to determine that one yes-or-no question; and I'm not sure what for -- which is probably why it's only got 15 archives in the 4 years it's been around (I'm not sure if people are grasping just how seriously low that is). I'm seeing two possibilities, aside from curiosity: You're considering the creation or deletion of an article. If you're considering nominating an article for deletion and you lack requisite knowledge of N, either learn more about it and do the research, or risk nominating for deletion so others can determine this, or tag it with {{notability}} and see if it gets nominated by someone else. Adding another option here is pure WP:LIGHTBULB; but I'll tell you what, if you want to cave to that tendency, we could create a new banner template for tagging and categorizing notability discussions taking place on article talk pages, for use by those who feel they just must do something between nothing and nominate (I'd be happy to create that). equazcion(talk) 19:19, 14 Sep 2013 (UTC)
Support I don't know if everyone is aware of this, but I believe we can count the teahouse as one of the most successful things we have ever had for helping new users confused by WP's maze of policies and noticeboards. Users unfamiliar with the concept of notability as defined here should be directed there where they will get a fairly prompt and accurate reply. Mark this as historical and add a note directing users to the teahouse. Beeblebrox (talk) 21:11, 14 September 2013 (UTC)
That's great for new editors, but what about established editors that need to discuss notability problems of a more advanced nature that aren't suited for an AFD discussion? --MASEM (t) 21:25, 14 September 2013 (UTC)
Per my comment above, I'm still not sure what circumstances would make that necessary, especially for advanced users. There aren't many potential notability concerns beyond the question of is this or is this not a notable topic. There could be rare exceptions, but I wouldn't say a noticeboard is required to handle exceptions. equazcion(talk) 21:32, 14 Sep 2013 (UTC)
Masem: A relevant WikiProject is probably the best place, as its editors are most likely to be familiar with the fates and relative importances of articles on similar subjects. --erachimatalk22:49, 14 September 2013 (UTC)
Support - Little used cul de sac of WP which even if it worked perfectly would only duplicate our standing notability-and-deletion mechanisms (Tagging, PROD, and AfD). Carrite (talk) 22:38, 15 September 2013 (UTC)
Support - So little used it took me 5+ years to realize that it existed. Beeblebrox beat me to saying it, but I think that we should point notability questions to the Teahouse; when I wanted to know if "I am Going to the Lordy" was notable, that's where I went (even though I was a Teahouse host at that point). öBrambleberryofRiverClan13:33, 19 September 2013 (UTC)
Support - The noticeboard rarely produces adequate outcomes and is, in my opinion, redundant to other venues. Most editors these days directly nominate for deletion or tag articles with {{notability}} and discuss on the talk page if they want to discuss notability. New editors can ask at the Teahouse or other help pages. I don't really see a potential use or benefit in having this around. Michaelzeng7 (talk) 01:51, 21 September 2013 (UTC)
Support - I've been here for 2 (nearly 3) years & in that time (til today) I never knew this board even existed!, -
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.
Can we make the page look like a normal disambig page? I think the historically inactive thing on Wikipedia:Notability/Noticeboard discourages participation/editing. For example, if I wanted to modify where to tell people where to go, now I can't. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 18:54, 29 September 2013 (UTC)
Semi-protect all templates?
Although most templates vary in importance from "critical" to Roche.svg; I personally think that, after seeing some vandalism by IP's to some navboxes lately (particularly ones for media conglomerates for some bizarre reason), maybe we should consider only allowing registered users to edit templates (they would still be allowed in Template talk, of course, and maybe we can exempt sandbox pages from it as well).
Permanently preemptively protecting pages (even templates) flies in the face of the goals of Wikipedia. I don't think it's a good idea at all. Jackmcbarn (talk) 18:55, 13 September 2013 (UTC)
In practicality I don't think semi-protecting all templates would be such a bad thing. Almost nobody who has less experience here than the autoconfirmed requirements should be expected to know what they're doing with templates. Nevertheless, I think the fact that anyone can edit them sends an important message about Wikipedia's principles. It reminds us of those principles as well. Any preemptive restriction is a step towards another preemptive restriction. equazcion(talk) 19:13, 13 Sep 2013 (UTC)
We have experienced IP editors who choose not to register. Enacting such pre-emtpive restriction would affect them. -- Whpq (talk) 19:24, 13 September 2013 (UTC)
Screw IP editors! But no seriously you do have a point, I didn't think of that. :) equazcion(talk) 19:29, 13 Sep 2013 (UTC)
Out of curiosity more than anything, Whpq, can you show me a template that has had many IP edits that couldn't be considered trivial or vandalism? I don't disagree with you, I would just like to see some evidence that there are actually use cases of templates being edited by IPs that goes past casual. I also wouldn't be opposed to them being semi-protected with the option to unprotect upon valid request. Technical 13 (talk) 20:06, 13 September 2013 (UTC)
My comment was a general point that we deliberately have made the choice that editting as an IP is allowed, and absent very good reasons, we shouldn't be restricting their abilities to edit. Navboxes are nice to haves, so I don't see that vandalism happens on them as a sufficiently good reason to protect them in any manner. -- Whpq (talk) 21:09, 13 September 2013 (UTC)
They are actually a template comprised of other templates, and are used to ensure synchronization between the three relevant articles. And yes, I noted the irony myself of the vandalism to the Flames template, but I think it curious that you focused on that rather than the dozens of useful updates. Resolute00:33, 14 September 2013 (UTC)
Some IPs definitely are. I have seen wonderful works of IPs in templates (mainly one IP starting with 76 something). So, No. --Tito☸Dutta18:22, 22 September 2013 (UTC)
Comment - Templates certainly aren't content or plain text, and I think it can be safely said that most (but certainly not all) templates affect several articles and provide links or serve to automate data entry and update stats subject to frequent changes. I don't believe that restricting access to auto-confirmed editors would be a hinderance nor fly in the face of the encyclopedia being free content that anyone can edit. Conversely, I don't believe most templates are in any need of protection. Perhaps the threshold for semi-protecting templates could be set very low; otherwise this seems to be a solution in search of a problem. - Floydianτ¢23:45, 23 September 2013 (UTC)
Oppose, especially if this would include userspace templates (as is the case for userboxes). Protection should only be used when there is a risk of vandalism or other abuse.--Jasper Deng(talk)02:14, 24 September 2013 (UTC)
Oppose. Not only would this prevent IP-by-choice editors from ever experimenting with templates, it would prevent registered editors in good standing from doing regular template maintenance when they are accessing WP from an insecure location where logging in to an account is inadvisable. Also, it is a violation of a pillar. VanIsaacWSVexcontribs06:04, 25 September 2013 (UTC)
Oppose - if anything, the "convenience" protection of many non-critical, low- or mid-traffic templates should be lifted. Constructively editing IPs are (or can be) a valuable contribution for most Wikipedia aspects, we shouldn't risk loosing their input. What should be done, is going more consequently after vandalism-only IPs and banning earlier, if an IP doesn't manage to offer any worthwhile addition at all. GermanJoe (talk) 06:45, 25 September 2013 (UTC)
Oppose on technical grounds. After much thought about this and reading the discussion here, there is really no technical way to distinguish between templates and drafts and otherstuff in userspace or project space, so this protection canvass could only be applied to Module: and Template: effectively. What would this mean to the project? This would mean that:
A) There would lot unconfirmed and IP editors that would be creating templates in inappropriate places to circumvent the protection.
B) There would be a lot more template submissions at WP:AFC that the project is currently unable to process (we only have a few reviewers capable of understanding templates and most of them either wouldn't have the time to keep up with the inflow or don't have the interest in reviewing others templates).
There are likely other scenarios that would be undesirable from this that I've not had enough coffee to think of right now, but either one that I listed here is enough for me to say "no thanks" to this proposal. Technical 13 (talk) 12:03, 25 September 2013 (UTC)
Eliminate or Rename "Fictional Hillbillies" Category
Proposal: Eliminate or rename the "Fictional Hillbillies" category, and any other article or category that employs the ethnic slur "hillbilly", using "Southern Mountaineer", "Southern Highlander", or some other, neutral term.
Argument: Wikipedia wouldn't tolerate a category of "Fictional Coons"—meaning stereotyped misrepresentations of black Americans as ignorant, boisterous, superstitious, libidinous, cowardly, and brainless—even though there are plenty of such characters, so designated when they were popular. A category of "Fictional Yids", "Fictional Dagoes", or "Fictional Micks" would, quite properly, be taken down within minutes of being posted, even though stereotyped characters appropriate for inclusion in such categories are abundant in the popular music and literature of the 19th & early 20th Centuries.
Why then does Wikipedia tolerate a category for analogous stereotypes of Southern highlanders? Like "coon", "yid", "dago", "beaner", etc., "hillbilly" is a jocularly derisive, manifestly ethnic classification, applied to Southern highlanders (or occasionally to all white Southerners)* by others, to point out the former's membership in a despised, alien, and fundamentally inferior group; their non-membership in the speaker's own, presumably superior, group; and, at times most importantly, the speaker's non-membership in, and "appropriate" disdain for, the inferior group.
The unfortunate history of race in the United States has tended to obscure genuine ethnic distinctions (other than those deriving from relatively recent immigration) within broad racial classifications. (Wikipedia's article on Ethnic groups in the United States suffers greatly from this confusion.) Such divisions nevertheless exist (though seldom without some element of race, or class, or both); and each is accompanied, to a greater or lesser degree, by its distinctive complement of conflicts, abuses, prejudices, stereotypes, and derogatory names.
There's no reason why a slur like "hillbilly" should be any more welcome on Wikipedia than any other epithet that demeans or disparages people on the basis of race, class, ethnicity, age, or similar category.
Notes:
I recognize that my proposed alternatives to "hillbilly" suggest a United States POV in using "Southern"; but less parochial alternatives like "Southern (U.S.A.) Mountaineer" seem awkward and contrived. I venture to predict that the average reader will readily understand "Southern" in this context to refer to the Southern United States.
Wikipedia does have an article on the musical genre of "coon songs", while the equally offensive term, "Hillbilly music" appropriately redirects to Old-time music. Since "coon songs" are songs about stereotypical black American characters (usually presented in the persona of such a character), rather than the authentic musical expression of a group referred to as "coons" (although some "coon songs" were written by black Americans), it's appropriate for Wikipedia to cover the genre under its regrettable name. (I do, nevertheless, prefer to see the term "coon song" set off with quotation marks, as an indication that it was coined and used by others, in another time, and that its use today is in the nature of quoting those who named the genre, and not a matter of preference or choice.
Stereotyped fictional black American characters, such as Amos 'n' Andy, who might have been referred to as "coons" in former times, are listed on Wikipedia under the rubric Fictional African-American people.
Reference:
* See, e.g., this charming remark (second-to-last comment in section) by a now-departed Wikipedian in a Village Pump discussion: "I am surprised we are even debating if the Birmingham in Alabama is as notable as the one in England, there is no debate, the UK one is more famous and important to world history unless you count lynchings or number of hillbillies."
I see from your userpage that you're from Staunton; I'm from that area as well, so it's interesting to me that you and I would have such differing views on the appropriateness of the word. To me, it's no more offensive than city slicker, bumpkinoryuppie, and quiiiiite a far cry from "coon", which, I agree, is the kind of word you'd not ever want to use outside of quotation marks. It will be interesting to see what other people have to say about this. 28bytes (talk) 02:17, 17 September 2013 (UTC)
Reply Strictly speaking, Fishersville—the hospital just happened to be in Staunton. We lived there till I was about five, then moved to Newport News. Our old house (formerly the Tinkling Spring Manse) now houses the offices of the Greater Augusta Regional Chamber of Commerce, and sits behind the Sheetz filling station.
I think "hillbilly" now is about where "coon" was in the 1920s: it's not always meant as derogatory, but it is always demeaning, if only in a joking way. And often it is meant in a very derisive and contemptuous way, as in the example I quoted above. (Search the Village Pump for "hillbilly", and you'll find two or three more gems along the same lines from the same person—who, by the way, has contacted me to inform me that she or he has not departed Wikipedia, implications on the person's user page to the contrary notwithstanding, and to warn me against using the term "coon" so freely.)
In any event, white Southerners who aren't mountaineers, such as myself and, I surmise, 28bytes, bear a special obligation in this regard, because historically our people have tended to look down on the mountaineers, too, and have been all too ready to accept and employ all the relevant derisive stereotypes and epithets. Similarly, white Southerners of middling social status and higher have traditionally had no problems with stereotypes and epithets based on other ethnic or class distinctions within Southern society, such as "redneck", "grit", "peckerwood", "coonass", "white trash", "trailer trash", "swamp trash", and so on. It behoves us to reflect, first of all, that all people are entitled to common, decent respect, unless by actual bad conduct they forfeit it; that prejudice is an ugly thing at best; and that putting other people down just for being who they are diminishes us, not them. If that's not enough, we ought to remember that many non-Southerners are happy to disregard these nice distinctions of class and ethnic group, and to deride all white Southerners en bloc with the same stereotypes and epithets. Some call us "hillbillies"; some call us "rednecks"; some smile and call us "Bubba"—just the way our great-grandfathers might have called a Pullman porter "George", or a black waiter "Sambo".
Prejudice isn't always hateful: sometimes it's just condescending. Stereotyping a group as figures of fun may not be as bad as making them out to be terrorists or thieves or rapists, but it still belittles them and tells them that we don't consider them worthy to be taken seriously. So the Li'l Abner-Jethro Bodine-Gomer Pyle stereotype is bad enough; but when people start talking about "hillbillies", it's usually not long before somebody mentions inbreeding and "Deliverance".
Is this even a serious proposal? You have got to be kidding me. Let's start with hillbillies not being exclusive to the American South. There are hillbillies in I assume all 50 US states to begin with. Second- it's not an ethnicity, even if you claim it is an exclusive term for whites (which would make it racist, not an ethnic slur, there's a difference). Third- there are Black hillbillies. And finally (humorously)- Who cares about hillbillies being offended? They wouldn't realize it anyways.Camelbinky (talk) 14:12, 17 September 2013 (UTC)
Oh, and I'm hardly a "now-departed Wikipedian", as you can see I'm still here, alive, and commenting with humor about hillbillies. For the record I live in Mid-Missouri (also called "Little Dixie" based on the Southern heritage of the original settlers and their slave-owning habits) where people are quite proud of being hillbillies, whether they be white or black.Camelbinky (talk) 14:23, 17 September 2013 (UTC)
Reply Sorry if I posted this in the wrong place—it's my first proposal, and I did try to do it right. I'm also not insisting on deletion. I'd be content with renaming the category, as I suggested in my initial posting. Jdcrutch (talk) 02:53, 18 September 2013 (UTC)
Wherever this winds up, I see no reason to delete, as this is not a racial, but rather a regional/cultural designation, akin to redneck. While on one hand the word "hillbilly" does originate in the south (if there are hillbillies in all 50 states, it's because they migrated from the south, elsewhere the word "redneck" is more descriptive), there are also words like OkieorYooper that carry similar regional connotations, which could be viewed as offensive to the people so labeled, but if the people themselves (nodding to southerners) have no real issues with it, then I'd say let it drop; no sense imposing PC on people who don't want it. Montanabw(talk)15:26, 17 September 2013 (UTC)
Reply What Montanabw calls "regional/cultural" I call ethnic. Broadly speaking, what we call "race" is just one kind of ethnicity; but for historical reasons it's entirely appropriate to treat race and ethnicity as distinct—though related—phenomena in American society. Ethnic and racial stereotyping are not directly equivalent, of course; but both are demeaning, and neither has a place in a serious academic setting like Wikipedia (except as a subject for study, like any other social pathology).
As with racial epithets, ethnic slurs may be benign or deeply hurtful, depending on who uses them, and in what context. Luke Jordan, a black man from Virginia, recorded a song called "The Travelling Coon", and another in which he sings, "I'm a hustling coon, that's just what I am." In yet another song, a couple of circus monkeys clearly stand for black people. Even so, I would hesitate to conclude on that basis that Jordan had no real issues with white folks' calling him a "coon" or a "monkey". The name of the band, "N.W.A." stood for "Niggaz Wit Attitudes"; but if somebody started a Wikipedia category called "Niggers With Attitudes", and I objected to it, I wonder if anybody would think I was trying to impose PC on people who didn't want it?
It would be nice if we could all be good sports, and take a joke at our own or our group's expense, when nobody means any real harm by it. Some of Shakespeare's most delightful characters are ethnic or class stereotypes. Ethnic/racial humor was a mainstay of Vaudeville and the early cinema, and some of it was genuinely funny. But in modern-day America we've become extremely touchy about such things, and most ethnic and racial stereotyping is strongly disfavored. In that context, it's just not right to have one or two groups whom it's still OK to ridicule.
I would say the people "themselves" do not find it universally offensive as the ethnic and racial slurs used by the original poster of this thread. And the "people themselves" are not just Southerners, as the article hillbilly points out, it includes people of the Ozarks, which are in Missouri as well as Arkansas, and Missouri is a Midwestern state, not a southern. Also, West Virginia is not a southern state, nor is Pennsylvania both of which have lots of hillbillies in their Appalachian sections. Please also note that President Truman, General Bradley, and JC Penney (all good Missourians) had no problem receiving a Hillbilly medal of distinction from the Springfield, MO chamber of commerce; the article also mentions a Kentucky town that has "Hillbilly days" festival, and I'm sure it isn't the only one. I fail to see that the African-American or Jewish communities would have a medal or festival named for "coon" or "kyke".Camelbinky (talk) 17:02, 17 September 2013 (UTC)
Missouri IS a southern state. If it was a slave state pre-Civil War, it's a southern state. Upper south, maybe, but the south. West Virginia was a "southern" state until it broke with Virginia at the time of the Civil War. I must say that hillbillies in Pennsylvania is news to me, got a source for that? Otherwise, I agree with Camelbinky. Montanabw(talk)01:57, 18 September 2013 (UTC)
Reply "TROUT" and "LP" are lost on me, I'm afraid. A neutral, encyclopedic rubric for the characters portrayed in "The Beverly Hillbillies" might be "Fictional Southern Mountaineers", as I suggested above. I personally might characterize them somewhat differently, but I'm not asking Wikipedia to express my personal views. Jdcrutch (talk) 02:53, 18 September 2013 (UTC)
For claiming to be a expert on wiki policy you seem to have some curious holes in your knowledge. TROUT refers to the glorously enshrined WP:TROUT. LP is a shorthand for Living Person as derived from WP:BLP. I don't understand how the whitewashing of the name does anything but make less clear the categorization. Also your recategorizaiton fails on the Beverly Hillbillies for the reason that they were never Mountaneers (Jed shot some game in his swamp and up came a bubblin' crude...). Even Mountaineers is an inappropriate categorization (See also Kilimanjaro Expedition) Hasteur (talk) 03:19, 18 September 2013 (UTC)
Reply Thanks for the explanations. I don't recall claiming to be an expert on anything. I do, however, know that the fictional Jed Clampett was said to be "a poor mountaineer". As for the appropriateness of "mountaineers", Hasteur will have to explain that to Appalachian State University's football team. Jdcrutch (talk) 04:16, 18 September 2013 (UTC)
Comment: I've not noticed this category previously. The name is pejorative (see Category:Pejorative terms for people). Most of the pages within that scope would fit in the more neutrally named Category:Works about AppalachiaorCategory:Appalachian culture (one reason why I say "most" instead of "all" is because there has been some heartburn at WP:WikiProject Appalachia in regard to the inclusion of Ozark Mountains topics). Since not all depictions of "hillbillies" are fictional (U.S. reality TV currently has a fascination with "hillbilly"-type characters), it's important to have non-pejoratively named categories for real people who might be considered hillbillies. --Orlady (talk) 03:10, 18 September 2013 (UTC)
Strongly oppose
I recognize that my proposed alternatives to "hillbilly" suggest a United States POV in using "Southern"; but less parochial alternatives like "Southern (U.S.A.) Mountaineer" seem awkward and contrived. I venture to predict that the average reader will readily understand "Southern" in this context to refer to the Southern United States.
We have hillbillies in the north too, thank you very much.
Wikipedia does have an article on the musical genre of "coon songs", while the equally offensive term, "Hillbilly music" appropriately redirects to Old-time music. Since "coon songs" are songs about stereotypical black American characters (usually presented in the persona of such a character), rather than the authentic musical expression of a group referred to as "coons" (although some "coon songs" were written by black Americans), it's appropriate for Wikipedia to cover the genre under its regrettable name. (I do, nevertheless, prefer to see the term "coon song" set off with quotation marks, as an indication that it was coined and used by others, in another time, and that its use today is in the nature of quoting those who named the genre, and not a matter of preference or choice.
Most hillbillies are proud to be such. I don't know where you get off calling it offensive.
Stereotyped fictional black American characters, such as Amos 'n' Andy, who might have been referred to as "coons" in former times, are listed on Wikipedia under the rubric Fictional African-American people.
So? Are you trying to say that because other stuff exists, that we should...?
OPPOSE. I must concur with the thought of keeping the category. It is just as important to keep it as it is to debunk it. How any of us feels about a word, or a slur is censorship simple and clear. Lest there be any confusion, I have been called a hill billy, a hick, coal camp trash, white trash, red neck, ignorant country fuck, ridge runner etc etc etc I actually had to learn to drop my accent, which took a few years. That and us country folk spoke a form of cajun french in the hollers, which only added to the fact that people in general believed us as a group and as individuals to be impaired or the term, dumb hick. As much as these terms caused me pain, it brings me greater pain to get rid of them. Ignoring a factual thing, even a slur, allows the slippery slop of forgetting and when we forget we repeat the ignorance over and over and over. Oddly, people need this stereotype. Thats how they used to sell all those cute little signs and salt shakers at gift shops. It makes money and brings in tourists. It still exists here on Wikipedia....GASP....Want an example? How about when myself or another person creates an article about a small town or community in Appalachia? I am told, it is not notable...Really? I have even been told, nobody would really care to notice. Were these things said to me personally? No. It is however, rather ignotrant to assume that a remote place is not notable. It might have had a post office, a coal mine, even had a building on the National Register of Historic places. Did it dawn on any of you, that if I buried people there, if I helped birth children there, if I watched people marry, I would question the NOT notable assertion? Most people who state its not notable, lets ask this, have you even been to these places? AND when I say been to these places, I do not mean you got lost. OR how about when the bulldozers come and take away the graves, the church, the schools, am I to understand, this is dome because, its not notable. Human beings by the sheer accident of birth may or may not be in notable place, AND we affirm this, because, no data could be found....I state, no data could be found YET. AND all of the cute terms, all of the clouded ambiguous language is not meant to make hicks feel better. THAT language is meant to make YOU feel better. From this self proclaimed hicks point of view, if the terms you seek are made to make you feel better, then SHAME ON YOU. Coal town guy (talk) 13:19, 18 September 2013 (UTC)
Oppose There's no reason why hillbilly must mean Southerner. Hillbilly as used by most people means a backward, old fashioned person. There's no reason why it has to target one group. Konveyor Beltyell at me17:25, 18 September 2013 (UTC)
Oppose. The idea of renaming the category to something with "Southern" in it raises my hackles. Being referred to as Southern can easily be perceived as a slur. I refer the reader to Southern Culture on the Skids. And yes, thereabouts is exactly where I am located. Fylbecatuloustalk17:48, 18 September 2013 (UTC)
Oppose as the term is not even offensive. Southern is much to vague, and could apply to many different countries with incorrect meanings. Being fictional implies no slur on any real people. Graeme Bartlett (talk) 11:18, 19 September 2013 (UTC)
Weak oppose. While I don't consider it a proper term for an encyclopedia, there are clearly fictional characters that are best described as "hillbilly." The designation should only be used for fictional characters, however. Bms4880 (talk) 06:12, 20 September 2013 (UTC)
comment - all current members of the category are not merely poor Southern hill whites, but stereotypical poor Southern hill whites. What do we do with somebody like Mike Stearns, who is a poor Southern hill white but does not meet the stereotype (although if you start dissing hillbillies, he will steadfastly identify himself as one)? --Orange Mike | Talk18:24, 20 September 2013 (UTC)
Bumping thread for 15 days. Technical 13 (talk) 14:24, 15 July 2013 (UTC)
Like--Mark Just ask! WER TEA DR/N 20:20, 10 August 2013 (UTC)
Roche.svg; I personally think that, after seeing some vandalism by IP's to some navboxes lately (particularly ones for media conglomerates for some bizarre reason), maybe we should consider only allowing registered users to edit templates (they would still be allowed in Template talk, of course, and maybe we can exempt sandbox pages from it as well).