Misplaced Pages

Revision as of 20:46, 7 August 2013

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

• WP:VPR
• WP:VP/PR
• WP:VPPRO
• WP:PROPS

New ideas and proposals are discussed here. Before submitting:

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

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Refining the administrator elections process Blocks for promotional activity outside of mainspace For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

Mass removal of old indefinite rangeblocks

There were a number of issues raised. Some came to clear consensus, others less so. The consensus can be summarized as follows:

1. 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.
2. 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.
3. 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)

Links -

• The first (failed) discussion on restricting RangeBlocks to CheckUsers which led to the current proposal
• The passes proposal at the VP, which was an RfC and also advertised at CENT

The general agreement in the previous discussion was -

1. All rangeblocks beyond a certain time period will be reviewed.
2. The rangeblock is reverted unless there is strong reasons not to.
3. All reverted rangeblocks are placed in a special category for monitoring
4. 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 agree that indefs shouldn't be used. I've never blocked any IP more than a year myself. Dennis Brown | 2¢ | © | WER 01:00, 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)

• Bumping thread for 15 days. Technical 13 (talk) 14:24, 15 July 2013 (UTC)

Technical 13 (talk) 14:24, 15 July 2013 (UTC)

Indefinite vs. infinite

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.) - jc37 15:14, 1 August 2013 (UTC)

Time period before review

How much time should it be before the previous rangeblock is reviewed?

1. 3 months
2. 6 months
3. 9 months
4. 1 year
5. 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)

• 6 Months if it's their first review. 1 Year afterwards. MM (Report findings) 12:58, 25 June 2013 (UTC)
• 3 months on first review. 6 months on second review and yearly after that. NinjaRobotPirate (talk) 13:35, 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)
• 1 year, since a 1-year block on a highly abusive IP range is standard. -- King of ♥ ♦ ♣ ♠ 00:51, 26 June 2013 (UTC)
• 1 year, per King of hearts above. Kudpung กุดผึ้ง (talk) 05:47, 26 June 2013 (UTC)
• 1 year, also per King of Hearts ·addshore· 09:42, 26 June 2013 (UTC)
• 1 year was my favoured time period too. Sounds best. TheOriginalSoni (talk) 12:09, 4 July 2013 (UTC)
• 3 year An indef block is given for a reason. The Banner talk 21:11, 6 July 2013 (UTC)
• 1 year. Sounds just right. -- œ 05:38, 8 July 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. Andrew 00: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. ϢereSpielChequers 22: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?

1. Bureaucrats only
2. A specialised elected/selected group of trusted editors (may be chosen along with one of the other options)
3. Administrators only
4. Administrators + Rollbackers
5. Administrators + Reviewers
6. Autoconfirmed
7. Everyone
8. 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) 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)

This is an eminently reasonable option as well. Sailsbystars (talk) 09:57, 26 June 2013 (UTC)

Yeah, this seems like a good solution. NinjaRobotPirate (talk) 13:23, 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)
• Everyone , because reviews will be decided on the weight of the arguments and not on a tally of the !votes. Kudpung กุดผึ้ง (talk) 06:07, 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)
• Callanecc's point sounds best. Everyone could participate, but only CUs should close it. TheOriginalSoni (talk) 07:11, 23 July 2013 (UTC)

Who monitors the activity

Which group of users will monitor the activity after the old rangeblock is lifted?

1. Administrators only
2. Administrators + Rollbackers
3. Administrators + Reviewers
4. Autoconfirmed
5. Everyone
6. 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: Same process as with any old IP. If they're acting up then drop em off at AIV. MM (Report findings) 13:02, 25 June 2013 (UTC)
• Everyone. Agree with previous users. NinjaRobotPirate (talk) 13:40, 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 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 - the more eyes the better. Kudpung กุดผึ้ง (talk) 06:25, 26 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 Mishehu 21: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)
• Bot if someone can make such a bot then why not? All the rangeblocks that WP has to deal with would be painful for a group of people to handle. MM (Report findings) 13:07, 25 June 2013 (UTC)
• Bot. Makes sense to me. NinjaRobotPirate (talk) 13:41, 25 June 2013 (UTC)
• A Bot does indeed seem like the logical path to follow! ·addshore· 17:20, 25 June 2013 (UTC)
• Agree, a bot is the correct course. Tazerdadog (talk) 19:57, 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)
• Bot sounds like a good idea. Kudpung กุดผึ้ง (talk) 06:26, 26 June 2013 (UTC)
• Bot sounds like a good idea to me as well, also see my comment related to a bot in the section above. Callanecc (talk • contribs • logs) 06:06, 17 July 2013 (UTC)

Blacklist?

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

NinjaRobotPirate but then there will be some proxy-offering websites, or permanent troubles who would better be handled with a blacklist. TheOriginalSoni (talk) 13:51, 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)

Sailsbystars, it is 200 indefinite ones. TheOriginalSoni (talk) 16:47, 25 June 2013 (UTC)

199 ;p ·addshore· 17:18, 25 June 2013 (UTC)

So Soni 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 them... Plain and simple... Technical 13 (talk) 22:44, 25 June 2013 (UTC)
• ROPE. Eventully, the guilty user(s) will be gone and it should then be unblocked. עוד מישהו Od Mishehu 21:42, 2 July 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)

• As proposer, Aye 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)

  Let ArbCom do it? XD MM (Report findings) 08:08, 28 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)

I have no idea what these two are. Could you please explain in a simple way too? Thanks. TheOriginalSoni (talk) 21:37, 26 June 2013 (UTC)

Examples of an ISP IP would be ones from Comcast or Verizon 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)

I Like This. I think we should. MM (Report findings) 08:08, 28 June 2013 (UTC)

• Final Note - If there are further topics of discussion, please add them as a section above this line.

Let's merge the idea lab to this pump.

The idea lab village pump is underused, and really insufficiently distinguished from this one to merit being a separate discussion area. The way in which this one and that differ is very ill-defined, and potentially confusing to new users (would they really want to "incubate" an idea?); so I strongly recommend that we "keep it simple, stupid!" and reduce the number of places for people to propose and discuss ideas for the site to just one. The traffic level at the idea lab is low enough that bringing it here won't make this page unusably busy.

Also, "The Four Pumps" sounds like a Motown quartet. That's not really a formal benefit, I just thought I'd mention it. — Scott • talk 12:22, 10 July 2013 (UTC)

• Proposals are plausible but Idea Lab is for dream features: This pump, wp:PROPS, is mainly for tangible improvements, with many easy to implement, while wp:VPIL allows for blue-sky dreaming, with some dreams realized here when more details are finalized. However, we want to keep the separation, to allow wp:VPIL to discuss a radical new concept for months, if needed, without being auto-archived in the rampant foot traffic of the numerous proposals here in wp:PROPS. -Wikid77 19:38, 10 July 2013 (UTC)

• Oppose. Switched to Conditional support below. -- Toshio Yamaguchi 15:23, 25 July 2013 (UTC) VPR and VPI should be kept separate. VPI is good for developing ideas through input from other editors, but if no judgement of whether the proposal is to be approved or rejected by the community is sought yet. VPR is where the community expresses whether they approve or reject a proposal. -- Toshio Yamaguchi 21:19, 10 July 2013 (UTC)
  • I've seen a lot of things get posted to VPI that would have made perfect sense to be posted here. They're usually barely commented-upon and then vanish into the archives forever. I've also seen posts on here get the kind of discussion that's apparently intended for posts over there. The separation is entirely artificial, inconsistent, and pointless. — Scott • talk 12:17, 12 July 2013 (UTC)
    • If we merge VPI and VPR into one board, how do we keep the distinction between proposals where voting should take place (Support, Oppose) and those where constructive input is sought in the form of discussion? I mostly use VPI when I want input from other editors to develop an idea. It needs to be clarified how one seeks input without voting here, if this merge takes place. -- Toshio Yamaguchi 06:23, 16 July 2013 (UTC)
      • That's just a matter of careful labeling and writing, which should always be a consideration when posting to this board anyway. — Scott • talk 11:40, 16 July 2013 (UTC)

• Support: Scott does have a valid point. The descriptions for the two pages have a lot of overlap, and the criteria for choosing one or the other is somewhat vague. It might be better to have separate pages based upon the scale or scope of the proposal—one for easy to implement ideas and the other for major projects. Praemonitus (talk) 15:11, 13 July 2013 (UTC)

• Comment: If this merge takes place, should Misplaced Pages:Village pump (miscellaneous) also be merged? The purpose of that one appears to be even less well defined than that of VPI. -- Toshio Yamaguchi 06:30, 16 July 2013 (UTC)
  • VPM does have a clear purpose... it's the "if your post doesn't clearly fit the other boards, post here" zone. The distinction between this and VPI is what's unclear. — Scott • talk 11:40, 16 July 2013 (UTC)

• Oppose. The distinction is very clear. Proposals is where you post a proposal and it either gets accepted and implemented or rejected. If you come unprepared, it will most likely fail the scrutiny. In Idea lab you post an idea, it will not be implemented after the discussion whether response is positive or negative. It will be a foundation for a proper proposal. And it is not that Idea board is slow and should be merged, it is that Proposals board gets ideas that have barely been fleshed out and should be split into a dedicated board. I find this distinction very clear, and I never had any issues with this. Idea lab being slow only tells me most editors believe they have fleshed out their proposals and are ready for a yay/nay kind of critique here. —  HELLKNOWZ  ▎TALK 10:59, 16 July 2013 (UTC)

• Comment. What about abandoning VPI and marking the proposals at VPR using something like

Proposal for acceptance or rejection

Idea for discussion

to tag a discussion here? Then it would be clear whether the proposer intends it as a proposal to be accepted or rejected or an idea to be developed. -- Toshio Yamaguchi 12:14, 16 July 2013 (UTC)

And then again the proposer could have directly posted it to the correct VP in the first place. The distinction we have is clear and it makes sense in my opinion. The problem is users not thinking enough about it before posting a new proposal or get spoiled to post to the higher frequency sub-pages (e.g. technical instead of proposals) to get more responses. --Patrick87 (talk) 12:21, 16 July 2013 (UTC)

You know, I just have to point out that Toshio's excellent suggestion above is the sort of thing that, ostensibly, should be posted to the other pump. And yet here it is, on a post that originally started out as a "let's do this" proposal. See what I mean? Discussions are naturally fluid, and separating them by type is a really artificial thing do to. — Scott • talk 21:26, 16 July 2013 (UTC)

+1 TheOriginalSoni (talk) 07:31, 19 July 2013 (UTC)

• Conditional support. I support this if we also adopt the mechanism I suggested above (or a similar one). -- Toshio Yamaguchi 15:23, 25 July 2013 (UTC)

• Comment Many people tend to decide they dislike ideas as originally described and stop there, regardless of any request to do otherwise. Offering suggestions that might make the proposal more acceptable is something that not everyone is capable of doing -- many lack the capacity to imagine changes that would make them like the ideas they see. They instead feel the need to voice their opposition. You can create labels to discourage that (and it is a good idea), but I suspect that stalwart "opposing" comments will still be rampant, even if not referred to with big bold Opposes. Idea Lab was started recently-ish as a haven from the de facto voting and has only been around a fraction of the time the other Pumps have. It may just need more time to catch on, and maybe better marketing. Just food for thought. I have no real opinion either way on this. Equazcion 16:45, 25 Jul 2013 (UTC)

Well, that's really a cultural issue. I've heard people say that "the Village Pump is where good ideas go to die"; we should try to encourage a culture of positivity and creativity, rather than allowing an endless chorus of "no way"s and "that would never work"s and "if it ain't broke don't fix it"s (the most pernicious of the lot). — Scott • talk 12:42, 27 July 2013 (UTC)

I would sell my left cyber-pinky to remove "if it ain't broke..." from Misplaced Pages's vocabulary. The number of improvements that eventually resulted from proposals that had to be repeated ad nauseum due to being shot down by naysayers with zero imagination is staggering. Do you have any idea how many years "Did you mean..." was a common feature for all major websites' search engines while proposals for it here kept getting shot down as somehow infeasible? MANY, is the answer. But I digress. In the end I don't know how to solve this problem but I like the label idea. Whether or not Idea Lab is closed down, the labels should be created and their use encouraged everywhere. We should distinguish between votes and idea development. I would just change the "Idea for discussion" language because it would be appearing alone and doesn't actually discourage voting as is. Perhaps an accompanying linked essay page with further explanation. Equazcion 14:44, 27 Jul 2013 (UTC)

• Support. I think VP: proposals, perennial proposals, idea lab, and policy all should be merged/renamed to two pages: VP:Brainstorming discussions (or some such name) and VP:Straw Polls. - jc37 15:24, 1 August 2013 (UTC)

  Ideally that would be good, although it might make for two pretty big village pump pages. Equazcion 21:35, 1 Aug 2013 (UTC)

  Not really, just state at the top that if any discussion or straw poll exceeds X number of bytes, then it is split to a sub page (and replaced with a navigation link to said subpage). QED : ) - And that means that brainstorming sessions can potentially stay open ad infinitum. (And marking hostorical and potentially restarting discussion obviously falling under the same guidelines that we follow for any discussion or project page.) - jc37 19:47, 2 August 2013 (UTC)

  I think I like that idea. I'm not sure if it could gain traction but I like it. Equazcion 19:55, 2 Aug 2013 (UTC)

  (ec) - Actually, better idea: merge the VPs for proposals, perennial proposals, idea lab, policy and misc. (or in other words, all VPs except Tech) and set up the VP like WP:CFD/WP:DRV, etc. (I've long been wishing the admin noticeboards were set up like this.) Any board which has this much daily volume could be set up this way. And so, due to each page being daily, it sets itself up for self-archiving. And thus, it makes for much easier finding of past discussions (and permalinking to them), and even just having a central discussion location. And if volume for whatever reasons apparently doesn't justify daily pages, then it's easy enough to switch to weekly or even monthly, as needed (We did this a while back for WP:MRV it didn't need daily logs, like WP:DRV has, so we switched to monthly ones.) But of course the outcry would be similar to your comment above concerning "if it ain't broke"; though imnsho, I think that the copy/paste archiving of high volume noticeboards is a "broken" system for various reasons, not the least of which the technical one of having a single page with a ridiculously long edit history for no actual purpose save that "we've always done it that way". - jc37 20:11, 2 August 2013 (UTC)

• Comment. Per @Toshio Yamaguchi:'s idea above, I created {{pifd}} and {{pfa}}:

Template:Pifd Template:Pfa

Equazcion 21:05, 1 Aug 2013 (UTC)

Thank you. The templates look good to me. -- Toshio Yamaguchi 21:22, 1 August 2013 (UTC)

Thanks. I think it'd also be great to have an essay for these to link to that would further explain the difference. I might create one at some point but if anyone wants to get one started feel free. Equazcion 21:35, 1 Aug 2013 (UTC)

• Comment. Apparently there's some resistance to using the Proposals page this way. Equazcion 15:07, 2 Aug 2013 (UTC)

Desysop / reconfirmation RfA proposal

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:

1. 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.
2. 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.
3. 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.
4. 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:

1. 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.)
2. Each individual bureaucrat may only make 3 reconfirmation selections in a calendar year.
3. The bureaucrat who selects a candidate for reconfirmation cannot close that reconfirmation RfA.
4. 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.
5. 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?

3. Would there be a "call for the question "/petition process by others to bring to the Crat's? Thanks. Alanscottwalker (talk) 16:08, 13 July 2013 (UTC)

• • 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. PumpkinSky talk 16:11, 13 July 2013 (UTC)
• Support — Ched :  ?  16:14, 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.
  • --Bbb23 (talk) 16:31, 13 July 2013 (UTC)

• 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¢ | WER 16: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)
• Perhaps if private info is involved (say CU or OS info), ArbCom should continue to handle it? --Rschen7754 17:09, 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 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.5 18:16, 13 July 2013 (UTC)

  I have the following experience which happened on the Russian Misplaced Pages 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 Misplaced Pages has been rather worse than yours. I am aware of the following that could reasonably be called reconfirmation RfAs: Misplaced Pages:Requests for adminship/SarekOfVulcan 2 (72% support down from 87% in their first RfA), Misplaced Pages:Requests for adminship/HJ Mitchell 3 (95% up from 85%), Misplaced Pages:Requests for adminship/Herostratus 2 (62% down from 79% and unsuccessful), Misplaced Pages:Requests for adminship/Crzrussian 2 (86% down from 99%), Misplaced Pages: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.5 14: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.5 19: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

1. 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.
2. 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.
3. 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). PumpkinSky talk 18: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)

Let's say … a subpage of WP:BN?--Wehwalt (talk) 20:45, 13 July 2013 (UTC)

Yes that makes sense—leaving it unsaid does not, IMO :) John Cline (talk) 21:31, 13 July 2013 (UTC)

• Bottom line, I support the initiative. :) John Cline (talk) 23:44, 16 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. Jusdafax 21: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 Misplaced Pages. Any further concerns within the 'protected' time frame should be directed to arbcom. Resolute 23: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? Resolute 00: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. Resolute 02:20, 14 July 2013 (UTC)
• Support per Bbb23. Andreas JN466 00:52, 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 Misplaced Pages community at large should be asked to approve this concept as well, which I imagine would involve a Wiki-wide Rfc. Jusdafax 01: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)
• Strong support yes, probably the best idea I have seen yet. AutomaticStrikeout  ?  03:22, 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 Misplaced Pages 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↗ 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 Misplaced Pages 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 administrators made in 2007-2008. Kiefer.Wolfowitz 08: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· 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. Acalamari 11: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. Salvio 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. - MrX 15: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| 17: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 | ✌ 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:

1. If the admin loses the reconfirmation vote, and accepts the decisions, no one should be able to appeal.
2. 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 Misplaced Pages 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. — ΛΧΣ 03: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. Steven Zhang 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 Misplaced Pages: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.PumpkinSky talk 22:11, 16 July 2013 (UTC)
• Oppose - Per TenOfAllTrades, likely to lead to harassment of bureaucrats. Gatoclass (talk) 16:47, 15 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. --Jayron32 00:16, 16 July 2013 (UTC)
• Oppose Misplaced Pages 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.PumpkinSky talk 22: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 Real accountability is needed here, and part of that is the ability to remove tools. Intothatdarkness 14:08, 17 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 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 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. Wizardman 19: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. Wizardman 19: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)
• Support. Per Wizardman. I want more than this offers, but I don't think I'm ever going to get it... — This, that and the other (talk) 10:44, 25 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? - jc37 15: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)

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~~ → report 11:35, 21 July 2013 (UTC)

Some problems and solutions:

• WP:AN will be even bigger
  • Discussions that have no chance of succeeding may be closed by WP:SNOW.
• People just can't let go of their grudges
  • Isn't that human nature? Some have grudges, but most do not, the request is rejected.
• When a sysop does something, a party will ask for de-adminiship
  • Yes, they'll try. I have confidence in the system as there is the other party who then like the sysop.

~~Ebe123~~ → report 11:51, 21 July 2013 (UTC)

"Edit source" is a misleading label and should be changed

See Misplaced Pages talk:VisualEditor#"Edit source" is a misleading label and should be changed.--Fuhghettaboutit (talk) 15:54, 28 July 2013 (UTC)

See also:

• Misplaced Pages:Village pump (proposals)/Archive 104#Relabel the "Edit source" tab so it reads "Edit wikitext" (10 July 2013)
• Misplaced Pages:Village pump (technical)/Archive 114#Changing the labels on the "Edit" (VE) and "Edit source" tabs (8 July 2013)

I don't understand why there is no reaction from developers to this issue. I think a lot of pushback to VE is caused by the fact that for section editing, the regular link is hidden until the "primary" link to VE is moused over (so the wikitext editor can't be found at once, although preferred by most everyone). --Atlasowa (talk) 16:25, 28 July 2013 (UTC)

I created a registered user account simply for the ability to go into Preferences and "hide" the Visual Editor option. Now "Edit" just means old-style editing. I was forever hitting the wrong button and going into Visual Editor only to have to hit Cancel. Must have done that a hundred times since the system changed over. I think VE is confusing to anyone who is used to using Wiki formatting. Newjerseyliz (talk) 18:03, 28 July 2013 (UTC)

They're planning on changing the appearing-wikitext-section-edit links. It is too distracting for many users, and too complicated to use on touchscreen devices. bugzilla:50540 seems to be the main entry. I'm not sure when the fix is due, but I suspect soon. –Quiddity (talk) 03:10, 29 July 2013 (UTC)

Thank you for the bugzilla link, Quiddity. So this has been pointed out for weeks, but is rejected/stalled by WMF because stable section links would add "clutter"...? But on the other hand, a mouseover link (that unexpectedly takes you to the visual editor if you click it) and forces you to hover and follow the decollapsing with the mouse (and try to click it) is OK, despite bad usability (especially on touch screens). Wow, unbelievable. Oh and the big joke is that actually you can not edit sections with the visual editor, just the whole page, but you can edit sections (faster!) with the wikitext editor! This bug could have been fixed for weeks, before the roll-out to dutch and german Misplaced Pages. Apparently WMF thinks it's OK to confusingly reassign to edit visually and trick unwilling editors into using the visual editor. Apparently WMF doesn't give a damn about wasting vounteer editors time... This is beyond me. And this not just hardcore editors that prefer wikitext editing, according to VE usage stats by Dragons flight (Misplaced Pages:VisualEditor/Feedback/Archive_2013_2#Some_performance_notes) of July 17/18:

As shown, the individuals most likely to choose VE are newly registered user accounts. Anons are only a little more likely to use VE than registered users. This suggests that many of the individuals who edit anonymously were actually familiar with the source editor and continue to prefer it even though they edit anonymously. (That's rather surprising to me.) Even though new users are most likely to choose VE, they still go with source editing 2/3 of the time. Since the introduction of VE, article editing rates are down slightly. For the length of time considered, a change less than about +/- 6% is consistent with random variability, so these fluctuations are not necessarily indicative of anything. However, it will be interesting to look at changes over a longer time period. Whether or not there is a meaningful drop, we can probably rule out the possibility of any large immediate editing surge as a result of VE's introduction. Of course, this only looks at the short-term reaction to VE. Only time will tell whether VE ultimately becomes popular. Dragons flight (talk) 03:56, 18 July 2013 (UTC)

Someone on Bug 50540 - VisualEditor: Display both "edit" and "edit source" links for sections without hover commented: "Put thought in it! I could imagine, that this decision will determine whether people will be disabling/hiding VE or keep using it along with the Wikitext editor." I absolutely agree! See also Misplaced Pages:VisualEditor/Feedback/Archive_2013_07#Edit_and_edit_source_links_so_confusing_I_had_to_disable_Visual_Editor_in_preferences and Misplaced Pages:VisualEditor/Feedback/Archive_2013_07#Note_the_many_unhappy_people_who_do_not_see_the_HIDDEN_.22edit_source.22_link and Maggie Dennis 2013-07-02: "Note that this request is being repeated a lot, including by people who are unhappy that mousing over causes words to pop up, which they say disrupts reading the page. They would prefer the words be always visible to avoid this."

And indeed, users are choosing "Remove VisualEditor from the user interface" (en:MediaWiki:Gadget-oldeditor in en:Special:Preferences#mw-prefsection-gadgets):

• 4. Juli: 607 user choose "Remove VisualEditor from the user interface"
• 11 July: 1018 user
• 18. Juli 1300 user
• 25 July: 1473 user

There is a CSS workaround at Misplaced Pages:Village_pump_(technical)/Archive_114#Removing the animation from "edit source" section links on Visual Editor (10 July 2013), currently, 17 user are using this CSS. But this can't be the solution! --Atlasowa (talk) 08:45, 29 July 2013 (UTC)

I point out that 'wikitext' though technically correct is totally confusing for newbies. For them it will read "text of the wiki" most likely. "Edit wiki | text mode" or something like that might be a better choice. —TheDJ (talk • contribs) 08:58, 29 July 2013 (UTC)

Why not Edit (GUI) | Edit (text) ? That's the version used in other wiki variants with GUI. Adam Cuerden 09:07, 29 July 2013 (UTC)

Newbies can't know already what "edit wikitext" or "edit markup" means, but they'll learn immediately by seeing it when clicking. The important thing is having unambiguous words for both ways of editing. Because editing is fundamentally important to Misplaced Pages and we talk a lot about it. I think "source" has too many different meanings (source=reference, "You messed up the source"? "just copy the source text from another article"?) and "edit" can mean 2 different methods from now on ("When editing the article, click on button XY and add ABC"?) How about "edit visually" and "edit wikitext"? And looking a little bit forward: mobile Misplaced Pages uses icons for navigation, the edit button is a pen icon similar to this: . So how about for "edit visually" and for "edit wikitext"? --Atlasowa (talk) 09:37, 29 July 2013 (UTC)

We could play with colours to make the 2 pen icons easy to distinguish visually:

for: "edit" (easily, visually)

for: "edit wikitext" or "edit markup"

Other ideas? --Atlasowa (talk) 10:13, 29 July 2013 (UTC)

Any version of the options where one option is "text" (or "text mode") will still be confusing. Both modes involve editing text, so don't count on that word making any sort of distinction. "Edit Direct" and "Edit Source Code" might be one clearer possibility; but really I doubt there's any option that'll make the difference immediately obvious to most people. It was never even all that obvious what the plain old "edit" link did. People are going to learn what these do through trial and error, as always. Equazcion 09:29, 29 Jul 2013 (UTC)

Just saw the discussion on the Wikimedia Design mailinglist thread VisualEditor section links redux. Erik Möller's suggestion "would be to take a similar approach to the mobile site: have an icon for section editing (e.g. pencil) and maybe a different one for source editing (e.g. "<>" which is commonly used to switch into source mode in RTEs)." He later concludes as "probably the best short term option > The hover effect is easy to drop - if we are all willing to take the hit on the clutter." Still, nothing is changed. --Atlasowa (talk) 09:33, 31 July 2013 (UTC)

Now Erik Möller on Wikimedia mailinglist: "Any idea of when we can expect the change?" "Last time I discussed with Trevor he mentioned that it was a trivial fix (we just need to remove the hover effect), so let me bug them tomorrow :)." So apparently the hover effect will be removed in the next days, but the labels "" will stay. --Atlasowa (talk) 09:41, 31 July 2013 (UTC)

Per the discussion at Misplaced Pages:VisualEditor/Default_State_RFC#Question_4: Should the user interface explicitly warn editors that pressing the "edit" button is using beta software?, whatever label is used for the Visual Editor needs to include the word "beta".—Kww(talk) 19:33, 31 July 2013 (UTC)

The problem with "edit source code", "edit source", "edit wikitext", "edit markkup" etc. is that a user doesn't really have to know anything about "source code", "source", "wikitext", and "markup" to edit constructively. Having such technical terms on the tab will intimidate many users who may think that it requires extensive knowledge of a computer language or markup style in order to edit. Adam Cuerden's suggestion "Edit (GUI) | Edit (text)" appears to be a much more user-friendly option.--Wikimedes (talk) 18:59, 3 August 2013 (UTC)

"GUI" is just as technical as "wikitext" and "markup", and won't simplify anything. As for "edit text", this would suggest to many users that there is one button to edit the text of the article and one button to edit something else (the layout? the interface?) Andrew Gray (talk) 19:22, 3 August 2013 (UTC)

Got me thinking of the way consumer software marketing usually handles these situations. How about "Edit" and "Easy Edit " ? Equazcion 19:37, 3 Aug 2013 (UTC)

Too few would be willing to call VE "easy". "Edit" and "Edit" would be more neutral. Mysterious Whisper 20:08, 3 August 2013 (UTC)

Perhaps veteran Wikipedians might be willing to put their opinions on the state of the software aside in favor of terminology that'll be more commonly understood by the masses. The new software is intended to be easier once it's out of Beta. That fact that it currently has flaws is covered by displaying the term "beta". Equazcion 20:12, 3 Aug 2013 (UTC)

My point exactly. When Yahoo! Mail introduced a new layout, the old one was referred to as Yahoo! Mail Classic. (And I believe the newer layout was, for a time, offered as Yahoo! Mail.) I've seen similar elsewhere, so this phraseology should be familiar to anyone with some computer experience ("commonly understood by the masses."). Calling the original Classic and the new, currently-being-beta-tested one Beta, confers no opinions, and seems the most likely to communicate the necessary information without unnecessary confusion. Then, if-and-when VE is out of beta, we can still have "Edit" and just "Edit". Mysterious Whisper 20:24, 3 August 2013 (UTC)

Or Edit and Edit; something along those lines. I don't think "beta" is likely to be too confusing/offputting; Gmail labelled itself "beta" for five years without distressing the world, and matched with "old" there's a clear distinction even if you're not familiar with "beta" (= not old). Andrew Gray (talk) 20:25, 3 August 2013 (UTC)

I'm concerned "old" may have negative connotations that "classic" (and "beta", for that matter) doesn't. I've seen many instances, in software and otherwise, where the original version is called "classic" to differentiate from a newer version; I can't recall ever seeing something that continues to be offered officially referred to as "old" by those offering it. Mysterious Whisper 20:39, 3 August 2013 (UTC)

I propose it say , since the beta warning pops up anyway. Keep it simple. — Confession0791 09:40, 4 August 2013 (UTC)

Per most of the above, do you think a completely new user is going to understand what is meant by "code" and "visual"? (Sidebar: Does anyone know where the text of the new "warning" message, and the fact that if apparently only comes up the first time you open VE, was discussed?) I still like "Edit" and "Edit" because it's the most like what I've seen elsewhere (and, thus, the most familiar to your average non-wikipedian computer user). Mysterious Whisper 11:51, 4 August 2013 (UTC)

I find it improper for an encyclopedia to use a wrong term on the very top of all articles. "Edir source" clearly implies "Edit source code" ("For the purpose of clarity ‘source code’ is taken to mean any fully executable description of a software system."). Source code is all the HTML, the CSS, the scripts, most of which we do not see. If your browser has a "view source" option, take a look at an article to see the difference. "Edit" should remain "edit". A new term should be used for the VE and it would better be a term which encourages new users to think of it as a first step to learning Wikimarkup. Hoverfish Talk 13:04, 4 August 2013 (UTC)

Yes. Or in Misplaced Pages it could mean editing the references.

I think it's important to put the type of editor in parentheses or as a superscript to show that it's the type of editing interface rather than the thing you are editing. So "edit (Wikitext)" or "edit would be greatly preferable to "edit Wikitext". Even "edit (markup)" is not too bad, but for me "edit (text)" is still preferable to Wikitext or markup.

Fair enough that GUI is just as technical as Wikitext, etc.; "edit (visual)", "edit (VE)", or "edit (VE beta)" would be better. "edit (easy)", however, reflects a personal opinion that won't be shared by all editors, and is not descriptive of the editing mechanism.

I'm not convinced that there is a neutral single-word descriptor that will adequately describe the differences, hence my suggestion of labeling both simply "Edit", but with "" for the classic editor and "" for the currently-being-beta-tested one. Concise, neutral, and familiar to most. An actual, multi-word description of the editors can appear when ones cursor hovers over the link, as is already done (right now, Edit = "Edit this page with VisualEditor"). Mysterious Whisper 19:26, 4 August 2013 (UTC)

Wikipedians' devotion to neutrality should really remain confined to article development. It's silly to refrain from calling the new and old editors one thing or another for fear of offending someone who likes one over the other. The priorities being discussed here are completely screwed up. The focus should be easy recognition to the common user, and "Edit " vs. "Edit " are not descriptive; How is anyone supposed to have any clue what either of those do? Those labels do nothing more than suck any meaning out in favor of diplomacy for our silly internal drama. Equazcion 20:31, 4 Aug 2013 (UTC)

Two problems. The first is practicality: just because "Wikipedians' devotion to neutrality should really remain confined to article development," doesn't mean it will. Wikipedians are sharply divided here; anything that doesn't sound neutral has zero chance of gaining consensus. The second problem is: can you describe, in two words or less, to someone who has not experienced either editor, what the differences are? I don't think it can be done ("Easy" won't cut it). Hence why I pointed out the hover-over text in my above comment; it's the only way we'll be able to convey all the necessary information. And, with that, the tabs themselves only need to be differentiable, and can and should be nondescript. (Although "classic" for the classic editor and "beta" for the being-beta-tested editor do convey some important information.) Mysterious Whisper 20:47, 4 August 2013 (UTC)

When it comes to certain software matters, consensus isn't necessarily vital. If the WMF is convinced that something will benefit Misplaced Pages's reach then it'll probably happen. "Easy" conveys much more than mere "beta". Someone seeing "beta" won't know what to expect in any way; it could mean a more advanced editor with more complicated features. For the many people who may have tried clicking "edit" before and found that they didn't understand what was going on, or worse, made an edit only to have it reverted because they inadvertently screwed something up, the fact that there's an "Easy" version in the beta stage will convey a lot. Equazcion 21:11, 4 Aug 2013 (UTC)

Note that the title of the section is ""Edit source" is a misleading label and should be changed." It seems most are happy with "Edit ", the real issue it what to call the other one (which, as near as I can tell, you haven't addressed). That aside, we both know that WMF would love to label VE "Easy" (in fact, the call it 'the new, easier way' or somesuch in the new pop-up message you now get when first opening VE), we know they'd gladly do it against consensus, and we know that if they did, there would be public uproar, and then we'd be right back here, under the heading ""Easy editor" is a misleading label and should be changed." Mysterious Whisper 21:18, 4 August 2013 (UTC)

I have indeed addressed it. The name for the traditional edit feature should be changed back to "Edit", since "Edit source" is indeed misleading. The fundamental issue is how to differentiate the two, and calling the new one "Easy" is the best way to do that. You obviously disagree that the new version is actually easier right now, and I'm actually with you there, but whether or not it's actually "easier" isn't the issue. The question is how to communicate what it's intended to be. Many people will assuredly find that it doesn't work well yet, but most internet users understand that "beta" means "we're still working on it". Equazcion 21:27, 4 Aug 2013 (UTC)

I never stated my opinion on VE, and I haven't !voted at RfC, so I'll thank you not to assume. I've merely been pointing out that the majority of editors would not allow VE to be labeled "Easy" (as shown by the RfC and comments elsewhere), and that anything other than a neutral name will bring us right back here for a nearly identical discussion. VE is intended to be the Misplaced Pages editor, so eventually calling it just "Edit", and calling it "Edit " while it's in beta testing, both makes sense and is not likely to be challenged. But then we can't call the old editor "Edit" too, hence "Edit ". Given that, and your own opinion that VE has not yet proven to be "Easy", I can't fathom why you'd want to give it such a title. Mysterious Whisper 21:49, 4 August 2013 (UTC)

I'm much more concerned with finding the method that would be best in general, rather than finding the one most likely to be agreed upon by this community. I've explained my reasoning behind using the word "Easy". If you want to address the reasons I've stated already, feel free. Equazcion 21:56, 4 Aug 2013 (UTC)

The two qualities (the "best in general" and "the one most likely to be agreed upon") are not always mutually exclusive and, IMO, mine satisfies both (I, too, have already explained why). But we clearly don't agree. I am curious to see what others think. Mysterious Whisper 22:03, 4 August 2013 (UTC)

Note: bugzilla:50540 is fixed, see Misplaced Pages:VisualEditor/Updates/August 1, 2013:

• changing the section edit link order to say "".
• For consistency, "Edit" is changed to "Edit source" in namespaces where VisualEditor is not enabled.
• The section editing animation (progressive disclosure), which many users found annoying and confusing, is disabled.
• Users clicking the "Edit" tab now get a first-time modal message (users cannot interact with editor before they dismiss it) informing them that they're using VisualEditor, warning them that issues may occur, and thanking them for any help with testing and reports.

With these changes, I will not disable the Visual editor in my preferences but will keep this default. (I still think that "edit source" is not ideal. We have to update help documentation to include VE editing and will have to explain that "edit source" and "edit references" are not synonyms and to write sentences like "to beta edit, do ABC", "to source edit, do XYZ".) I will use Visual editor for appropriate edits and will test Visual editor from time to time on more complex edits. I will also opt-in to VE beta on german Misplaced Pages (""), since I am no longer forcefed an editor with limited usefulness. Thank you for the changes to all involved! --Atlasowa (talk) 09:30, 5 August 2013 (UTC)

I'm interested in this issue. This type of conversation has happened in several places, and the result is pretty much the same as usual: no consensus. If you haven't seen the others, I think the only common points you're missing here is someone saying that wikitext isn't source code on the grounds that HTML isn't source code either (this is apparently a point of contention between the Real Programmers™ and HTML users), and someone else saying that it ought to be called "Edit source" because fully protected pages always say "View source" (a very logical idea, since consistency is helpful to users). Personally, I kind of like the suggestion of "classic", which most people will correctly interpret as a friendly way of saying "older", but it has not proven very popular at other discussions.

There are two main uses that might be relevant, and IMO the people here are qualified to comment on both. The first is what we want just at the English Misplaced Pages. This can be changed at any time. WP:There is no deadline for making this decision. We've changed between "Talk" and "Discussion" over the years, and there's no reason why we couldn't do that for these labels. The other is what would make sense to users at thousands of other wikis around the world. There are about 800 or so WMF wikis. What would you suggest to translators? What would you suggest to Commons or Wiktionary? What would you suggest for private wikis (e.g., in a non-profit organization)? Mediawiki has been getting requests for help with installing VisualEditor on people's private wikis, and the software has to come with a default label for each tab. Each of these could choose whatever it wants, but probably most will use the default. It is possible that what's best for the English Misplaced Pages is not relevant for these other wikis. For example, Commons probably wouldn't mind "Edit source", because it's not a reference-oriented project. But Wiktionary, which already has a separate namespace for citations, might find "Edit source" to be even more confusing than it could be here. So if you have an opinion, even if it's "do this here, but do that for most places", please feel free to share your opinion with me. (At some point, it would probably be useful to make a complete list of all the suggestions made so far.) Whatamidoing (WMF) (talk) 18:12, 5 August 2013 (UTC)

I've said this above but just for the record, I think the discussion is excessively pedantic and focused on what the internal die-hards would find comfortable. The priority should be the general populace. Label the new editor "Easy ". It conveys the right message ("We're working on an easier way to do this. Wanna try it out?") and does so with very few characters. Seems like that would work for every language and project. I feel this is one of those instances where the WMF should fire up those convenient market-driven instincts that take over when the dorks of the Misplaced Pages community can't seem to see the big picture. No offense to any dorks who might have been offended. Equazcion 18:22, 5 Aug 2013 (UTC)

Great to finally have an "official" statement here, with some moderation we might reach consensus eventually which was not the case so far (as you mentioned). To directly give some feedback:

• Make this change for all Wikis (e.g. directly in MediaWiki source) and hope translation works well. At least on German Misplaced Pages I'd say the problem is exactly the same. Otherwise we might have fixed it here on enwiki but nowhere else (not even in the English versions of other Wikis) which is not what we should aim for.
• The "Edit source"/"View source" analogy: I totally concur that it would be great to have it consistent – but not by keeping "source". If we pick something like "markup" or "Wikitext" both labels could be replaced. If we take "Edit (classic)" or the like we surely will loose this consistency (which is why I don't like it).
• "Edit Wikitext" would be my current preference. After all, Wikitext is something unique here on Misplaced Pages (we can be proud of it)! And it will be a unique label which is what we want after all to prevent ambiguities. It perfectly describes what the button does by definition, and eventually it will be recognized broadly – editors are not dumb after all and will quickly learn what Wikitext is (if they did not know yet).

--Patrick87 (talk) 18:34, 5 August 2013 (UTC)

I agree with Patrick87. Naming should be consistent, "edit (classic)" doesn't work for "view (classic)". "Edit wikitext" would be my current preference too. I think "" are a decent, almost uncontroversial ;) choice for enWP. This should also be most universally translatable, "beta" and "wikitext" are very short and far less confusing than translations of "easy" or "classic" or the ambiguous "source"-

• Looking at french Misplaced Pages, they were recently surprised by a new tab "modifier la source" (which is confusing), considered changing it to "modifier le source" (which is even more confusing) and just now apparently settled on "modifier le wikicode". in the documentation fr:Wikipédia:ÉditeurVisuel it still says "Vous pouvez continuer à utiliser l'éditeur classique de texte source (wikitexte) via l'onglet « modifier la source »" - "You can continue to use the classic source text (wikitext) editor by the link « edit source »". VE was activated for registered users (fr:Wikipédia:Le_Bistro/24_juillet_2013) and for IP editors on July 29 (fr:Wikipédia:ÉditeurVisuel/Avis) and a lot of complaints and bugs, but the french didn't go berserk like the Germans or providently deactivated VE like the Dutch. But i would like to see stats for french deactivation of VE in preferences (this should be available somewhere on the toolserver).
• I see that Whatamidoing is already watching feedback about VE on polish WP (pl:Misplaced Pages:VisualEditor/Opinie), russian WP feedback is rather grumpy. --Atlasowa (talk) 01:31, 6 August 2013 (UTC)

WP:RA

Requested Articles needs to be cleaned. There are thousands of items in there, many of which are requests for unnotable companies. Please see WT:RA for a major proposed change. Matty.007 11:19, 1 August 2013 (UTC)

Note: I've moved the discussion from here to WT:RA#Changes, since the proposal has a huge impact on how Requested Articles are handled, and that seems the best place to discuss and document the proposal. -- John Broughton (♫♫) 02:44, 2 August 2013 (UTC)

Enable "Add an link for the lead section of a page" by default

I just found this feature. Had it been on by default, it would have made editing more convenient and less cumbersome. I can't think of a good reason not to make it the default. One could argue that brand new editors may click on the wrong "edit", but it's obvious what's happening if they do. You could call it "edit lead section" if that is a concern. Vzaak (talk) 18:42, 1 August 2013 (UTC)

Can't agree with you more!--RekishiEJ (talk) 11:36, 2 August 2013 (UTC)

Wouldn't it add yet more distracting clutter to the lead section? There's already a lot of interface content in the form of hatnotes and cleanup templates that detract from the actual article. Praemonitus (talk) 00:03, 4 August 2013 (UTC)

I might suggest perusing the archives for this topic. It's become perennial by this point. --Izno (talk) 02:42, 4 August 2013 (UTC)

It's not in WP:PERENNIAL. In the archives I found many suggestions to turn the link on, which would support making it the default, as well as the discussions here and here, which appear majority positive about the change. The reason for the holdup seems to be a technical matter about integrating into common.js, and whether the link will conflict with floating elements. Since those discussions are five years old I wonder if that still applies.

So what exactly is the downside? Calling it "edit lead section" will head off confusion with editing the whole article. The link will save an untold amount of bandwidth for WP. Users will have a faster/easier/less cumbersome experience. The "clutter" argument is too nondescript and abstract for me to really consider. I'm looking at it now, and it's not "cluttered" at all.

Also please keep in mind the perspective of new users. I feel a bit annoyed (almost betrayed) that all this time I could have avoided editing the whole article. Vzaak (talk) 13:15, 4 August 2013 (UTC)

• Support I have had the gadget enabled for years with no downside. Template:Bug is one of the oldest bugs open. --  Gadget850 14:31, 4 August 2013 (UTC)
• Possible problem: Will users mistake it for the link to edit the entire page? Is there any way to do some testing? Adam Cuerden 14:42, 4 August 2013 (UTC)

That was twice addressed above. Call it "edit lead section" or similar. Vzaak (talk) 20:39, 4 August 2013 (UTC)

Links on the front page

From "todays featured article" and "in the news"...the green and blue panels with the text just mentioned look like clickable objects that will take you to the featured article and the 1st spot news article. When I fisrt read wikipedia I certainly clicked on it a few times and wondered why it didnt link to featured articles and wikinews. On a wiki that has almost identical format to wikipedia that I'm a part of...we added these links to the title panels for both sections of the front page and created very simple code to allow the links to change to the featured article every day. As there is a link at the bottom that leads the user to the page on featured articles and wiki news...its not a bad idea to link the top title panels to the current featured articles and wikinews. We also linked the images to the featured articles and wikinews. Not sure if this has been mentioned before but I think it's a harmless idea and benificial for the front page. --Shabidoo | Talk 20:53, 1 August 2013 (UTC)

Per MOS:HEADINGS, section titles don't normally contain links. It's not a bad proposal, but it's just not the convention at Misplaced Pages. Praemonitus (talk) 23:55, 3 August 2013 (UTC)

About community portal

I think that, "create articles" , "globalize" and "ent events in historical perspective" should be added to the help out section of the portal, as uncreated notable articles and articles having systemic bias are worthy of being noticed as articles without unsourced statements are. And {{Recent changes article requests}} should be transcluded to the newly created section "create articles", as in the past the template was transluded to the portal, but now it is not.--RekishiEJ (talk) 11:36, 2 August 2013 (UTC)

No one can edit the same article for more than one month

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.

Preamble

Controversial topics tend to fall under the control of a few biased editors who have an obsessive interest in getting their respective messages to stand dominant in articles. Tenuous neutrality is maintained by their endless tug-of-war. Their frequent skirmishes tax our administrative and dispute processes without resulting in effective resolution. Casual outsiders offering their takes at these articles are often also ineffective against the concrete-lined entrenchments that develop at these articles. The fact is that we really have no effective dispute resolution process to deal with this. Ours is based on the assumption that people will eventually voluntarily acquiesce to whichever side or compromise is obviously correct; but in such controversial situations, that resolution is the least likely to occur.

Wouldn't it be great if articles were generally the result of more detached reporting, rather than de-facto falling to the editors with the most bias? I have to wonder if there's some other way.

Proposal

Editors who have ongoing interest in a topic tend to often be the ones with biases they feel the article must convey. I realize this is not always the case, but it it is perhaps more often than not. If we limit the amount of contiguous time -- and/or edits within a particular amount of time -- that an editor can spend at a topic, we could perhaps ensure than articles always eventually fall to neutral people. A kind of preemptive topic ban, you could say, which I think would generally be a good thing for everyone who's been at the same topic for too long.

This would obviously represent a major change at Misplaced Pages and I don't expect it to be enacted right here and now. This is just a preliminary seedling of an idea that I wanted to toss out there and see if it grows. The specifics are up for discussion (the choice of one month as a limit was especially arbitrary and just presented to get the discussion ball rolling). Equazcion 12:54, 2 Aug 2013 (UTC)

• Oppose. We don't need preemptive bans and edit restrictions when there's no acute problem. This is totally contrary to the general project scope that anyone can edit any article. Neutrality can be enforced from case to case where it's necessary, but generally limiting the areas of interest for our editors is a no-go. De728631 (talk) 13:01, 2 August 2013 (UTC)
  • "Neutrality can be enforced from case to case" -- Can it? Maybe in the most blatant cases, but usually it's just subjective and not something an administrator could come and "enforce". Equazcion 13:18, 2 Aug 2013 (UTC)
• Oppose: What this would actually do is simply prevent any serious attempts to improve articles (which may take hundreds of edits to an article), and would lock in vandalism or errors on lightly watched articles while giving free range to ip-hopping vandals. Rather than stopping edit-warring, it would stop editing.Nigel Ish (talk) 13:04, 2 August 2013 (UTC)
• Facepalm I'm sure that also an "Editors should only edit articles about things they don't care at all" would improve NPOV. Oh wait, we also would not have articles then. -- cyclopia 13:09, 2 August 2013 (UTC)
• Oppose per those above, though this is only scratching the surface of what a bad idea this would be. Johnbod (talk) 13:11, 2 August 2013 (UTC)
• We allow anonymous editing despite the fact that most vandalism comes from IPs. Yet you're suggesting that I not be able to work on the many articles I help curate because a minority of people obsess over a small number of fringe articles? I don't think you've thought this through. The proper method is, well, what we use now - targeted topic bans. --Golbez (talk) 13:13, 2 August 2013 (UTC)
  • You're right, I haven't thought this through. Hence my description of it as a "preliminary seedling of an idea". Equazcion 13:19, 2 Aug 2013 (UTC)
    • "Wouldn't it be great if articles were generally the result of more detached reporting, rather than de-facto falling to the editors with the most bias?" I want to respond to this in specific. You realize that knowledge and interest does not necessarily mean bias, right? It wouldn't be great if people like me who had researched them for years were unable to, for example, split an edit war implement a neutral solution, or were unable to update an obscure article just because I touched it in the last 30 days. Or, because I work hard to bring a list of governors up to featured status, to congratulate me for my effort I'm not allowed to edit it anymore. "Eventually fall to neutral people" seems like a sentiment returning to the anti-intellectual days of Misplaced Pages, back when we disregarded experts in their field because we were All Equal Here. (harkens back to Misplaced Pages:Randy in Boise) Oh, and finally: This is 100% impossible to enforce. Because, as I pointed out... we allow anonymous editing. --Golbez (talk) 13:22, 2 August 2013 (UTC)
• Oppose. This proposal basically assumes bad faith on the part of all editors. Resolute 13:17, 2 August 2013 (UTC)
  • Basically. There are pros mentioned here, but so far as I can see Equazcion has not considered at all the possible cons. --Golbez (talk) 13:29, 2 August 2013 (UTC)
    • Casting a broad preemptive net might yield more positives than negatives. We could end up preventing qualified people with alot to offer, but I'm not sure how much articles would really suffer compared to how much the community suffers from stalwart bias situations. I'm obviously aware there would be cons, especially if you're purely deciding whether or not you like the idea as initially presented. Which the request to "not vote" and the admittal that this is "preliminary" were meant to avoid. Perhaps you could think of a change that might make this something you would consider. Maybe the limit could be 90 days, after which someone would have to take a mandatory topic break for 30 days. Equazcion 13:36, 2 Aug 2013 (UTC)
      • "might yield more positives than negatives" We seem to all disagree with you on that one. You're basically assuming bad faith for everyone who works on Misplaced Pages, and punishing those who are interested in a particular topic. I'm not seeing at all how this is a good thing for anyone. --Golbez (talk) 13:56, 2 August 2013 (UTC)
• (edit conflict) Comments: what defines a controversial article? Also, would you want someone to, say, only work on fungus articles for a month, and be forced to something else for another five? There is a difference between divisive ownership and stewardship. Chris857 (talk) 13:29, 2 August 2013 (UTC)
• Oppose. If this were enacted, the site would be a dead, rotting corpse by the end of the year. People are naturally drawn to edit things they enjoy. If they are prevented from doing this, then what possible reason could they have for contributing here? Using the collective knowledge of people who enjoy a particular topic is what Misplaced Pages was built on. — Huntster (t @ c) 13:49, 2 August 2013 (UTC)
  • Would imposing mandatory breaks after a certain amount of time on a topic carry the same impending doom? Equazcion 13:53, 2 Aug 2013 (UTC)
• Oppose. There are articles I edit every month because they address dynamic situations, such as the number of currently-serving federal judges. There are other articles I edit every month because they occasionally draw vandals. I am not about to refrain from participating in either activity. bd2412 T 13:54, 2 August 2013 (UTC)
• Oppose. Expertise is not optional, and neither is it free. Even if we rely on RS, it's an illusion to assume that every computer science PhD is competent to talk about details of automated reasoning, or every history major on Opium War, or every Wikipedian on Jesus without spending considerable time on getting familiar with the topic and the literature. --Stephan Schulz (talk) 14:07, 2 August 2013 (UTC)
• Oppose. Sorry, but for the huge range of reasons outlined above, this must be one of the most ridiculous ideas I've ever seen to be seriously promulgated. Edwardx (talk) 14:12, 2 August 2013 (UTC)
  • Thanks! It's always interesting when so many impassioned responses come as a result of ridiculous ideas. Equazcion 14:17, 2 Aug 2013 (UTC)
• Wrong solution to real problem I totally understand the frustration driving this suggestion, but this isn't the solution to it. I don't know what is, but this isn't it. Zad68 14:24, 2 August 2013 (UTC)
• Oppose. This would be a bonanza for sockpuppets. A far better way of handling the PoV problem is to tackle the IP-vandal issue would be the use of PC-protection. While editors who have a strong PoV might well be reviewers, every change request that they decline in their capacity as reviewer would naturally be subject to appeal and if the editor in question uses his reviewer status to promote is PoV (rather than keeping IP-sockpuppets out), he is liable to lose his reviewer status. Martinvl (talk) 14:39, 2 August 2013 (UTC)
• Oppose. This will almost make it harder to identify editors with serious POV issues! When an editor repeatedly edits an article, it's easier to identify the POV. When there's IP-hopping, changes of username, or whatever else would no doubt go on to sidestep the rules, there will be a loss of transparency in who's making the edits. Yes, POV is a problem in some articles, but this is absolutely the wrong solution. —C.Fred (talk) 15:08, 2 August 2013 (UTC)
• (edit conflict)WP:SNOW. Just admit that this is not going to happen. There's plenty of ways of strong arming an individual editor off a specific article (WP:CONSENSUS, WP:30, WP:DRN, etc.). Your proposal would impose significant hindrances on users who are trying to enforce consensus/policy/guidelines/etc. and be a gold mine for SPAs/IP-hoppers/throwaways. Strongly suggest that the OP withdraw this proposal before it is closed for him Hasteur (talk) 15:10, 2 August 2013 (UTC)
  • It was proposed for discussion, not implementation. Despite the fact that people have responded in go-or-no-go style, there's really nothing to snow yet, as there are no details. I'm just trying to point out a problem and one preliminary take on a solution. If anyone has a take on the problem I've identified, and variations or entirely different solutions, feel free. Equazcion 15:23, 2 Aug 2013 (UTC)
• As if. I sympathize with Equazcion and I agree that article obsessed editing monkeys are disruptive and not at all easy to deal with . But how can you call this a free uncyclopedia if you blanket block valuable users from editing articles? --Shabidoo | Talk 16:05, 2 August 2013 (UTC)
• Equazcion, are there any articles that you've worked on for longer than a month (or a year, if you prefer)? Would we really benefit from having you walk away from them? There are some articles that I've worked on significantly over the years, like Disease and Human body temperature, that I honestly don't care very much about, but I sincerely believe that the English Misplaced Pages would be worse off if I took them off my watchlist. WhatamIdoing (talk) 18:33, 2 August 2013 (UTC)
  • Honestly? Yes. All articles would benefit from fresh perspectives taking over completely from time to time (even if they're taking over for me), and that does not happen voluntarily. I'm not suggesting anything permanent mind you. PS. We could even limit it to contentious topics that have had a certain number of edit wars by the same editors in a specified period of time, as one thought. Equazcion 18:45, 2 Aug 2013 (UTC)
• Oppose. Wrong solution, very bad for the encyclopedia. Binksternet (talk) 18:51, 2 August 2013 (UTC)

• Oppose as just plain stupid. AndyTheGrump (talk) 19:28, 2 August 2013 (UTC)
• Oppose One of the main reasons we have watchlists is to be able to revert vandalism but with this new proposal if I revert vandalism to a article on 1st July then see further vandalism to it on August 2nd I would be powerless to revert it without it being me who got blocked. Not sure how this would be enforced either. Thanks, ♫ SqueakBox talk contribs 19:39, 2 August 2013 (UTC)
  • Seems like the spirit of the proposal could be maintained while allowing for such cases, if we tweaked the proposal (I've mentioned several possibilities here already). Which since it's a "preliminary" idea, you should feel free to suggest. Equazcion 19:46, 2 Aug 2013 (UTC)
    • The article this proposal would currently most hurt is Deaths in 2013 as the entire content changes monthly. Thanks, ♫ SqueakBox talk contribs 19:51, 2 August 2013 (UTC)
      • So let's limit this rule to contentious topics, for instance, those that have had X number of edit wars between the same editors over the last N days. Equazcion 19:58, 2 Aug 2013 (UTC)
        • Glad to see you are proposing limiting the rule already. And Deaths in 2013 isnt entirely free of edit warring, as we saw with the JJ Cale entry demonstrated this month. Thanks, ♫ SqueakBox talk contribs 20:05, 2 August 2013 (UTC)
          • I proposed limiting the rules a long time ago, you just didn't read it; one might say I proposed as much within my original post, since I said this was... what did I call it? A "preliminary seedling of an idea"? I assumed that would be taken as "please suggest variations" and not "vote only on my initial description of the proposal", but I guess I was mistaken. Equazcion 20:08, 2 Aug 2013 (UTC)
            • I do think your heart is in the right place, and that editors often need to take a vacation from topics in which they have been too deeply ensconced for too long. bd2412 T 20:12, 2 August 2013 (UTC)
              • Yes, I agree with BD2412. I already try to take a break from articles I end up in content edit wars about, would that all editors did the same. Thanks, ♫ SqueakBox talk contribs 20:15, 2 August 2013 (UTC)
                • Thanks to both of you, and yes it would be great if everyone did that voluntarily. It's just unlikely, in the grand scheme. I'm hoping some idea might come out of this that seems feasible. Equazcion 20:20, 2 Aug 2013 (UTC)
• oppose "A kind of preemptive topic ban, you could say," I do say. Why do you think I'm such a bad editor that I deserve such a ban? Andy Dingley (talk) 19:54, 2 August 2013 (UTC)
  • Deep down, everyone's a bad editor :) Or rather, everyone becomes bad at editing after they've spent enough time at contentious topics. It's just human nature, which I don't think anyone should claim they're above. Equazcion 19:58, 2 Aug 2013 (UTC)

Plip!

Flawed? Maybe. It was the introduction of a general concept though, rather than a concrete proposal. What do you suggest to fix its extensive flaws? Equazcion 20:31, 2 Aug 2013 (UTC)

Well, one way is for everyone reading this to take a more active roll in Misplaced Pages:Dispute resolution on Misplaced Pages. Add your name to the list of volunteers at DR/N. Help editors, instead of just criticize (but hey, criticism is important) by answering questions and trying to explain guidelines, policy and procedure (assuming you are familiar enough with the specific guideline etc.) Participating in the various noticeboard consensus discussions, participate at RFCs, join the Teahouse, and help newcomers, edit in good faith and continue to assume the same. If all else fails the old fashioned "Topic ban" does indeed seem to work. If that doesn't then a block or site ban can be used by administrative action.--Mark Miller _{Just ask! WER TEA DR/N} 20:41, 2 August 2013 (UTC)

• Oppose and Close as a snow balls chance of happening. While I fully understand the reasoning of the proposal; to be proactive against conflict and content disputes, this is simple too extreme a limitation to place on the general community at large The sins of a few effecting the abilities of all is more punitive that preventative.--Mark Miller _{Just ask! WER TEA DR/N} 20:32, 2 August 2013 (UTC)
  • What sort of less extreme measure might be more acceptable? Equazcion 20:35, 2 Aug 2013 (UTC)
    • See my reply just above.--Mark Miller _{Just ask! WER TEA DR/N} 20:43, 2 August 2013 (UTC)
• I just want to make sure I understand the premise... So essentially, get all your edits to an article in one month, then have a forced wikibreak from that article for (at least) a month, before being able to edit it again? So a one-on one-off system? I suppose I could see how that might work, but it really goes against quite a bit of the "anyone can edit" philosophy, and the fact that we're a (mostly?) volunteer developed website. So preventing contributors from editing merely for the sake of preventing them from editing, not due to some behavioural issue doesn't sound like it would garner much support (looks up above) nope, doesn't seem to. If there was a way to block an individual (for a week or 10 days, let's say) from all the articles in some particular category (essentially a technical way to enact a topic ban), then I might support that. But we don't seem to be anywhere near that functionality, much less the technical means to block a single editor from a single article (regardless of time: whether it be a month or a day or a year). - jc37 20:37, 2 August 2013 (UTC)

  I'm not suggesting anything more technical than the topic bans normally imposed. And the "month" was just a discussion seed. There are all kinds of possible details to consider. We could limit it to articles where where are frequent problems, make the mandatory break shorter, make the editing window bigger... Jc37, you of all people should know that this is merely a "brainstorming" session :) Equazcion 20:41, 2 Aug 2013 (UTC)

  : ) - jc37 22:23, 2 August 2013 (UTC)

  I tell you what I would support Equazcion, your idea got me thinking about this. Creating something new or adding a new limitation in this fashion may not be the asnwer, but what might be a drastic improvement is, if we propose that "Topic ban" discussions be a part of the dispute resolution process. Right now we don't even mention this as a possibility. Perhaps because most of these discussions take place only at AN or AN/I. But we should really consider making this a more formal part of the actual Misplaced Pages DR process under "Resolving user conduct disputes". As far as I know, there is no particular policy or guideline that prohibits a "Topic ban" discussion from being made as an RFC or having it placed directly on the article itself that suffers from an issue. Now, this could be abused, so perhaps what is needed is to add "topic ban" discussions at the DR/N when such issues are involved with content. I have long believed Misplaced Pages needs a conflict board. AN and AN/I are administrative noticeboards and I think if the community is going to be the ones who are deciding by consensus, it need not be located at the administrative venues.--Mark Miller _{Just ask! WER TEA DR/N} 21:05, 2 August 2013 (UTC)

• (ec with below) I've pretty much abandoned all hope for DRN becoming something remotely effective, but just to address your suggestion, if topic bans were made possible there, everyone would just immediately suggest them for the opposing side. But in general I do agree, having conflict board with actual binding results would be helpful. I'm assuming DRN would have been that board already if the concept hadn't been rejected before, but I could be mistaken. Equazcion 21:18, 2 Aug 2013 (UTC)

At the moment, Misplaced Pages does not have any real conflict resolution. The DR process currently only states RFCUser conduct. The DR/N does not discuss editor behavior but only in relation to the broader content dispute. My suggestion is not to broaden or even loosen criteria for beginning a topic ban discussion, just that it be allowed to take place on at least DR/N for now...or, barring that, the discussions could be directed to Misplaced Pages:WikiProject Conflict Resolution. Thoughts?--Mark Miller _{Just ask! WER TEA DR/N} 21:31, 2 August 2013 (UTC)

• Hold on, this is going somewhere interesting now. I've wished that it were easier and a more lightweight process to dislodge a problematic editor from a topic area. Writing up the proposal of "I'm having a problem with Editor X", gathering the diffs, and going to the dramaboards with it is time-consuming and painful. Giving well-qualified (how is this defined?) case-handlers at WP:DRN the ability to make at least short-term and limited topic bans that can be enforced with blocks if violated is a very interesting idea. This is worth more discussion. Zad68 21:13, 2 August 2013 (UTC)

• We don't even need to create or give any power or authority to DR/N volunteers. They just mediate, but...if we incorporated the idea that a volunteer could initiate the "Topic Ban" discussion at DR/N over issues that also involve a content dispute, drastically reduces the need for that filing to either end up at another venue like AN/I but also reduces the chance of the dispute returning back to DR/N itself. It would help alleviate some of the pressure from AN and AN/I as well as still be within the guidelines at DR/N, that volunteers have no special power or authority. it need not even be initiated by the volunteer, it could be initiated by anyone in good faith over long term disruption. Editors could then decide if a topic ban is appropriate right there if it is strongly needed.--Mark Miller _{Just ask! WER</su b> TEA DR/N} 21:23, 2 August 2013 (UTC)

• But then who is !voting in the TBAN discussion? The participants in the DRN case? Passers-by? The annoying thing about writing up an ANI is the tedious and time-consuming collection, curating and editing of diffs to present the narrative to the ANI participants who don't have any background on the problem. And if the issue isn't something really obvious, like a dozen diffs showing Editor X telling everyone to f--- off, but it's more subtle, like the ongoing selection of problematic sources or subtly misrepresenting the sources, it's hard to do, and at a dramaboard it can easily devolve into "This is a content dispute!" and will get shut down. If you've been working with a good DRN volunteer for a little while who has had the time and perspective to see the issue for what it is, that'd be a better and faster path to a productive outcome. I don't know exactly how this should work but this is starting to move in an interesting direction. Zad68 21:34, 2 August 2013 (UTC)

All discussion at DR/N, AN and AN/I are open to all editors. They are general community discussions. Even now, you don't need to be a volunteer at DR/N to weigh in on the dispute. Same at the other boards. The proposal I have in mind is simply to allow "Topic Ban" discussions at The Dispute Resolution Noticeboard. Some topic ban discussions fizzle out quickly and some are obvious disruptive tactics etc. We need to contend with that now in several places, but if done right, this could be a step that alleviates a number of issues.--Mark Miller _{Just ask! WER TEA DR/N} 21:40, 2 August 2013 (UTC)

Yes, understood... will think about this over the weekend. Zad68 21:43, 2 August 2013 (UTC)

The first thing you read at WP:DRN is This is an informal place to resolve small content disputes as part of dispute resolution. Allowing formal sanction discussions to occur there is antithetical to that purpose. Because what goes on at WP:DRN is voluntary dispute resolution, it receives a lot less attention then that Admin Noticeboards, but once you start having binding discussions, and having discussions result in sanctions, you will import much of the drama that isn't already there. Monty₈₄₅ 22:26, 2 August 2013 (UTC)

• Oppose as someone who has edited a lot in the The Troubles and Basque conflict areas, I've seen more than my fair share of problematic editors there, but those who genuinely misbehave get gradually escalating restrictions, while the vast majority learn to play within the rules. Most importantly, editors who feel passionate about topics are far, far more likely than the average editor to have access to the relevant sources to improve the article. Valenciano (talk) 20:49, 2 August 2013 (UTC)
  • Editors who are problematic to the point that sanctions can be imposed aren't my particular concern here. People often become entrenched without breaking any rules. If only they did, this wouldn't be an issue. Equazcion 20:55, 2 Aug 2013 (UTC)
    • So, you're not worried about problematic editors, you're worried about... editors who might become problematic? Maybe we need to see some examples of articles that you think would benefit from forced vacations of those who have worked on them. --Golbez (talk) 20:59, 2 August 2013 (UTC)
    • But doesn't editing and being entrenched without having sanctions imply that they're obeying the will of the community and the great Five Pillars. All you keep doing with these repeated "It's not a problem, but it could be" hypotheticals and responding with the same tired responses demonstrates a need to Bike-Shed. Hasteur (talk) 21:03, 2 August 2013 (UTC)
      • Not necessarily. NPOV is one of the five pillars and it's highly subjective. Proving that someone is editing with a POV is really only possible in the most blatant cases. Equazcion 21:09, 2 Aug 2013 (UTC)

• Oppose. A month is generally insufficient to do an adequate literature survey, let alone to develop enough expertise to assess the various sources. Such a restriction would preclude in-depth study of the topic, and permit only superficial editing. An egregiously bad proposal. ~ J. Johnson (JJ) (talk) 21:25, 2 August 2013 (UTC)
  • Did I say a month? Sorry, I meant to say 3 months. What do you think? Equazcion 21:28, 2 Aug 2013 (UTC)

    Still a ridiculous idea. What punishment ar you proposing for those unwise enough to edit beyond your arbitrary limit of however long it might be? Eric Corbett 21:31, 2 August 2013 (UTC)

    • I haven't proposed any sanction yet. That would be premature since this is just a preliminary conceptual discussion. Equazcion 21:37, 2 Aug 2013 (UTC)

• Oppose This would probably be more harmful than it would be useful. Disruptive POV editors can already be dealt with using the existing processes. The editors this proposal is aimed at could be placed under an editing restriction instead, which would be less harmful for the whole encyclopedia, as it wouldn't interfere with other editors abilities to edit. -- Toshio Yamaguchi 21:29, 2 August 2013 (UTC)
  • It's very difficult to prove a POV exists in all but the most blatant cases. Even then, it's difficult and usually simply not done, because no one wants to go to ANI and deal with that. Equazcion 21:37, 2 Aug 2013 (UTC)

There is always a POV; what we want is to avoid a biased or non-neutral POV. Which is very simply to determine. First you survey the literature — oops, just ran out of time, my month (the proposal!) has expired. Your "solution" (to an undemonstrated problem) is self-defeating. ~ J. Johnson (JJ) (talk) 21:49, 2 August 2013 (UTC)

When we speak of POV here we generally mean a bias, but yeah. One man's survey of abortion literature suggests that pro-choice article text is NPOV while the other says it's POV, etc. I envy you that you've never seen something like this demonstrated. Equazcion 22:01, 2 Aug 2013 (UTC)

(edit conflict) I think it is often visible whether an editor has a POV or not (How is the content the user contributes written? Does the editor attribute the material he/she contributes to reliable sources? etc), so this restriction is not only unnecessary, but as I said, even harmful. Such cases need to be judged on a case-by-case basis. Repeated cases by the same user can be dealt with at ANI. -- Toshio Yamaguchi 21:54, 2 August 2013 (UTC)

Most contentious topics are edited by people with POVs on two respective sides of an issue. We're not talking about a single problematic editor whom everyone on all sides can agree is obviously problematic. We're talking about everyone, even good, experienced editors, who simply need to take a step back from a topic they've become too invested in. Equazcion 22:01, 2 Aug 2013 (UTC)

For such contentious topics, there are measures that can be taken, such as whitelocking or goldlocking the article. -- Toshio Yamaguchi 22:12, 2 August 2013 (UTC)

I have seen edit conflicts over content on such articles, but more often than not, I've seen those editors with a strong POV actively work to expand the article by sourcing it, adding text and images etc, things which improve this project overall. People who are apathetic about topics generally can't be bothered to find the time to do that and lack the necessary knowledge and access to source material. Also forcing people out of their main areas of interest will almost certainly lead to them getting discouraged and abandoning the project altogether. Equazcion's intentions here are good, but the results would be catastrophic. Valenciano (talk) 22:18, 2 August 2013 (UTC)

Oppose. I think articles would whipsaw on a monthly basis with the changing of the guard, so to speak. As a counter-suggestion, why not have admins who have enhanced control at one Wiki-project? Bus stop (talk) 22:00, 2 August 2013 (UTC)

For one, admin and other editors don't have "control". Its a community endeavor.--Mark Miller _{Just ask! WER TEA DR/N} 22:17, 2 August 2013 (UTC)

Ask any admin who ever got involved with The Troubles area. A lot of them got burnt out as they were continually being accused of bias by one side or the other. Valenciano (talk) 22:20, 2 August 2013 (UTC)

Interesting idea. I think in its present general form it can't work. But you can think of ArbCom imposing restrictions like this or that restrictions like this can be voluntarily agreed on during dispute resolution. Count Iblis (talk) 22:52, 2 August 2013 (UTC)

• I entirely sympathise with the thinking behind this proposal, and I appreciate how thoughtfully the original poster has framed this idea. However, frankly this is a terrible proposal that would be exceptionally damaging to our community of editors. Entirely oppose. AGK 23:04, 2 August 2013 (UTC)

Perhaps instead of blocking ppl for 24 hours for WP:3RR they could simply be banned from the article they edit warred on for 1 month, that would be a much more effectively preventative punishment and would discourage ppl from edit warring more than the current policy does, breaking that restriction could result in a 1 month block. Thanks, ♫ SqueakBox talk contribs 00:20, 3 August 2013 (UTC)

Oh wow...look at that. Another excellent proposal!--Mark Miller _{Just ask! WER TEA DR/N} 00:42, 3 August 2013 (UTC)

• I too understand and sympathise with the thinking behind this proposal, and think that there should be a serious discussion (perhaps in the form of an RFC) in which we discuss how to address disputes and articles that are affected in the described manner. But in terms of the specifics of this proposal, I must oppose. If you (and I mean "you" as in the community in general) sees a problem with dispute resolution, I would recommend being part of the solution, and join us.) Steven Zhang 00:39, 3 August 2013 (UTC)

• I strongly agree. There are not enough editors involved in the actual process of DR.--Mark Miller _{Just ask! WER TEA DR/N} 00:42, 3 August 2013 (UTC)
• There are no specifics. I will not participate at DR. It's currently a completely useless reiterative process. But I agree that there should be a serious discussion regarding the handling of these situations. Equazcion 00:51, 3 Aug 2013 (UTC)

I really don't care what you think about DR/N. How is that relevant here? To make it relevant is to say you are using your own disdain for Misplaced Pages process to make proposals that circumvent things you do not like. That seems wildly inappropriate.--Mark Miller _{Just ask! WER TEA DR/N} 01:16, 3 August 2013 (UTC)

I wasn't responding to you. Steven Zhang suggested that providing manpower at DRN would help, and I disagree. I'm not looking to circumvent it, as that would imply it's some sort of required process. It's a remedy, and one that I find useless and broken, so I'm suggesting something else. Sorry if I've struck a nerve, obviously DRN is close to your heart, but that's my opinion. Equazcion 01:25, 3 Aug 2013 (UTC)

Sorry about responding after your comment. I do understand you were referring the comment to Steven. Yes, DR/N is important to me...but, perhaps not so close to my heart as art and theatre. ;). But I do very much believe you have more than good faith in your proposal. I actually believe you have the entire community at heart and I support that, if not the proposal itself.--Mark Miller _{Just ask! WER TEA DR/N} 01:53, 3 August 2013 (UTC)

@Equazcion, while I disagree with your opinion, I respect your right to your opinion. I have weighed in on your proposal here and thus I see my continued participation in this discussion as unnecessary. I would welcome a wider discussion at the DR wikiproject, but I would rather focus on making improvements to the process on my end. Regards, Steven Zhang 02:21, 3 August 2013 (UTC)

• Obvious Oppose. - Block as needed. Protect as needed. Good editors who are interested in and focus on specific topics for lengths of time shouldn't have to deal with this stupidity. --Onorem (talk) 01:11, 3 August 2013 (UTC)

• Comment – A more comprehensive solution would be to ban all users as soon as they have edited for one month. Then all disputes will rapidly resolve, and incivility will always be short-lived. --Epipelagic (talk) 01:40, 3 August 2013 (UTC)
  • Now you're thinking! Equazcion 01:41, 3 Aug 2013 (UTC)

Helpboxes as reference cards about wikitext

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 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:

So, I propose to expand this "helpbox" concept (of reference 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 Misplaced Pages features, without worrying about the hundreds-and-hundreds of help-pages (which are fine when teaching Misplaced Pages 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)

I know that Wikimedia UK has a physical version, which I've used before (i.e. given to others). Grandiose (me, talk, contribs) 16:45, 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)

Making the Main Page stand out

I believe the main page of Misplaced Pages 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)

Agreed. GenQuest 00:20, 5 August 2013 (UTC)

Remark - What exactly is your problem with flashing or scrolling? And why would you make disparaging remarks about my age? Horatio Snickers (talk) 19:28, 5 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)

• @Horatio Snickers: please see Misplaced Pages:2013 main page redesign proposal for this year's suggestions for changing the main page. Thanks. 64.40.54.132 (talk) 02:18, 5 August 2013 (UTC)

Reply - Thank you. Horatio Snickers (talk) 19:28, 5 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.

Truth4Sale (talk) 22:08, 4 August 2013 (UTC)

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 the US at least, financial aid information is often protected by FERPA, so it's not going to be public record. Intothatdarkness 19:59, 7 August 2013 (UTC)

New guideline proposal

Misplaced Pages:Cosplay images in articles. I started a discussion at Misplaced Pages:Village_pump_(policy)#Cosplay_Images and then created the proposal. I thought I would leave a note here as well. The discussion should probably move to the proposal talk page.--Canoe1967 (talk) 03:03, 5 August 2013 (UTC)

How about a "Wikipedians in prison" program?

There is no end to the work to be done on Misplaced Pages, 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 Misplaced Pages as part of their rehabilitation. Cheers! bd2412 T 16:24, 7 August 2013 (UTC)

I often found myself thinking the same thing. Support this proposal. -- cyclopia 16:32, 7 August 2013 (UTC)

Very timely suggestion...in related news:

Cox, Erin (August 5, 2013). "Gansler proposes tablet computers for inmates". The Baltimore Sun.

DMacks (talk) 16:39, 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 Misplaced Pages 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 Misplaced Pages to the accessible sites would be the job of whoever is regulating access to other sites. Within Misplaced Pages, there would be a mentoring/monitoring project to assist prison participants with constructive editing and curtail non-constructive edits. bd2412 T 17: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)

• Support. Minimum security harbors embezzlers, inside traders, and market manipulators that have unique expertise in the subtle truth spinning that drives Misplaced Pages'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 16:50, 7 Aug 2013 (UTC)
  • Thanks for the trolling, now what about a bit less sarcasm and a bit more serious discussion? -- cyclopia 16:56, 7 August 2013 (UTC)
    • It was a joke. Unclench. Equazcion 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? -- cyclopia 17:03, 7 August 2013 (UTC)

The point on the message to law abiding citizens is valid. I will strike that. Bus stop (talk) 17:08, 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 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). bd2412 T 17: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 17:25, 7 Aug 2013 (UTC)

There may be some benefits to the prisoners, however. Constructive participation in a collaborative project like Misplaced Pages might, for example, be the kind of evidence of good behavior that reflects well in parole board hearings and the like. bd2412 T 19:04, 7 August 2013 (UTC)

• Support. This would also most likely have the advantage of improving the racial diversity of Misplaced Pages editors. We're keen to help people edit Misplaced Pages 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)
• Oppose. Too many issues and not enough clarity with the proposal. Intothatdarkness 19:50, 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)

• Misplaced Pages noticeboards
• Misplaced Pages proposals
• Pages automatically checked for accidental language links