Wikipedia

Wikipedia:Village pump (proposals)/Archive 127

< Wikipedia:Village pump (proposals)
(Redirected from Wikipedia:VPR/Archive 127)
Latest comment: 8 years ago by Stuartyeates in topic Bot to remove WP:EASTEREGG (racist?) wikilinks to "Israeli Jews" under the word "Israeli"
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Bring the blue and red notification back

Latest comment: 9 years ago2 comments2 people in discussion

I like the way it was changed yesterday. Now once again old-fashioned.

Blue for our talk page messages.

Orange for our Username getting pinged, mentioned in any discussion.

Green for our created pages getting patrolled and when we receive thanks for our edits.

Red when we are warned or other negative things.--Action Hero Shoot! 14:31, 15 September 2015 (UTC)

Hey Action Hero: looks like the change is only temporary. HTH, --Elitre (WMF) (talk) 14:57, 15 September 2015 (UTC)

Time for a patroller user right?

Latest comment: 9 years ago27 comments15 people in discussion

As the Orangemoody case has illustrated, our new page patrol is vulnerable to circumvention via sockpuppets. It also suffers from ongoing patroller competence issues. Is it time to add a "patroller" user right to help manage these problems? VQuakr (talk) 04:17, 8 September 2015 (UTC)

Better solution: Make it more like "auto-confirmed" (with rarely-used corresponding "patroller" and "no-patroller" user-rights). As a "straw" example I would say to have the "auto" right you would need to have "10 articles/1000 edits/90 days" or "0 articles/4000 edits/1 year" under your belt, where the articles must be at least 7 days old/7 days as an article (i.e. recently moved drafts don't count), at least a certain size (say, 100 bytes), and not up for deletion to count. davidwr/(talk)/(contribs) 04:38, 8 September 2015 (UTC)
Any barrier to reviewing with a new account would be in improvement, but in the abuse case linked above the sockmaster just did dummy edits to game autoconfirmed. Similar "automatic" permissions would similarly be gameable, and would not invite the scrutiny that comes with assigning a permission. Unlike autoconfirmed, a patroller right is one that most editors would not need or use. VQuakr (talk) 04:44, 8 September 2015 (UTC)
I can't see how making it "non-automated" would improve anything with respect to sophisticated sock-farms like Orangemoody case. With such socks, sockmaster would learn the rules and the sockpuppets would fool the admins. The only difference is that either it would suck up admins' time or the admins wouldn't spend more than a minute or two and their "investigation" would be pretty mechanical which would be the de facto equivalent of an "auto-" right except you have to ask for it. In short, this user-right won't be of benefit against sophisticated cases like this, but it probably will help against less-sophisticated sock-farms. Also, there is one big advantage to an "auto-" right vs. a "regular" right: If I'm an experienced editor and I decide on a whim I want to patrol pages today, I don't have to wait for the right to be granted to me. davidwr/(talk)/(contribs) 05:06, 8 September 2015 (UTC)
As someone who started contributing on the new page patrol, no one should start contributing on the new page patrol. I made plenty of mistakes despite reading the relevant policies because I didn't have the experience of context to tag pages properly, and I wouldn't expect any new user to do much better in those circumstances. A user right for patrolling pages is definitely appropriate due to both the Orangemoody incident and the desirability of experienced editors doing the patrolling, so long as the requirements are somewhat low. I'd suggest 45 days, a minimum of 250 or 500 edits, and a demonstrable history of significant edits (to combat the use of slight copyedits or addition of links to reach the threshold, as was the case in Orangemoody). If we go much higher than that, we risk increasing the backlog of the new page patrol significantly. ~ RobTalk 05:02, 8 September 2015 (UTC)
Good point. If the backlog gets too long then we might as well ditch "patrolling" entirely. davidwr/(talk)/(contribs) 05:06, 8 September 2015 (UTC)
I don't know who orangemoody is, but his topic definitely desereves attention. I have been the target of many, many undeserved speedy notices by patrollers. I realize not everyone agrees they were undeserved and will be happy to provide some diffs (but only if this is of interest and if I can take my time collecting them). Ottawahitech (talk) 11:38, 8 September 2015 (UTC)
Good to hear from you, Ottawahitech! I hope you have been well. I linked an article about Orangemoody in my post at the start of the section: short story, it was/is a complex exploit of Wikipedia's web presence and open nature to try to extort money from innocent victims. Gaming the new page patrol was a part of that exploit. I don't think diffs are necessary at this time, though, since there is ample evidence of a problem needing a solution here. VQuakr (talk) 21:27, 8 September 2015 (UTC)
Nice to see a familiar face, VQuakr. I wonder why it took such a scandal to finally acknowledge a problem that has been obvious even to someone as clueless as me for years. Are you sure BTW that this acknowledgement is shared by editors who are not participating in this particular thread? Ottawahitech (talk) 13:37, 9 September 2015 (UTC)
  • I had suggested something similar at the idea lab: restrict patrol to pending changes reviewers and admins, and possibly create an additional patroller group. There are basically four options :
  1. a unique usergroup of reviewers / patrollers
  2. two distinct groups with reviewers able to patrol
  3. two distinct groups with patrollers able to review
  4. two distinct and separate usergroups.
Going with #1 is the simplest option, since many (but not all) users active at NPP are reviewers in the first place, while #4 would involve significant work for admins. #2 would ensure a significant user base for NPP from the start, mitigating concerns of increase in the backlog, and makes more sense than #3.
So I support #2: remove 'patrol' from autoconfirmed, create a new patroller usergroup with 'patrol', but let reviewers 'patrol'. Cenarium (talk) 15:00, 8 September 2015 (UTC)
    • Alternatively, we could introduce a distinct user right but keep "patrol" attached to autoconfirmed for 30 days, giving patrollers a chance to request the right before it's taken away from autoconfirmed users. This would solve the problem of an increase in the backlog during transition to #4. ~ RobTalk 15:47, 8 September 2015 (UTC)
  • I will simply repeat a portion of what I had to say over at the Idea Lab since this is where the discussion is taking place.

    Whatever regime we set up a dedicated commercial enterprise can find a way around it. It would take some time to work up an account with whatever "NPP reviewer" user-right but it is trivial when there is money on the table. At that point our best option is tying the user right to the Terms of Use by saying anyone with the 'NPP user right' may not receive compensation for their editing (with the usual carve outs for GLAM, WiR, employees of the Foundation etc.). As to detecting Orangemoody type things that requires either mentoring or a lot of experience. AGF ties our hands because we are suposed to deal with each new editor as a naive but well-intentioned person who just needs some proper guidance and each NPP must figure out how to manage that. I have never seen anything that tells us how to spot and deal with bad-faith paid editors etc. If we try to figure it out we are called 'deletionist' and 'over-zealous' which sooner or later leads to people giving up or becoming ass-holes with a smaller number figuring out how to manage on their own. Of course giving guidance on recognizing articles being pushed by puppet-farms will become useless almost as soon as they are posted. It would be so much easier if we just had a WP:CABAL controlling NPP :)[1]

    The only thing we can really do is increase the time/cost required to create an account that can pass our patroler-right criteria. I would also not support and automatic granting of the right upon passing a threshold. One possibility would be to make being confirmed with the user right a two stage process where the NPP is reviewed after 30 days or so by the admin who granted the right or another admin to make sure the right is 1) being used and 2) being used properly. I know this would be a bit of a time sink for our overworked admin corps, particularly when rolling out the new user right (How to grant this right when it is first introduced will have its own logistical and policy questions to be answered) but having a second stage review means even bad-faith accounts must contribute positive work to the project and spend time to do so thereby raising the cost of subverting our system. JbhTalk 15:24, 8 September 2015 (UTC)
@Jbhunley: re admin workload, only the actual addition and removal of the permission would need an admin flag. Follow-up "policing" of patrollers can be done via peer review by non-admins. We already have WP:NPP/N for a similar purpose. VQuakr (talk) 19:32, 8 September 2015 (UTC)
@VQuakr: The peer review would be useful to provide adequate feedback to 'grow' good NPP but what I was proposing, probably not clearly, is that the process go something like this:
  1. An editor who has (some minimum criteria set by policy) makes a request for NPP-user-right and says they intend to perform new page patrols.
  2. Admin looks over request and if no red flags pop up they grant the right. (this is where it would typically end)
  3. In 30 or so days another admin (or maybe an NPP peer) reviews the contributions of the editor and makes sure that they have done some minimum number of patrols (say minimim 50 bright-line) and they are correct and do not show any bad behaviors like working in tandem with another editor to get non policy compliant articles into Wikipedia.
  4. If the editors fails the, call it 30 day, review the NPP-user-right is removed which is why the admins will see a workload increase beyond what they would see for Rollback or Reviewer as they now are.
This will do several things. First it will insure competence, which can not really be checked before an editor starts doing NPP. It will cut down on hat collecting by insuring that editors with the right are willing to do the work. Most importantly from the perspective of preventing commercial editing rings self-patrolling their articles it increases the cost of getting the right. Time must be spent to get the minimum standards and they must actually learn the page creation policies to stand up to the initial review. A further benefit is that by having an established review process there will be a cadre of editors who can do spot checks of NPP editors and there will be a place to address problems that come up.

Since one of the major purposes of this user right is to prevent paid editing rings from inserting material into Wikipedia without review we must remember that all advanced user rights have an actual cash value to a commercial editing ring. The only way to limit the number of times our process will be subverted is to make the investment in time (Both in account age and work to build 'trust' and policy learning curve) more than or very close to the actual cash value of having the user right. I know that it is kind of bureaucratic and that is antithetical to many Wikipedians but erecting barriers to entry that do not restrict good-faith editors (beyond proving competence) is really the only defense volunteers have against those who are trying to make money off of the project. JbhTalk 20:36, 8 September 2015 (UTC)

  • Absolutely we need this. As for who gets it, I would say a handful of CSD tags accurately added or removed would be the best qualification for this userright. Aside from future Orangemoody type incidents, a big advantage of such a userright is that it could be easily taken away when needed. I've declined quite a few speedies, many were isolated errors by people who were trying to do the thing correctly, some were correct when the article was tagged but rendered incorrect by subsequent edits to the article. But we do get patrollers who insist on their own interpretation of the speedy deletion criteria. ϢereSpielChequers 15:50, 8 September 2015 (UTC)
  • It is indeed absolutely time to focus on the introduction of a minimum set of qualifications for New Page Patroller. As I have stated many times over the years, NPP is our only firewall against unwanted new articles and as an essential core process it needs an almost admin level of clue. Paradoxically, the far less important AfC project requires 500 mainspace edits and 90 days (which I introduced).
The brilliant suite of Page Curation tools that The Blade of the Northern Lights, WereSpielChequers, Scottywong and I fought tooth and nail for has greatly reduced the backlog from over 30,000 to a 'mere' 3,000 articles, but is still of course only as good as the people who can use it intelligently and in the manner for which we had it designed.
Concomitant with the launch of the Page Curation system it was originally intended to introduce a user right for it but at the time, this did not get done. It therefore remains an anomaly that unlike all the functions such as Counter-vandalism and Pending Changes, etc, the essential operation of NPP requires neither training, experience, nor special rights. and in any 1-hour session I spend on NPP, most of my my operations are correcting wrong tags, declining CSD (or changing the criteria), unpartrolling and tagging where tags were not applied, notifiing creators so that they can address the tagged issues, and much more. It's very frustrating that we can't trust our patrollers to do a reasonably good job and it's of even greater concern that no one wants to do anything about it while at AfC for the few pages that pass through their portal, there is more action and noise than at a Mad Hatter's tea party, and our NPP noticeboard and talk page often remain dormant for months.
I strongly suggest bundling AfC reviewier, New Page Patroller, and PC reviewer into one user right with a relatively high threshold. This would reduce bureaucracy, increase the quality of reviewing, and reduce the number of coat pegs for the hat collectors. Moreover, it would technically pave the way for the merging of AfC to NPP for which we already have a consensus.
A proper RfC needs to be launched at Wikipedia:New pages patrol/RfC for a user right for which we are already waiting on some requested stats and tables, and are already redesigning the NPP main page. VQuakr has already designed the dedicated noticeboard and the training department has been created. A lot has been going on and perhaps DGG could weigh in because I understand he also has some interesting ideas. Kudpung กุดผึ้ง (talk) 16:28, 8 September 2015 (UTC)
A "trusted editor" flag with those rights does make sense and reduce the paperwork. Admin granted but with a threshold to give guidance in policy. Dennis Brown - 2¢ 16:38, 8 September 2015 (UTC)
FWIW, I personally don't think that PC reviewer needs to be included in this new NPP right, and should remain a separate thing. PC reviewer is actually useful to the protect in its own right. --IJBall (contribs • talk) 20:26, 8 September 2015 (UTC)
  • I was previously very hostile to such an idea, and I'm still quite skeptical of it, but in light of recent developments I must admit we need a minimum bar for new page patrolling. However, I would never support such a high bar as "10 articles/1000 edits/90 days" or "0 articles/4000 edits/1 year". I propose that our NPP system be based upon our current methods for anti-vandalism. We would set up a patroller userright, similar to the 'rollback' right for anti-vandalism. When it is implemented, we would need to more widely advertise the NPP academy, similar to the CVUA. Once the program is completed, the user could apply for the right at WP:RFPERM. I would also be in favor of automatically adding the right to the reviewer package; a person trusted with reviewer would likely be competent enough to review new pages. We might also still allow manual page patrolling (e.g., without the New Pages Feed), as we allow manual reversion without rollback through Special:RecentChanges. --Biblioworm 17:08, 8 September 2015 (UTC)
  • I strongly support a dedicated "patroller" right. Wikipedia patrolling quality is slowly but surely approaching nil. However, the bar should focus more on trust and treatment of new page patrolling as serious, not as a shooter game; rather than high standards and inflated requirements. Esquivalience t 02:52, 12 September 2015 (UTC)
  • A patroller right sounds like a good idea. While, yes, as some people have said above, a financially-motivated bad actor might just acquire the right, having to do so will make their schemes more difficult and easier to expose -- if it takes 100 mainspace edits to get patroller rights, then they will either have to invest time in each patrolling account (and risk discovery if they try to cheat with quick automatic edits), or use a small number of patrolling accounts, and risk discovery if someone notices any unusual patterns in the pages they patrol with them. --Aquillion (talk) 05:40, 12 September 2015 (UTC)
  • The problem of performing NPP is the same as that of reviewing RfCs, and the same user right is needed. I would support a high bar for automatic assignment of the right, with the understanding it could be assigned to lower levels also. The NPP portion would still permit tagging new pages, but not marking them as patrolled. The RfC portion would still permit making comments. If the bar is set high enough, this could replace the autopatrolled user right, which exempts the person from needing their articles to be checked. For a grant of the right, I do not think it should require the creation of articles--many--perhaps most--of our most effective reviewers and patrollers have made very few articles from scratch, some of them none at all. I do not disagree with the possibility for automatic grant of the right, but there are many possible hang-ups. Automatic granting should d require creation of articles, but I do not know if this can be automated. For automatic assignment, I would set the bar at a level that would very thoroughly discourage the technique of creating multiple sockpuppets with it, and I think that at least 90 days and 500 edits. (of course, Anyone who deserves it in good faith before that--and many people would--can simply ask for it.) It would be granted -- and removed by admins; I don't see how we could prevent overcoming the removal by reaching the automatic level. I like the earlier suggestion that the first grant be for a limited period & require checking, and I don't see how this checking process could be automated either. A few paid editors do good reviewing, sand deserve the right, but they should never qualify automatically, and I'm not sure that could be automated either. DGG ( talk ) 19:25, 13 September 2015 (UTC)
@DGG: I agree that the technical action of marking a page "patrolled" is what the proposed right should control, but I disagree that it should be synonymous with the autopatrolled right. Creation of quality articles and patrolling are as different skill sets as those of a writer and an editor. There are of course many skilled Wikipedians that merit both permissions but many many more that should have one or the other, but not both (ie, me). VQuakr (talk) 05:03, 16 September 2015 (UTC)
There's a considerable overlap. At present we give autompatrolled very very easily. Large parts of the basic skill set is the same, tho most people do better at one than the other. Just as nobody can be either a writer or editor without a good knowledge of grammar and the principles of composition. DGG ( talk ) 05:19, 16 September 2015 (UTC)

Draft namespace

I'm strongly against stopping good-faith new users create and otherwise work with new articles. What I suggest is better use of the Draft namespace. Maybe 'new' users could automatically have their new articles appear in draft rather than article space? Stuartyeates (talk) 20:17, 13 September 2015 (UTC)

@Stuartyeates: a patroller user right would not affect newbies in any negative way. New editors could still create articles exactly as they can now, but the new pages would be patrolled by a curation team of more uniform competence levels. This would not only mean that new editors would be less likely to be bitten by an ill-considered speedy deletion nomination but also that the patroller would be more familiar with the rest of the patrol checklist. As a result, the new editor would have better odds of getting competent, timely, constructive feedback on their contribution (or even just a "thanks!" for a job well done) to encourage them to improve and continue contributing. VQuakr (talk) 04:50, 16 September 2015 (UTC)
Stuartyeates, expect to see perhaps next week a proposal for exactly that: new and anon user automatically directed to draft. DGG ( talk ) 05:15, 16 September 2015 (UTC)

Request for comment: Bot flags and bureaucrats

Latest comment: 9 years ago43 comments18 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is no consensus on the questions. The arguments on both sides are good, but the discussion is pretty evenly split. AlbinoFerret 20:22, 16 September 2015 (UTC)

Should we remove the bot flagging ability from bureaucrats and add it to a newly created a BAG user group? →Σσς. (Sigma) 07:21, 13 July 2015 (UTC)

This is a noticeboard for bot owners. Please move your RfC to WP:VPR or such. Legoktm (talk) 08:01, 13 July 2015 (UTC)

- or to the Bureaucrats' noticeboard. Kudpung กุดผึ้ง (talk) 08:05, 13 July 2015 (UTC)

  • Comment: If we were to do that the only thing left for the bureaucrats would be closing RfAs. As it stands, the bureaucrats are a dying breed, but we need them. Although there are 30 or so of them it's difficult to get more than a handful together for a 'crat chat in a reasonable time. What we need are more truly active bureaucrats. The only way we'll do this is to give them more to do, not less. By increasing their tasks, it would attract new candidates for 'cratship and prevent the group's ultimate extinction. --Kudpung กุดผึ้ง (talk) 08:05, 13 July 2015 (UTC)

The contents of this discussion have been copied from WP:BON. →Σσς. (Sigma) 08:46, 13 July 2015 (UTC)

Note - As there have been concerns over the phrasing of the initial statement, one should treat this as asking for input on two separate, but related, issues: (a) whether we should remove the bot flagging ability from bureaucrats and (b) whether we should create a new BAG member user group, which will have the ability to flag bots. →Σσς. (Sigma) 20:14, 16 July 2015 (UTC)
  • Naturally I'm very biased here, being a BAGer and non-'crat myself (and additionally as the person who mentioned this idea to Σ), but I support this. The current situation is a little odd; the BAG is responsible for gauging consensus and approving/denying bots from a policy standpoint but the technical task of adding the flag is left to bureaucrats. This is akin to a situation where 'crats are allowed to close RfAs but the act of promoting admins is left to stewards, or something similar. In practice this matters little, but it does lead to wait times after approval before a bot is flagged. if BAGers had this technical ability, we could do it as part of the approval process and there would be no wait time. While one could make the argument that bureaucrats act as a second/sanity check during bot approvals to make sure nothing was missed, in practice I'm not sure how true this is. Never have I known a 'crat to deny a bot flag, and I assume they mostly just watch Wikipedia:Bots/Requests for approval/Approved for new approvals, verifying that there are no obvious issues. — Earwig talk 09:01, 13 July 2015 (UTC)
    I would also like to add some additional background here: this is the only substantial previous discussion on this topic that I could find, over six years ago. Primary opposition seems to be due to concerns over BAG operation, but I'm not sure how that applies here since this is just for the technical flagging ability, not for some kind of process reform. Bot controversies only happen after bots have been running for a while; the current situation seems less like a check for me than a bureaucratic (ha) extra step. I would also like to stress the fact that the +bot flag itself does very little; we can't grant it to edit through blocks or other serious things. Its most notable function is hiding edits from recent changes. — Earwig talk 09:25, 13 July 2015 (UTC)
    But if there is a need for process reform, adding the technical ability before the process is putting the cart before the horse - I would like to see the process BAG would use to flag bots before deciding. The "sanity check", as you called it, is a valuable step. –xenotalk 14:29, 13 July 2015 (UTC)
  • Not a single thread of rationale has been provided as to why this should be done. As such, I can't see anyone can do anything but Oppose. Kudpung's points are also valid here. Dennis Brown - 2¢ 09:40, 13 July 2015 (UTC)
  • Support if the right is unbundled (which may require agreement on other projects and interest from developers to do the unbundling). I reproduce below some evidence I once presented to ArbCom regarding the role of bureaucrats in the bot approvals process:

The role of bureaucrats in the bot approval process

The assignment of bot status was up until April 2006 within the technical remit of stewards, with requests being made on meta. In keeping with their usual role, the stewards deferred to local communities to determine the consensus for bots to run and issued flags based on the approval decisions of groups on local Wikis such as BAG, where these existed. When the technical ability to assign flags was given to bureaucrats, they assumed the same role as the stewards had previously played - acting on the advice of the Bot Approvals Group. In some situations where BAG have been unable to reach a consensus, they have asked bureaucrats to aid them in making certain determinations - e.g. whether there is consensus for someone to join BAG. However, the local community has never accorded bureaucrats an "oversight" role over bot operations. It is a misunderstanding to think that bureaucrats have delegated the task of bot review to BAG. Unlike the promotion of new administrators or the performing of rename, the bureaucrat role here is largely technical.

This is reflected in that fact that where the assignment of a flag is not needed, bureaucrats have no role at all in the approval process. Examples of such situations would be:

  • The approval of a bot to run unflagged
  • The approval of an additional task (however different) for a bot with an existing flag

BAG is mandated by the community to determine the technical suitability of a bot, its compliance with policy and whether a consensus for a task exists. It follows that bureaucrats are not empowered to make a separate judgments as to consensus and to refuse to flag, or to withdraw a flag by virtue of having the technical ability to do so.

When bots are approved, they are listed at Wikipedia:Bots/Requests for approval/Approved and the next bureaucrat to check that list will assign the flag. Once a bot is listed, bureaucrats rely on the approval decision of BAG.

SquelchBot - a declined flag

In one recent case, I did decline to flag a bot [2]. This was expressly because I judged the approval to have been only partial - Tawker had only endorsed the technical merits of the bot. It was later decided this bot would run unflagged.

In the circumstances, I have no problem with "cutting out the middleman" and giving BAG the tools to do the job themselves. I don't think there's any need to invent work for bureaucrats to do - if the community would like to keep us busy, feel free to increase the number of RfA nominations (we used to close the same number each month that we now close a year!). WJBscribe (talk) 10:26, 13 July 2015 (UTC)
  • I still prefer a two key system, and there are only 4 BAG members listed as active (and there is value in having one key with a separate branch). There also hasn't been any indication that having bureaucrats flag bots has caused any undue delays. –xenotalk 10:42, 13 July 2015 (UTC) Disclosure note: Current bureaucrat
    I agree that lack of BAG members is a concern. For that matter, it is a concern with the current system - any idea why BAG membership is so depleted? WJBscribe (talk) 11:22, 13 July 2015 (UTC)
    It's a peripheral part of the project, I suspect. Thus lack of interest, and it requires some technical understanding. Jo-Jo Eumerus (talk, contributions) 11:25, 13 July 2015 (UTC)
    It's a largely thankless and generally boring (and sometimes tedious) task. –xenotalk 11:28, 13 July 2015 (UTC)
    Still it has not caused any huge delays. It is only few days that I wished we had extra help. -- Magioladitis (talk) 08:40, 15 July 2015 (UTC)
  • Oppose removing the ability from bureaucrats because it would make them unable to reverse earlier bureaucrat actions and the BAG group is understaffed and prone to attrition. I am not opposed to a usergroup for BAG being created that can assign and remove the bot flag (so, in addition to bureaucrats) as long as it is not the same person that approves the bot who also flags the bot ("four-eye principle"). –xenotalk 13:36, 13 July 2015 (UTC)
  • Support giving ability to BAG, oppose removing from bureaucrats. I agree with everything xeno has to say in the "oppose removing the ability from bureaucrats". I think it's reasonable for BAG members to handle the flagging and even more important for bureaucrats to handle the flag in for nonstandard scenarios. This would certainly be a Nice Thing to have, and as long as the flag is handled with care, there shouldn't be any problem going forward. E. Lee (talk) 17:24, 13 July 2015 (UTC)
  • Why not just add this to the adminstrator toolkit, like many other user rights? What was the rationale for selecting bureaucrats for this task? — Martin (MSGJ · talk) 08:15, 15 July 2015 (UTC)
  • Support giving ability to BAG, oppose removing from bureaucrats This is very very interesting. As a BAG member I sometimes considered applying for a bureaucrat flag only for this reason. BAG members certainly need the bog flag ability. I see not reason to remove this ability for bureaucrats. Bureaucrats are trusted members of the community in helping in these issues. -- Magioladitis (talk) 08:35, 15 July 2015 (UTC)
    Do you agree that's it's best for the approver to not also be the flagger? I'd prefer two sets of eyes , as now. –xenotalk 10:58, 15 July 2015 (UTC)
    xeno Some thoughts: a) Sometimes I needed to be able to give bot flags was in order to allow bot owners perform bot trials. b) We do not require two set of eyes for admin flag. On the other hand, I think that bureaucrats should be aware of any flags given. So, I am neutral on that. Still, I do not reject your idea and I understand the reasoning behind. We have to find a middle ground between more bureaucracy and security. -- Magioladitis (talk) 12:01, 15 July 2015 (UTC)
    a) in this case [if you gave the flag for the trial], you would just leave your recommendation once the trial was complete and let another BAG member give the final approval. b) we have dozens of sets of eyes on admin flag (all the participant's and most bureaucrat's) while a bot's first task could be shepherded through by just one BAG member, BRFA is not well-attended. I'd prefer at least one other set of eyes before the approval and flagging. (anticipated) c) I understand unflagged bots could get their first task approval by a single BAG member but this doesn't concern me as much because those edits aren't marked with the bot flag. –xenotalk 12:40, 15 July 2015 (UTC)
    I meant that there is a case that you need to hand the flag for a limited period (for instance enable bot mode in AWB) and you ll want this ti be done with not much bureaucracy. And there is also the point you just made. In many cases we hand out bot flag but we do not attended what follows. We recently had a case of an editor running a bot outside the bot trial period. But, yes, I understand your concerns and I would not like to sacrifice security over flexibility. I like your proposal but I will try to find an even better solution if there is any. -- Magioladitis (talk) 12:52, 15 July 2015 (UTC)
    @xeno: In that case, should we require two BAG members to approve new tasks for an existing bot with a flag? New tasks can be totally unrelated to existing ones, and bureaucrats have no involvement in this process, so single BAG members are currently approving flagged bot tasks. WJBscribe (talk) 12:59, 15 July 2015 (UTC)
    I'd leave that decision up to BAG; it's reasonable to assume that once the bot operator has the one task and the flag ongoing, there is sufficient evidence that the bot flag is being used responsibly and just an additional standard approval is enough for me. –xenotalk 14:00, 15 July 2015 (UTC)
  • I don't knowe owt about bots except that they constantly cause us grief. The more eyes on them the better, and that means keeping the ball in the 'crats courrt. Kudpung กุดผึ้ง (talk) 11:30, 15 July 2015 (UTC)
  • Oppose removing the ability from bureaucrats and oppose giving it to BAG. I have concerns about how little independent oversight there is in this area. Sarah (talk) 20:08, 16 July 2015 (UTC)
  • Oppose Why? The 'crats are quick to flag bots when approved. Let's not make this more complicated than it has to be. — MusikAnimal talk 20:36, 16 July 2015 (UTC)
  • Support giving ability to BAG, oppose removing from bureaucrats – while this is probably above my paygrade, from what I've investigated, it seems like at least the "active" BAG members should have this ability as well as Bureaucrats. No reason to take it away from the Bureaucrats, though, as far as I can tell. --IJBall (contribs • talk) 04:57, 18 July 2015 (UTC)
  • Oppose I do have the impression that BAG is - as a matter of its highly technical function - a somewhat secluded group that governs a major aspect of wiki operation. Having another group of eyes checking bots before flagging them seems to be a more appropriate kind of supervision than having everything within the same group. Jo-Jo Eumerus (talk, contributions) 14:33, 18 July 2015 (UTC)
  • Oppose per WP:BUREAUCRACY (which is ironic in the context). We don't need useless additional user permission bit, and there are so few 'crats left, don't render their role even less interesting.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:42, 22 July 2015 (UTC)
  • Oppose - we have the 'crats to be neutral button-pushers for technical processes where the community has already approved; that they have little role in the bot approval process is a good thing. Ivanvector 🍁 (talk) 21:19, 23 July 2015 (UTC)
  • Oppose - I don't really see any reason to take this task away from bureaucrats. Bureaucrats are positions of trust and I believe they do a great job as well as the BAG. Sam.gov (talk) 22:12, 27 July 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to restrict page moves in the "Module:" namespace to administrators

Latest comment: 9 years ago17 comments6 people in discussion
  Moved to Wikipedia talk:Lua

Simply put, I propose that page moves of pages in the "Module:" namespace be restricted to administrators. In other words, I think that the entire namespace should be move-protected. There is one major reason why I think this is necessary, should have been done long ago, and why I don't believe that even template editors should be allowed to move the pages in that namespace. The reason is: when a page gets moved from a title in the "Module:" namespace, it never leaves a redirect. This situation is problematic since, for one, it is the equivalent of having access to the "delete" function while not being an administrator and, for two, if there are any pages that run the module by its previous name (such as pages in the "Template:" namespace), they all break after the move (and since there are no redirects in the "Module:" namespace, there is no way to avoid the pages that run the modules from temporarily going down after the page move.) Steel1943 (talk) 02:39, 18 September 2015 (UTC)

This sounds like a deeper problem. Why do Module: namespace pages not leave redirects when moved? That is what seems to be the issue. Dustin (talk) 02:47, 18 September 2015 (UTC)
For the same reason there are no redirects in the "MediaWiki:" namespace: the code on the page doesn't run if the request hits a redirect first. Steel1943 (talk) 02:55, 18 September 2015 (UTC)
A move can be done without breaking uses of the old module with a copy-and-paste to the new module name (which of course requires attribution back to the original module), and then modifying the old module to simply invoke the new one. isaacl (talk) 02:49, 18 September 2015 (UTC)
This solution is problematic since it breaks edit history attribution and in a case where the module may be renamed twice, then there will be a module invoking a module that is invoking a module, and that could blog up the site. Also, if this is the only resolution, it enforces the need to move-protect the namespace. Steel1943 (talk) 02:55, 18 September 2015 (UTC)
Yes, I noted the issue with edit history attribution. If a module is renamed again, all of the old module names can be modified to invoke the latest module name directly. I'm not suggesting this is the ideal way, but simply that it is not impossible with the current setup to rename a module without breaking uses of the old module name. isaacl (talk) 03:08, 18 September 2015 (UTC)
Right. I'm not doubting what you are saying as a resolution though; from what I see, it's the only resolution. And if this is the only solution, there should be almost no reason why a page move should occur since they will always break something if another page is set up to invoke the module. If anything, maybe a new speedy deletion criterion could be set up if there is proof that a "Module:" has been copied to a new title, and there is proof that there is no longer any pages set up to invoke the module at the old name. Steel1943 (talk) 03:36, 18 September 2015 (UTC)
  • I'm willing to believe you have identified a real problem, but I am not convinced this is the correct solution. The reason is that admins are not by any means experts on the module namespace. I've been an admin for six years and I don't even know what it is, or desire to find out. So, this will inevitably lead to persons who do know what this is and how it works asking for adminship so that there is somebody who is both able to deal with these moves and knows what they are doing, and they will be shot down as single-purpose candidates always are these days. And so these pages will be stuck where they are, or admins will make bad moves of them when someone asks, and the problem will persist, just in a different form. I would suggest that despite your misgivings this should be given to the technically-minded folks in the template editor group, who are more likely to understand the issues involved and respond appropriately than admins at large. Last time I checked, modules, whatever they are, have absolutely nothing to do with site administration. Beeblebrox (talk) 04:27, 18 September 2015 (UTC)
  • @Beeblebrox: That hits a point I meant to bring up in addition to my proposal; possibly an edit notice explaining to administrators performing these moves requirements that have to be met prior to a moving a page in the "Module:" namespace (an explanation that could be understood by any administrator, regardless their technical knowledge; the simplest start to the edit notice would ask the administrator to ensure that no transclusions of the old name exist.) In such a case, if an administrator doesn't feel comfortable that the requirements as outlined in the edit notice are met, then they should not be fulfilling the move request. In fact, on that point, it may just be best to never allow pages in that namespace to be moved, but I know that is kind of crazy and will never happen, so I'm trying to find an acceptable alternative. Steel1943 (talk) 04:44, 18 September 2015 (UTC)
  • Have there been any actual problems with moves by non-admins breaking modules? My first instinct is that this proposal isn't necessary, and that normal page protection will be enough to protect the modules most at risk. However, I could be persuaded otherwise if we are consistently having problems with this. — Mr. Stradivarius ♪ talk ♪ 04:32, 18 September 2015 (UTC)
  • @Mr. Stradivarius: Well, I can tell you that I messed up once, but then had enough common sense to revert myself after realizing that a redirect wasn't created. However, there's no way to guarantee that other editors may realize this if they make a similar mistake. If there is no way to technically move a module without causing problems without the "copy-paste" resolution above, then why should that option even be available? Steel1943 (talk) 04:38, 18 September 2015 (UTC)
I agree with Mr. Stradivarius, and was already thinking so much before I read his comment. I don‘t see any problem that needs addressing by this, such as lots of damaging moves. High usage modules are already protected which prevents them being moved, so the scope for damage is therefore minimal even in theory. And there may be good reason for a non-admin/non-TE to move a module. Perhaps they are working on it and need to move it from a temporary name to a permanent one, or for consistency with other modules. It is easy to move most modules without causing problems: just update the template or templates invoking them (which should have the same level of protection). I can't think of any that are invoked directly that this won’t work on. So I don’t see any problem that isn’t already dealt with our current protection policy.--JohnBlackburnewordsdeeds 04:56, 18 September 2015 (UTC)
  • @JohnBlackburne: Actually, there is no way to move a module without causing downtime for any templates that call them. As I stated above, since redirects in the module namespace do not exist, nor do they work since redirects cannot run the code, the only way to prevent any downtime is by the method that Isaacl suggested above (which is essentially a cut-and-paste move which causes WP:CWW issues. That, and I cannot see a valid reason for a module to be moved to another title is it is a module that is transcluded anywhere given these issues. Maybe we need a separate edit notice when a page is created in the "Module:" namespace to ask the editor "Are you sure this is the title you want this page? Afterwards, it cannot be moved." Steel1943 (talk) 05:11, 18 September 2015 (UTC)
You can move almost any module without causing problems: simply move the module and update the template at the same time. 'the template' as it is almost always just one. If there are more update them too. As for why one might be moved I gave you some reasons immediately above. Another might be a typo when creating the page. That is probably as likely as any other page but we don’t have special warnings, even though it is more problematic to tidy up after misspelling an article as the redirects need to be deleted. Another reason not to do this: modules are simply not targets of test or bad edits, that I’ve seen. Templates sometimes are, articles often are, but not modules. The module protection policy is based on number of transculsions, not which have been vandalism/disruption targets as none have.--JohnBlackburnewordsdeeds 05:45, 18 September 2015 (UTC)
Looking back at the previous discussion you initiated on this topic, it seems there has been progress in implementing a redirect feature, where the Lua code to effectively accomplish a redirect would be treated by the MediaWiki software as a directive to perform a redirect. Whether or not it gets implemented, though, perhaps the move capability can be modified to leave behind the appropriate Lua redirection code in the old module. isaacl (talk) 16:19, 18 September 2015 (UTC)

Auto archive

Latest comment: 9 years ago1 comment1 person in discussion
  1. Should the archive bot not be added to talk pages by default? Its really annoying to see huge length of ancient comments on various talk pages.
  2. Why not include talk header by default as well? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 05:37, 19 September 2015 (UTC)

Undeleting old IP talk pages

Latest comment: 9 years ago1 comment1 person in discussion

Please comment at WP:BOTREQ#Bot to undelete 400,000 old IP talk pages - a proposal to use a bot to undelete some 400,000 IP talk pages that were deleted as stale. 103.6.159.88 (talk) 05:59, 19 September 2015 (UTC)

Ahmed Mohamed (student)

Latest comment: 9 years ago2 comments2 people in discussion

Ahmed has already been invited to the headquarters of some of the biggest internet giants out there. I was thinking that wikimedia should make a similar gesture of support and encouragement. Hence I'm wondering, who is the best person to speak to in regards to a possible wikimedia conference invite or a wikimania invite for Ahmed? I would prefer a link to a wikipedia userpage rather than e-mail. Thank you. Kleinebeesjes (talk) 10:45, 20 September 2015 (UTC)

Bear in mind, Ahmed didn't do anything all that exceptional. He's from an metro area with over 6M people. There are probably hundreds of students in his metropolitan area his age who display similar intellectual talent each year, only most of them either don't bring the results of their hobbies to school or their school, like most schools, is smart enough to not make the mistakes his school make (and IMHO those mistakes were doozies). Dollars to donuts says that if his engineering teacher (yes, he has, or maybe had if he's switched schools by now, an engineering teacher) told his students "make a digital clock and bring it to class tomorrow. If you can't figure out how to do it, spend an hour on it and bring in what you have" at least a few of his students would bring in completed clocks. davidwr/(talk)/(contribs) 20:23, 20 September 2015 (UTC)
Latest comment: 8 years ago19 comments9 people in discussion
discussion below moved from Wikipedia:Bot requests —  Cliftonian (talk)  18:45, 15 September 2015 (UTC)

I see this all over Wikipedia, all the time, especially in the opening sentences of articles about (Jewish) Israeli people. The article will start "X person (born Y date) is an Israeli so-and-so ..."—with the word "Israeli" linking to the article Israeli Jews. This rather pervasive practice is at the very least WP:EASTEREGG linking and, in my opinion, frankly racist. It's as if white American people had their articles opening "X person (born Y date) is an American so-and-so ...", with a link to White American under the word "American". I have removed at least a couple dozen of these usages by hand as I've come across them over the last month or so, but since the number of them seems to be so high (and people with a certain agenda seem to re-add these links occasionally), I think a bot would be advisable to change the wikicode [[Israeli Jews|Israeli]] to just Israeli, without a link. I have no experience in these things so I am listing this here. Any assistance would be appreciated. Cheers, —  Cliftonian (talk)  09:49, 14 September 2015 (UTC)

  Needs wider discussion. Can you demonstrate consensus for this task? Because this would affect several articles on a very likely contentious issue. Headbomb {talk / contribs / physics / books} 13:18, 14 September 2015 (UTC)
Thanks for the quick reply Headbomb. I have opened an RFC below. Hope you're well, —  Cliftonian (talk)  08:48, 15 September 2015 (UTC)

Request for comment

Per Headbomb's request above I am opening this up to try to get some more views. I have also posted at WP:ISRAEL to get views from there. I have already posted my rationale above. —  Cliftonian (talk)  08:47, 15 September 2015 (UTC)

@Cliftonian: yes, I used the word Nation meaning an ethnicity, not a state. I think Arab and Jewish Israelis should be described in the same style, so it's not a separate discussion. Jewish Israelis are the majority, but they should not be considered the default case with Israeli citizens of other ethnicity being an exception. “WarKosign” 15:10, 15 September 2015 (UTC)
I looked at several articles on African-American actors, as another case of an ethnicity that is a large minority in its country. The articles that I checked describe them as Americans, without wikilink and without referring to their ethnicity in the article unless it's relevant in some section. The only reference to the ethnicity is by category. “WarKosign” 15:29, 15 September 2015 (UTC)

Please have your discussion somewhere else (WP:VPR). This is supposed to be a page where bot operators can work with people who have a request that has already been discussed or is uncontroversial. Having an RfC here will drown out the useful noise. Legoktm (talk) 15:55, 15 September 2015 (UTC)

discussion above moved from Wikipedia:Bot requests —  Cliftonian (talk)  18:45, 15 September 2015 (UTC)

@WarKosign: please excuse the thread of conversation being moved and broken up slightly. I agree with you that ideally Israelis of all backgrounds would be introduced simply as Israeli, without a wikilink, but I think so far as a bot is concerned it is better to focus on the low-hanging fruit of the [[Israeli Jews|Israeli]] problem first. The rest is another, much longer and much more complicated, discussion. —  Cliftonian (talk)  19:07, 15 September 2015 (UTC)

@Jethro B: apparently made most of the changes, he actually used AutoWikiBrowser. See https://en.wikipedia.org/w/index.php?title=Special:Contributions/Jethro_B&offset=20121031035859 Naraht (talk) 21:36, 15 September 2015 (UTC)
Thanks for this Naraht. —  Cliftonian (talk)  08:05, 16 September 2015 (UTC)
  • It's a minor point, but Israeli Jews are not a race. Hence it is not racism. The alleged behavior could perhaps be characterized as discrimination. Praemonitus (talk)

Solutions for Chinese versions & their heated warfare on Wikipedia

Latest comment: 9 years ago6 comments6 people in discussion

Problem & Reasons

  1. With approaching a hundred years of different political and cultural background, the Chinese language of different places like Hong Kong(1842), Republic of China(1911), People's Republic of China (1949), Macau, Malaysia, Singapore ... etc, have developed different vocabulary, and even different grammar, writing, expressions, strokes...
  2. The current simple switching of language encoding between the so-called Traditional/Simplified Chinese text cannot handle many issues, and worse, caused heated argument, offensive & defensive changes of the content.
  3. No need to pretend there is no differences. No need to halt the changes. No need to force unification of the new generation of Chinese languages.
  4. For the sake of the culture of all human being on Earth, for the culture of all countries,
  5. Reducing argument & thus let people of different places/countries use their time and energy to work on Wikipedia content for the passing on of knowledge and culture for future generations of their respective places/countries instead.

Solution

The original concept of Wikipedia has been respected by people all over the world. Wikipedia, please kindly consider for splitting the various Chinese versions into independent sets where the content can become independent of each other and cater mainly for the people of the country or place each set serve...asap. May peace be with you. May all countries and all cultures prosper for many generations to come. --Xaaan5 (talk) 23:46, 14 September 2015 (UTC)

  • There has been a problem with Hong Kong articles, where people have been trying to add Mandarin names, where the local language is Cantonese, and other people want to remove them. But I would have considered this a project level problem for here. Graeme Bartlett (talk) 11:57, 17 September 2015 (UTC)
  • If I understand what the OP is asking for, I think it's already done, or partly done. Besides the "Chinese" Wikipedia there are already Cantonese, Hakka, Min Nan and other WPs. See meta:List of Wikipedias by language group, Sinitic section.
    As far as the English Wikipedia is concerned, such as the Hong Kong articles that Graeme Bartlett mentions, if edit-warring is going on then it should be resolved by the usual processes. Stanning (talk) 14:12, 17 September 2015 (UTC)
  • Xaaan5: This has been raised before. There were proposals, years ago, to split controversial articles here on English wikipedia so we have articles from various points of view instead of one NPOV article. There have been edit wars over US vs English spelling. Our decision, in every case, was to knock heads together and tell the warring editors to work together to create a NPOV article and NPOV is now enshrined as one of our five pillars. This has worked till now and I doubt very much that it will change. On the contrary, I can imagine cases where there are separate wikipedias with the same language but different scripts uniting at some time in the future as tools are developed to auto-transcribe. Just my opinion. filceolaire (talk) 22:48, 22 September 2015 (UTC)
Latest comment: 8 years ago59 comments22 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Closing comment: There is near-unanimous consensus in favor of converting the mentioned links to a secure HTTPS connection. --Guy Macon (talk) 22:48, 14 November 2015 (UTC)
Moved from WP:VPT upon request.

As an extension of the discussion on WP:VPT, I decided to file this Request for Comments. The question is straightforward and has two parts:

“Should we convert existing Google and Internet Archive links to HTTPS, and is this protection of readers' privacy enough to merit a solitary edit?”

The reason for this action is Wikimedia's recent switch to HTTPS-by-default for all projects. If we are truly concerned with readers' privacy as they enter Wikipedia, we should be equally concerned with it as they follow an external link that serves as a reference to what they just read. The issue concerns all existing external links to Google services (Google Books, Google News, YouTube, etc.) and the Internet Archive domain (*.archive.org), and only those two, because Google Books, Google News and the Internet Archive's Wayback Machine are among the most linked-to references on Wikipedia, with literally millions of external links.

Frequently Asked Questions:

  • Won't this break existing links? What if the HTTPS version is different from the HTTP version? As far as Google and the Internet Archive are concerned, HTTP and HTTPS versions are identical. In fact, both services have switched to HTTPS-by-default years ago, and only maintain HTTP support to not break existing inbound links.
  • This seems like a mere technicality. Why not just be bold and do it? I would like to and, in fact, I did just "do it" over the past months, until Wikibureaucracy stopped me. It was pointed out to me that the rules of AutoWikiBrowser do not allow "insignificant or inconsequential edits," so the question that needs to be addressed here also is whether securing readers' privacy is to be considered "significant" or not.
  • I don't like HTTPS. Why did Wikipedia switch to HTTPS-by-default in the first place? Please do not make this debate a proxy war for an already settled issue. If you have questions about the purpose of HTTPS, please have a look at this info website by the Federal CIO.

Please leave your comments and concerns below. --bender235 (talk) 14:10, 10 September 2015 (UTC)

The MediaWiki software enables protocol-relative links, which basically means you shall leave Wikipedia on the same protocol (HTTP or HTTPS) that you have entered it. For two reasons, we should not consider this alternative here: (1) Wikipedia has switched to HTTPS-by-default, so everyone is entering on HTTPS anyways (unless you access a mirror website or offline copy of Wikipedia somewhere), and (2) both Google and Internet Archive have made public and clear declarations of HTTPS support and enforcement. For instance, read how IA encourages others to use HTTPS links. --bender235 (talk) 17:20, 9 September 2015 (UTC)
I'll let others judge whether you are right that "we should not consider this alternative here". But one can easily imagine situations where forcing absolute-HTTPS down people's throat could be a problem. For instance, in countries where the state has a special relationship with HTTPS.[4]--Anders Feder (talk) 17:30, 9 September 2015 (UTC)
As mentioned in the FAQ, the issue of whether we should bow down to authoritarian regimes' wish to spy on people was considered during Wikipedia's decision to move to HTTPS-by-default. So please do not reopen this debate here. --bender235 (talk) 18:16, 9 September 2015 (UTC)
This RfC does not concern whether Wikipedia itself should move to HTTPS-by-default, and any considerations made in that debate do not necessarily translate into different considerations in this debate about a different issue being fait accomplis.--Anders Feder (talk) 18:26, 9 September 2015 (UTC)
  • Use HTTPS wherever it's supported. The only reasons that ever existed to not use HTTPS were strain on servers and really obsolete clients not supporting it. HTTPS is now optimized enough it adds virtually no strain, and if anyone uses such an old client that they can't use SSL, they also can't read Wikipedia at all anymore, so switching our external links won't affect them anyway. Jackmcbarn (talk) 18:01, 9 September 2015 (UTC)
Thanks for your support, but let me ask you the follow-up question: does this protection of readers' privacy merit a stand-alone edit of changing HTTP links to HTTPS? --bender235 (talk) 18:27, 9 September 2015 (UTC)
IMO, yes. Jackmcbarn (talk) 19:45, 15 September 2015 (UTC)
The latter claim is false. See m:Offline Projects/About Offline.--Anders Feder (talk) 18:30, 9 September 2015 (UTC)
Well, offline is offline. If you read Wikipedia offline because you don't have internet access, you won't be able to follow any link, regardless of whether it is HTTP or HTTPS. --bender235 (talk) 18:56, 9 September 2015 (UTC)
No it isn't. There are many people who have intermittent or slow online access.[5] Not least in countries where access to Wikipedia is heavily regulated.--Anders Feder (talk) 19:15, 9 September 2015 (UTC)
Eh, and what does that matter for http vs https... nothing. HTTPs is actually faster in most usecases these days because then it can also be on HTTP2/SPDY. BTW that data you are linking to is almost 6 years old now. Remember how Europe is overflowing with refugees with smartphones? The first thing people do is buy a prepaid sim, because a phone is their best and most valuable tool. The world is change rapidly on this front, and that's the entire world, not just the western world. —TheDJ (talk • contribs) 19:51, 9 September 2015 (UTC)
Europe is generally considered to be part of the Western world. It is no surprise a phone is valuable tool there. As for "what it matters", as the example with Russia shows, HTTP vs HTTPS very obviously matters.--Anders Feder (talk) 20:08, 9 September 2015 (UTC)
@Anders Feder: It seems to me you didn't read the whole story of what you are referring to. Here's the key paragraph from the Russia-vs-Wikipedia+HTTPS story you link above: “This week's example of Wikipedia in Russia is one of the first few test cases of governments forced into an all-or-nothing blocking choice; fortunately, it provides at least anecdotal evidence that the theory works. After just a few hours of blocks, Russia reverted its policy, claiming the material had been taken down. (It hadn't, according to Wikipedia editors, though the title and URL of the page had been changed.)” Something similar had happened to the Internet Archive in June (read Ars Technica). In both of these cases, like in many others, it turns out that the HTTPS-by-default is actually a good thing, because it forces authoritarian governments into a all-or-nothing blocking choice, rather than just subtly blocking whatever they deem "anti-regime." So what you're claiming to be a bug is actually a feature of HTTPS. --bender235 (talk) 19:22, 10 September 2015 (UTC)
I did read it. The outcome in the case of Russia is hardly a feature, as you phrase it, of HTTPS, but rather of a complex web of specific political circumstances. Whether HTTPS will be a drawback or an advantage in any other given set of circumstances is anybody's guess. My claim was not that it always is a drawback, but rather that it is a factor in how accessible the URL is—one which should be taken into account in the considerations.--Anders Feder (talk) 19:36, 10 September 2015 (UTC)
I fail to see what the relevance of website blocking is in this situation. If a website is served only over https, any http links will be returned to the user with a 3xx HTTP status code and the browser will attempt to load https, which will be blocked. If that is correct (tell me if it is?), leaving external links as http provides no benefit to people in countries which may block Google or Internet Archive. BethNaught (talk) 19:43, 10 September 2015 (UTC)
Is it the case that Google and IA are served only over HTTPS? If that is the case, you are clearly right. But I don't know if it is.--Anders Feder (talk) 04:43, 11 September 2015 (UTC)
I believe it is true for Google: searches and Gmail are https only and whenever I try to access Google over http it redirects me to https. BethNaught (talk) 14:00, 12 September 2015 (UTC)
  • Support part 1, question part 2: It seems to me very clear that when websites provide https only, we should provide https links, as doing otherwise is pointless. Hence incidental conversion is definitely appropriate. As to whether solitary edits are appropriate, what risks do users face by visiting an http link which is redirected to https? If they face a privacy risk or outright attack vector a solitary edit would certainly be appropriate. BethNaught (talk) 20:28, 9 September 2015 (UTC)
Well, the latter depends on the circumstances. Like where they are, and who they are. But in general, no one should have to "depend on the benevolence of network operators." --bender235 (talk) 21:33, 9 September 2015 (UTC)
Bender235: How about cut-pasting it there?--Anders Feder (talk) 05:37, 10 September 2015 (UTC)
@Redrose64 and Anders Feder:.   Done. --bender235 (talk) 12:39, 10 September 2015 (UTC)
I am more than willing to do it and, in fact, I was doing it for long using AutoWikiBrowser. But the AWB people asked me to stop until I established community consensus that those edits are useful. --bender235 (talk) 19:15, 10 September 2015 (UTC)
@BU Rob13: I did, in fact, file a bot request some weeks ago. --bender235 (talk) 16:49, 11 September 2015 (UTC)
@Bender235: Did you post the doing tag next to your comment or was it someone else? If it was you, are you working on creating a bot, or are you still looking for someone else to hop in? ~ RobTalk 19:29, 11 September 2015 (UTC)
I added the tag with my initial comment. I am not a programmer, so this was a request for someone to program a bot that was "doing" what I described. --bender235 (talk) 20:55, 11 September 2015 (UTC)
  • Support in full. We should definitely convert existing Google and Internet Archive links to HTTPS, and this protection of readers' privacy and improvement of security definitely merits a solitary edit. As bender235 has said, no one should have to "depend on the benevolence of network operators", and history has repeatedly shown that network operators cannot be trusted. HTTPS is already enabled by default for everyone on Wikipedia, and it does not make sense to use HTTP links on an HTTPS page unless the target does not support HTTPS. In this case, both the Internet Archive and Google not only support HTTPS, but have also already enabled HTTPS by default. Right now, HTTP links are redirected to HTTPS by Internet Archive and Google from their servers, but the initial unprotected HTTP request presents users with the unnecessary risk that an ISP, government, or someone on the same network can see the links being clicked on and tamper with the subsequent redirection. By changing these links to use HTTPS, we are protecting the Wikipedia readers' privacy and security, without additional drawbacks as Wikipedia itself already uses HTTPS by default. Tony Tan · talk 16:59, 12 September 2015 (UTC)
  • Strongly Opposed. HTTP and HTTPS are different websites on different ports (80 and 443), changing them would be the equivalent of changing domains. Now due to way citations work, we need the original URL accessed on the cited date. The proposed change will break citation, the link history, and make it harder for tool authors such as myself to find the same URL on previous revision, on different pages, talk pages, and other languages. So unless you're going to check each citations again to update the access date, you are destroying citations.

    Sidenote: Anyone citing Google as a bearer of privacy is delusional. They were instrumental with the NSA in mass surveillance, have dossier on many/most business and individuals in the west, and have been found guilty by the courts for violating privacy. FYI, when you using a Google services, you aren't using the Internet anymore, instead your ISP dumps you into Google's private global network. If you were serious, you'd switch to youtube-nocookie.com, replace Google Books with Internet Archive equivalent (or Wikisource), and use the original AP news sources. — Dispenser 17:00, 15 September 2015 (UTC)

Most of what you wrote is opinion, but the part that is technical claims is simply wrong. Both Google and IA deliver exactly the same content over HTTP as they do over HTTPS. No citation will be broken. Ever.
As for your "sidenote:" I am not advertising Google as the bearer of privacy. And make no mistake, using HTTPS to connect to Google (or IA for that matter) will not protect you from all government surveillance. But HTTPS can be seen as "some" protection, rather than "none at all" in the HTTP case. In general, any measures of security in computer science should be evaluated against the adversary model. If your adversary is the NSA, then indeed an HTTPS connection to Google will not help you that much. But if your adversary is a rogue ISP, or a public hotspot, or even a foreign (non-US) government agency, then HTTPS will in fact protect not only your privacy, but also the integrity of the data being delivered to you. In essence, HTTPS is like a lock on your door. Will it keep out a government agency that comes with a warrant? Certainly not. But it might keep the ordinary burglars out. --bender235 (talk) 19:34, 15 September 2015 (UTC)
I've written a link checker and what I've written is not opinion. HTTPS is a different website, just like www1.example.com and www2.example.com are different website serving the same content. For citations, we need the original URL. — Dispenser 21:59, 15 September 2015 (UTC)
I don't see why this of any concern except for your corner case of a user-written script. Why should this dictate how we deal with this issue that concerns millions of readers and their privacy? I don't even see why this original URL mantra is so important. In the end, we cite a text, not a particular copy of it. That goes for books and websites. Because by your definition, even fixing http://links.jstor.org/sici?sici=0147-7307(198706)11%3A2%3C101%3ADTRDAT%3E2.0.CO%3B2-V to http://www.jstor.org/stable/1393579 would "break the reference," even though it only links to the same article, in the way the website intended. --bender235 (talk) 00:36, 16 September 2015 (UTC)
Most readers never check at references and the small number left who also care every website is HTTPS can simply install HTTPS Everywhere for this corner case of yours. And are you telling me you've been changing other links without re-verification and updating the accessdate?! — Dispenser 04:07, 16 September 2015 (UTC)
Oh, so readers never check references? I see...
As for changing URLs: yes, I been doing the fix described above quite frequently although, when a citation template was used, I would just replace |url=http://links.jstor.org/sici?sici=0147-7307(198706)11%3A2%3C101%3ADTRDAT%3E2.0.CO%3B2-V with |jstor=1393579 in that case. Similarly, I replaced links like |url=http://www.sciencedirect.com/science/article/pii/S0264999310000702 with |doi=10.1016/j.econmod.2010.04.008 all over Wikipedia. Do I "re-verify" the source? Well, obviously I had to follow the original link first to get to the JSTOR or DOI identifier. But did I re-read the source to see if it was the same word-for-word? Of course not. And why would anyone? It is exactly the same. (Also, did I update the accessdate? No, because journal articles do not need one. They do not change over time.) --bender235 (talk) 12:18, 16 September 2015 (UTC)
"HTTP and HTTPS are different websites on different ports (80 and 443), changing them would be the equivalent of changing domains." Not true. It's still served from the same servers ran by the same entity. "Now due to way citations work, we need the original URL accessed on the cited date.". No, you need a URL to the same article. "The proposed change will break citation, the link history, and make it harder for tool authors such as myself to find the same URL on previous revision, on different pages, talk pages, and other languages." How? (And your sidenote is totally irrelevant to the matter at hand. Even if Google is spying on us, using SSL to connect to Google means that nobody else can spy on us.) Jackmcbarn (talk) 19:44, 15 September 2015 (UTC)
First, same/similar content different server like a mirror. Second, it needs to be the one originally accessed with the timestamp (Got chewed out for a URL updater). Adding an archive_url would be acceptable. Third, it requires more patterns, more SELECT statements, and more processing. It introduces uncertainty into the backdating process. — Dispenser 21:59, 15 September 2015 (UTC)
It's not the same content on a different server. It's the SAME SERVER. Jackmcbarn (talk) 23:21, 15 September 2015 (UTC)
Might be the same server (usually not), but changing the Uniform Resource Locator means you need to re-verify that reference and update the accessdate. Simple really. — Dispenser 04:07, 16 September 2015 (UTC)
Dispenser, can you point me to an actual policy requiring that people fixing dead links re-verify that the contents of the article are supported by the citation. I know: once upon a time, for a situation significantly different from this, someone yelled at you. But I want a policy or guideline, not merely evidence that someone spouted a rule that I've never heard of, despite spending many years at WP:V, WP:RS, and WP:CITE. WhatamIdoing (talk) 20:28, 16 September 2015 (UTC)
  • support Definitely worth doing. Now WP, Google and the Internet Archive all use HTTPS users may not even realise that they are still making an insecure request. We and they have switched to a secure protocol for good reasons, we should not deny our readers the full benefit of that when it can easily be fixed.--JohnBlackburnewordsdeeds 17:22, 15 September 2015 (UTC)
    @JohnBlackburne: Our readers made no decision in HTTPS, they may prefer the extra speed and lower latency of HTTP. I don't feel we should be pawns of the EFF and their HTTPS Everywhere already does what this proposal wants to do. — Dispenser 18:15, 15 September 2015 (UTC)
    HTTP is not faster in this case because Google and IA redirect it to HTTPS. BethNaught (talk) 18:21, 15 September 2015 (UTC)
    As for the "HTTP is faster than HTTPS" claim, here's a technical rebuttal. --bender235 (talk) 19:45, 15 September 2015 (UTC)
    I'm talking was about latency and proxying which are slower for many reasons, not encryption speed. But BethNaught is correct that it would be irreverent since it would be redirected to HTTPS. — Dispenser 21:59, 15 September 2015 (UTC)
  • Support building this into the standard 'upgrades' to Wikipedia pages that AWB performs, but make AWB not save the pages unless there are significant other changes to the page. It will then slowly migrate. This is at the moment (since both do support still http) a low priority task. Note that the system should check whether the 'old' and 'new' data linked to are really the same (they should be). --Dirk Beetstra T C 06:06, 16 September 2015 (UTC)
  • Support. The possible downsides seem rather theoretical. In contrast, not having https puts millions of readers at great personal risk. People can and do read Wikipedia from within more authoritarian regimes, where ISPs certainly do monitor individual browsing habits. We have a responsibility to minimize this risk, and changing outgoing links to https is an important ingredient. Sławomir
    Biały     10:24, 17 September 2015 (UTC)
  • Support. Bazj (talk) 15:40, 18 September 2015 (UTC)
  • Support. HTTPS means your ISP and your employer and anyone listening in can't (in general) tell what page you are accessing (they just know it is Google or IA). This is an important privacy feature which we should share with our users. filceolaire (talk) 22:58, 22 September 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This RfC completely missed the fact that locations that use proxy servers will break secure links since they would end-up proxying the secure link but will not have the certificate. Bad idea. Walter Görlitz (talk) 04:13, 17 October 2015 (UTC)

  • I'm not questioning the merit of the RfC, but it is less than optimal that the same user who made the proposal also closed the RfC as "near-unanimous". It is mildly surprising that this was not brought up a month ago. However, I don't think this is the end of the world, so c'est la vie. Regards. --64.85.217.45 (talk) 00:54, 27 October 2015 (UTC)
(Appears to now have been reclosed by an uninvolved editor a few weeks ago, so striking comment.) Rgrds. --64.85.217.45 (talk) 07:16, 7 December 2015 (UTC)

If it is true that this change will make life much more difficult for readers suffering under oppressive regimes and that need to use proxy servers to circumvent oppression, then this is sufficient reason not to make such a change - however many coddled westerners 'vote' for such a change. BushelCandle (talk) 16:01, 28 February 2016 (UTC)

@BushelCandle: In the long-run, even Wikipedia readers from repressive countries will benefit from this decision. Because given HTTPS, repressive regime face an all-or-nothing decision for censoring websites like Google News or Internet Archive (see for instance, Russia's censorship of archive.org in July 2015). --bender235 (talk) 00:35, 12 May 2016 (UTC)

I just want to add a technical opinion. By retrieving the http version and then the https version one can compare if they are the same and then (automatically) change the url protocol. And if the page is loaded any way there's an opportunity to check sum the page while at it and include in the reference. Anyone not able to get to https links can change the protocol manually. Bytesock (talk) 23:16, 19 May 2016 (UTC)

Enabling VisualEditor for existing accounts which are dormant or inexperienced

Latest comment: 9 years ago45 comments22 people in discussion
Update: Thank you everybody for your feedback. Based on certain points made in the discussion by some community members, we have been re-considering whether some kind of easy opt-in prompt when people use the wikitext editor may be a preferable approach to rolling out wider access to the visual editor for existing editors.
For now, we will not go ahead with the changes we suggested in this proposal, and I'll come back with a different proposal when we are ready.
Yours, Jdforrester (WMF) (talk) 14:10, 21 September 2015 (UTC)
I'm adding the Archive templates for clarity. --Elitre (WMF) (talk) 19:18, 23 September 2015 (UTC)

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

Over the last few months, we slowly expanded the availability of VisualEditor as an option for new editors. This is now complete, which means that all accounts registered from now on get the choice to use VisualEditor.

Though VisualEditor is useful to both experienced and new users alike, we are yet to offer any choice to existing, inexperienced users. People with an existing account can and do opt-in to use VisualEditor, and there are a number of experienced editors (like those who read this page) who choose to use it. However, the vast majority of people are casual, irregular editors who come back every few months or so (or never). They do not change any of their settings, and most of them likely don’t even know they can. Offering VisualEditor to them as merely an opt-in preference is hiding it away.

Consequently, I think we should make VisualEditor available to all existing, inexperienced accounts, and for dormant accounts. By this I mean those who have not yet made many edits (fewer than 1000), and those who haven’t edited at all for a while (perhaps three to six months). I am not suggesting a change of status for active, experienced editors, as many of you have made the decision to not use VisualEditor, which I respect. This change would also not provide VisualEditor to anonymous editors, who I think deserve a separate community conversation about how that can take place, at some point in the future.

  • For casual, inexperienced editors, this would mean that they don't need to know about preferences to have access to both the wikitext editor and VisualEditor.
  • For any returning experienced editors, access to both the wikitext editor and VisualEditor would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months).
  • For all experienced, active editors, your current preferences will of course be honoured. For the thresholds I have proposed, about 20,000 editors; if you are reading this, you know about the Village Pump, so this almost certainly means you. If you have VisualEditor enabled, it would remain enabled. If you don't, then it would remain disabled.

The location of the preference switch will be moving soon to the "Editing section of Special:Preferences. This will bring the English Wikipedia into line with the majority of other Wikipedias, like French, Russian, or Italian; see this link to the French Wikipedia's preference screen for what that will look like. This will not mean that VisualEditor is "complete" or that it is out of "beta" though – there are still lots of improvements yet to make, not least integrating wikitext and visual editing together properly and removing the hack of having a second edit tab that jumbles up the interface. I have no intention of forcing anyone to use VisualEditor.

The choices about whether, at which thresholds, and exactly when to do this, are up for a discussion, and I would appreciate suggestions. I think this change would be a reasonable change without disrupting things for most users. Thoughts?

Jdforrester (WMF) (talk), Product Manager, VisualEditor – 17:55, 2 September 2015 (UTC)


Discussion

Sounds like a low impact plan to me. —TheDJ (talk • contribs) 15:33, 3 September 2015 (UTC)
+1. This would be very helpful for the education program, especially for making sure all the student editors who just created accounts in the period before the VE rollout hit 100% all end up with the same settings.--ragesoss (talk) 16:51, 3 September 2015 (UTC)
  • Hold on. Where is the statistical data on the impact of the change with new editors that was promised? And what is the advantage of changing the preferences of accounts that are minimally or not active? And since the issue of preferences is raised, would it not be better to do some user education on preferences instead of changing them without editor participation? On what basis is it assumed that the editors had not made a conscious decision to leave VE not included? That calls for some A/B testing before implementation. I'm still baffled why VE has been activated in the Wikipedia/project namespace, an area that requires user signatures on more than half its pages, based on a single user's request. Risker (talk) 19:00, 3 September 2015 (UTC)
    @Risker:
    TL;DR: This proposal is mostly based on what is best for inexperienced users, and server performance issues. The real question is how to solve the server issues without adversely disrupting things for any editor group.
    Where is the statistical data on the impact of the change with new editors that was promised?
    Did you mean the statistical data about the A/B test? The report and data from that is on meta. Did you mean the gradual release to new users? As promised, after the first step in that process last month, I reported back on how well it went, before increasing the rate to a larger proportion and monitoring from there.
    If you're looking for detailed numbers, there's an awful lot of statistical data provided in our dashboard at https://edit-analysis.wmflabs.org/compare/ but it's not very friendly, I'm afraid. (Cleaning that dashboard up so that those who don't have as much time and patience to pour through it is on our list of things to fix.)
    And what is the advantage of changing the preferences of accounts that are minimally or not active?
    Enabling VisualEditor in Beta Features for ever-more users adds a mess and (albeit minor) cost to the database, and thus site performance. There are already almost a quarter of a million accounts opted-in to VisualEditor, and letting this continue to grow (by more than another hundred thousand each month) is not great, technologically, and needs to be fixed for site stability reasons. (I hate to invoke WP:PERF, but…)
    More importantly, however, Beta Features is not and has never been designed for anything other than users actively opting in to new things – it's both confusing and poorly designed for this use case, wherein ever more users get accounts only to find that the system has them "opted in" to having something they haven’t actually explicitly opted into. I don't to be part of adding even more confusion to editing Wikipedia; it's already too hard.
    And since the issue of preferences is raised, would it not be better to do some user education on preferences instead of changing them without editor participation?
    Though I think that educating users is a worthy initiative, that's the equivalent of suggesting we write clearer warning labels on people’s tax forms – for most people in the target audience they would never be seen, and for everyone who already knows, it would just get in the way. Education features are a serious area for further work, regardless of whether the user is writing content or engaging in a discussion.
    On what basis is it assumed that the editors had not made a conscious decision to leave VE not included?
    As you will see in the A/B test report, over 99% of users made no changes to their preferences about VisualEditor; 35 users opted out, and 110 opted in.
    That calls for some A/B testing before implementation.
    A careful A/B test over several months might be worth considering with some interstitial or otherwise calls to action ("Hey there, do you want to opt in to our old skin with more buttons?" and so on for a variety of options), but I do not think it would be appropriate for this use case.
    Yours, Jdforrester (WMF) (talk) 00:30, 4 September 2015 (UTC)
  • No for experienced editors. It's annoying as hell when you step away for a few months and have your preferences changed. They were not set the way they are by accident. Additionally, the changes are often incredibly difficult to figure out how to reverse for the average editor. I often spend the first day after I come back from a long break reading VPT archives which is frankly ridiculous. Ambivalent for new editors, though looking at the last half hour on my watchlist I note VE still has serious problems. Jenks24 (talk) 19:44, 3 September 2015 (UTC)
    @Jenks24: Understood. How many months do you think would be adequate, if not three? Six? Nine? The scientific research done on people who stop editing shows that a timespan longer than a month and less than six months is most likely to be useful for this. If an editor is inactive for more than a month, they are likely to not be active for a long while. If they are going to come back after this long period of inactivity, it will mostly likely be between six months and one year since their most recent edit. [6] and [7] (PDFs both) may be of interest. I appreciate that there are always outliers, but the goal is to set preferences in a way that works for the majority of users. Jdforrester (WMF) (talk) 01:10, 4 September 2015 (UTC)
    @Jdforrester (WMF): what benefit will it be to the long-term user if they return? I admit I haven't read either of those papers, but just skimming the abstracts it doesn't seem to address that? If someone has made 50,000 edits in the 'old', wikimarkup style, surely getting used to VE will actually be more difficult than just doing things as they've always done. From personal perspective, the more things that are different coming back from a break the more difficult it is to get back into the swing of editing. I appreciate that in a lot of cases changes need to be made and I'm not saying "change nothing", but I fail to see the benefit of making an unasked for change to long-term experienced editors simply because they take an extended break. For example, look at all the unlinked names at WP:WBE (meaning they haven't edited for a month) – can you imagine any of them being pleasantly surprised when they log back in to find that VE has been activated on their account? If things are too hard or too different these returning editors will simply not bother. I don't think timeframe is the right way to be looking at this. Jenks24 (talk) 02:01, 4 September 2015 (UTC)
    @Jenks24: You're right, those papers aren't specific to any one change, but are about user behaviour and how likely people are to come back and edit once they've ceased editing for a while. I understand your concern about not adding any extra ramps and bumps that might dissuade returning editors from, well, returning. However, several long-term editors, especially returning long-term editors, tell us that they actually prefer VisualEditor, and have found that it increases their productivity. Consequently, I would realistically expect even long-term editors who are battle-hardened in using wikitext to be pleasantly surprised to discover that Wikipedia can be edited in the same "visual" ways that they use every day for editing word processing documents and e-mail messages. If you don't think timeframe of last edit is the right way, what way would you recommend? Jdforrester (WMF) (talk) 20:50, 4 September 2015 (UTC)
    @Jdforrester (WMF):Hmmm, fair enough, it could just be that I'm stuck in my ways and others are more embracing of change. I still generally dislike the idea of changing the preferences of editors simply because they are away for an extended period though. I prefer Kerry's suggestion below using a combination of how old the account is and how many edits it's made – obviously that's not an exact science, but still gives a reasonable indicator of how experienced an account is. I don't mind trying it on all accounts <1000 edits and then if that's successful maybe moving on to <5000, but that's about as far as I think it should go. If there is a concern that editors with more experience than this who have been away would miss out on learning about VE, I would not be opposed to some sort of automatic talk page message for anyone who takes a break of, say, six months or more between edits (it could even be less than six months if you thought it really necessary). Jenks24 (talk) 02:33, 5 September 2015 (UTC)
  • +1. That VE would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months) is quite a stretch to claim. By "performance improvements", I presume you mean HHVM, which is AFAICT a totally back-end change having no effect whatsoever on user settings, quite unlike VE. BethNaught (talk) 19:49, 3 September 2015 (UTC)
    @BethNaught: About 150 changes went live to this wiki just this morning (as happens every Thursday for all Wikipedias), and though individually most of the changes are relatively minor, collectively they make quite a change over time, especially when we’re talking about several months.
    HHVM, though an excellent piece of work, was done almost a year ago, and wasn't what I meant. Beyond my team working on VisualEditor to make it faster, I'm talking about the brilliant work done by my colleagues working on other things, from the Performance team to the Discovery department. For example, in just the last month the former have cut the average "firstPaint” time from roughly 1.3s to 0.8s, making the site feel massively faster for the majority of users. (You can play with a few of their numbers on their performance dashboard.) Similarly, the latter are working to redesign of the Search interface, over-hauling it to provide better, more accurate and more useful results for our readers and editors alike. Some early examples were presented at the public meeting this morning, and the slides are on Commons (PDF).
    By the bye, the impact of HHVM was to make loading VisualEditor about 10% faster, which we believe led to an increase in VisualEditor's use on wikis where it is used more widely, so it's not quite true to claim that back-end changes have no effect on user experience and take-up. :-) Jdforrester (WMF) (talk) 01:25, 4 September 2015 (UTC)
    If I'm not mistaken, all of the things you specifically mention are back-end changes. None of those things change the way people edit – they may have effects on it, but they do not change the manner of editing. Enabling VE would be totally different. I imagine a returning experienced editor who had had VE enabled in this proposed change would feel exactly like I do when I visit other Wikipedias: click on Edit, curse with surprise and/or confusion, and have to work out how to leave VE. Then they would have to either find the setting to turn it off or break the habit of a Wikipedia lifetime and relearn the meaning of the most fundamental button on the site. – This is no way to welcome returning editors back. BethNaught (talk) 20:48, 8 September 2015 (UTC)
    Beth, it seems that not everyone has the same experience. A more typical reaction to discovering VisualEditor appears to be surprise and interest, or even surprise and pleasure, rather than surprise and cursing. Given the opt-out rates, I believe that your personal reaction is not typical – though naturally one of the goals is to avoid offering VisualEditor to people who are likely to share your reaction, just as one of the goals is to offer it to the people whose reaction is likely to be the opposite.
    But I think you're missing the main point: At what point do you think we can assume that this probably won't be a disturbing for most of the accounts? When the accounts in a given group are so stale that 90% of them won't ever edit again? When 95% of them won't? When 99% of them won't? There will (I hope) be a few false positives (because I still hope that all of my long-absent friends will return, even if all they do is tell me that they're alive), but what level of false positive (=we thought they wouldn't return, but they did) are we willing to tolerate? Similarly, at what point does one typically acquire "the habit of a Wikipedia lifetime", and therefore the presence of two editing buttons might cause temporary disruption? After 500 edits? After 1000? After 5000? Or is there some other quality that is more predictive than how recently the person edited and how many edits have been made? Whatamidoing (WMF) (talk) 22:54, 8 September 2015 (UTC)
    Jenks24, that is a direct result of VisualEditor having been activated in Wikipedia namespace without any notice or discussion with the community as a whole. Editors who are used to working in project space all know that VE doesn't work there - or it didn't until about 36 hours ago. The majority of edits to Wikipedia space require either (a) a signature - not possible to do in VE or (b) a template that isn't in VE's "dictionary" or (c) both. I've asked for this to be reverted at T100067. Risker (talk) 20:22, 3 September 2015 (UTC)
    This was us responding to a user request, and has been reverted pending community reconsideration. It’s off-topic to this proposal, but happy to discuss in another thread or (probably better) on the discussion on WP:VE/F? Jdforrester (WMF) (talk) 00:32, 4 September 2015 (UTC)
  • As someone both using the VE for a lot of my edits (not all) and someone who teaches new users to edit with Wikipedia, I think the Visual Editor does make life a lot easier for the inexperienced editor. I doubt most of these recent signups who wer not currently opted-in even know that the Visual Editor exists, let alone have made a conscious choice to stay opted-out. I don't think it unreasonable to roll it out to these folks (assuming some clear explanation is put on their User Talk page along with step-by-step opt-out instructions, if they desire to do so). What the threshold of "newness"/"inexperienced" should be? I'd say start small - signedup in the last 2 months and less than 100 edits. Wait and see how that group react. Do they rush to opt-out? Do they use the VE? Do they complain? If nothing very bad happens, gradually expand the parameters to increasingly wider groups of people while there appears to be benefit in doing so. Then when it's only the more experienced editors left (say, signup over 1 year ago or more than 1000 edits), leave a message on their User Talk page reminding them of the availability of the VE and how to opt in.Kerry (talk) 07:29, 4 September 2015 (UTC)
    I like Kerry Raymond's idea. ~ ONUnicorn(Talk|Contribs)problem solving 15:28, 4 September 2015 (UTC)
    @Kerry Raymond: Thank you for your support, and the huge amount of feedback you've provided in the past few months. You have been a key part of making VisualEditor what it is today. Unfortunately, the kind of high-scale ramped approach you suggest would exacerbate the performance problems I mentioned above. (After all, we're talking about 26,109,385, of whom over 99.5% are currently inactive, and probably 98% will never edit again—but all of whom would have to have their preferences set.)
    I have considered options around this. If it is really important, we could do a fairly expensive (in computing terms) pilot. We could opt-in about 50,000 of the new-ish, active accounts that would be affected under this proposal. Based on the opt-out results that we saw with the A/B test back in May, we realistically expect that about ten out of the 50,000 accounts would both be active and choose to opt-out of VisualEditor. (About three times as many accounts switched the other way when we tested.) I’m not sure this would be the kind of information for which you're looking, though?
    Alternatively, we could assume that the experience here would be similar to the experience at other large Wikipedias. Even if you include active, experienced editors (which I am not proposing), the opt-out rate at other Wikipedias amounts to maybe less than 0.1% of all accounts. Less-experienced editors are less likely to opt out, and of course unused accounts never change their preferences. Even if the English Wikipedia opted out at a rate ten times the typical rate, it would still be a relatively small group of editors affected. Jdforrester (WMF) (talk) 00:35, 5 September 2015 (UTC)
Sorry if I was not clear. I was only proposing a rollout to inexperienced editors (at whatever pace is reasonable for performance considerations) and was not suggesting roll-out to dormant accounts (say, inactive over a year). I think the best action with dormant accounts would be to be trigger a "Welcome back" talk message on any reactivation of the account letting them know what's changed since they've been last been on-wiki (which is worth doing for reasons other than just the VE, e.g. paid editing policy). Kerry (talk) 02:25, 5 September 2015 (UTC)
Although I agree that would be nice in an ideal world, in a world with 150 changes going out each week, that would be .. difficult. What makes the list ? How big can the list be ? isn't 99.9% (even of the most important changes) going to 'off' the list by definition ?? —TheDJ (talk • contribs) 10:22, 6 September 2015 (UTC)
This might be a red herring but in terms of confusing existing editors, the only thing I can see that is confusing if the VE were to be enabled without their knowledge is that they would go from having one "Edit" tab to two "Edit source" and "Edit" tabs where the meaning of "Edit" has changed from source to visual. I can see that as potentially confusing. But if the tabs were "Edit" and "Edit visual", then that confusion would be reduced. Their familiar Edit tab would do what they expected (invoke the wikitext editor) and the "Edit visual" would be new and I think moderately self-explanatory. Having said all that, statistically do we actually have a problem with experienced editors trying to return from a break and being unable to edit? We know we have a problem getting people over their "early edit" curve, which this conversation is about. Kerry (talk) 03:01, 5 September 2015 (UTC)
  • Just a question on the performance impacts. Why not do a mass rollout the other way around, make it default? Instead of tracking opt-ins, track opt-outs. Do it in steps, anyone (like me) who currently doesn't use VE would get a notice saying it was going to become the default and have us choose to opt-out if we don't want to use it. After an arbitrary length of time, switch, so that only those who opt-out don't have it. Same with new users, instead of letting them opt-in to using it, have them opt-out of not using it. I'd assume fewer would ever opt-out than have currently opt-in. Jerod Lycett (talk) 02:51, 5 September 2015 (UTC)
    @Jerodlycett: I'm not sure mass-messaging 28 million accounts (either on their talk pages or in some other way) telling them we're about to opt them in, and that if they don't want it they'll have to opt themselves back out once it's done is a very friendly step. :-) Also, all new accounts already get opted-in to having both available; this is about how to move to a better situation technically without disrupting things for existing editors for whom we don't want to suddenly change things. Note that "doing it in steps" means keeping track of millions of users with different preferences, which is the exact thing we're trying to avoid performance-wise. Jdforrester (WMF) (talk) 16:07, 7 September 2015 (UTC)
    @Jdforrester (WMF):I must have misread the conversation. It seemed like right now you have an ever-growing table of people who choose to use VE, and if it was set as default that would balloon the table. My question was about instead having a table of opt-outs. So that right now we'd switch it so that all new users would have to opt-out (I'm assuming, and this is the question part, that fewer would opt-out than would opt-in). Also for messaging, I suggested a notification, like when you get pinged, not a message on the talk page. A question on that, if there was a change made to the default skin how would you go about the change? I've just assumed that it'd just be "All these editors chose to use the default, the default is changing, they're still using the default." and the same logic seems to apply here. All these old editors chose to use the default editor, and the default editor will have changed. They can choose to not use it. Anyway, the steps would be to use both opt-in and opt-out tables for a time, then drop the opt-in table and only use the opt-out table. Either table will (potentially) grow to infinity, I just think opt-out would grow slower. Another question though, what happens if I opt-in, decided I don't like VE, and opt-out, is there an entry in there for me, or does it drop that entry? Jerod Lycett (talk) 17:00, 7 September 2015 (UTC)
    A few points that may be useful for consideration (pinging Jerod Lycett and James F.):
    As noted above, all brand-new accounts already have access to VisualEditor. It's available, but they don't have to use it. If they don't want to even see the option, then they can opt out. When we did a 50-50 test in May, about 99% stayed with whatever they were given. Of the remaining 1%, about three new editors opted in for every one editor who opted out. I think you are correct to assume that fewer people will opt-out than will opt-in, at least among inexperienced editors.
    You are correct that the main problem is "an ever-growing table" of prefs settings. However, because of the sheer number of accounts involved, it doesn't matter much whether the setting is a million accounts opted in via Beta Features or a million accounts opted out via regular preferences. "Do it in steps" is not technologically feasible. The developers cannot gradually opt in a million here and a million there until all 26,132,779 have been processed. This will (unfortunately) need to be an "all at once" thing.
    However, it does not need to be an "all the same" thing. The devs can set prefs on or off for each group of accounts. Whether any given account is on or off can be based on our best estimate about which types of accounts would prefer which settings (including which ones are unlikely to ever be used again, so that it just doesn't matter).
    Consequently, this is the main   Question: What are the characteristics of accounts that will (mostly) want to be opted in, and what are the characteristics of accounts that will (mostly) want to be opted out? For example:
    • We should probably put the 280K (and rising rapidly) accounts that are already opted in into the list of people who will probably want access to VisualEditor. This will prevent changes for those editors.
    • The many millions of accounts who haven't edited for months or years should probably go in the "do whatever is least strain on the servers" list (which happens to mean opting them in).
    • Relatively recent newbies should probably go in the "get VisualEditor" list, since we already know that three times as many choose to opt-in as choose to opt-out.
    • Active editors without VisualEditor but with advanced user rights (e.g., admins) should probably go in the "don't touch my preferences" list. (On second thought, maybe I shouldn't have pinged James F. while mentioning another way to complicate the database work.  ;-)
    • —and so forth, through whatever characteristics you think are important.
    The system doesn't allow multiple prefs settings for the same thing. This prevents editors from setting contradictory preferences, i.e., both opting in and opting out. As a result, we can move from one system to the other (this is the proposal), but we cannot maintain the current opt-in prefs list and a separate opt-out prefs list at the same time.
    Sadly, one cannot use Notifications ("Echo") to send a mass message. The software does not have the ability to do so; this is long-requested (phab:T58361 and phab:T77347). Whatamidoing (WMF) (talk) 23:54, 7 September 2015 (UTC)
  • Absolutely not While I understand WMF believes Visual Editor is a good thing, I disagree. Visual Editor doesn't work as well as learning the coding. It doesn't help new editors learn what they need to know and actually makes editing hard when new users attempt it at edit-a-thons led by experienced Wikipedians that don't use Visual Editor. There's no reason to punish "dormant" accounts with VE, either. Just kill off Visual Editor and admit it's a lost cause. Chris Troutman (talk) 22:14, 8 September 2015 (UTC)
  • Strong Oppose - I'd rather not have the possibility of returning editors erroneously clicking on a gadget they didn't enable and getting confused when looking for the normal editing system. Though I don't care for the gadget, I can understand the argument for better presenting the option to brand new editors (though they may have edited as an IP). Personally I think editors should be encouraged to use the traditional editing system.—Godsy(TALKCONT) 12:08, 9 September 2015 (UTC)
  • Oppose This strikes me as an attempt to jam VE's foot further in the door so it'd be harder to shut. The logic of this proposal is also warped. It says that because we offer a choice to all new editors yet some inexperienced editors didn't have a choice, we will make the choice for them for them. Send them a message asking them to try VisualEditor. Show them how to switch between the choices and ask them to complete a survey in a week and say with they prefer and why. Jason Quinn (talk) 14:55, 9 September 2015 (UTC)
  • Strong Oppose Visual Editor sucks. It sucks. It absolutely, completely, totally, and utterly SUCKS. It sucks now. It always has sucked. Outside the realm of misty-eyed wishful thinking, it always will suck. Fiddling with it, tweaking it, enabling it under certain conditions, and so on is really just polishing a turd (see also sunk cost fallacy). I admit that that's a flawed metaphor though: turds are unpleasant, but they certainly are cheap. Visual Editor, on the other hand, has wasted incalculable amounts of donors' money and volunteers' time. But the solution is the same: they both need to be flushed and forgotten. Andrew Lenahan - Starblind 15:26, 9 September 2015 (UTC)
  • Opposed. Please don't fiddle with my food while I'm away from the dinner table. GenQuest "Talk to Me" 15:36, 9 September 2015 (UTC)
  • Support 0.5% accounts are active. Let's face the reality. We may consider deactivating/closing old accounts altogether instead of discussing what would their default preferences be on a website they don't use at all for years. On the other hand, I miss the Wordperfect possibility to edit code every time I use MSWord, FWTW I still do not understand why a wikicode edit interface such as WikEd is not available for experienced users or at the very least, a default editor with syntax highlighting. Afernand74 (talk) 17:08, 9 September 2015 (UTC)
    Um, wikEd is available for all logged-in users? What are you trying to say? BethNaught (talk) 20:20, 9 September 2015 (UTC)
    I was trying to say that the WP default wikicode editor is not really human friendly imho. Some improvement here would be welcomed.
  • In my opinion this proposal, as it regards inactive users, sends a symbolic message which is highly undesirable, namely: "we wrote some new software but the existing software can't cope with it being on by default, therefore we are going to unilaterally change your fundamental editing experience to gloss over the difficulty we've been having in implementing our controversial new software." What I'm trying to say is, don't use the limitations of the MediaWiki preference system as an excuse to force VE on currently inactive accounts (conveniently increasing the VE adoption rate), instead fix the preferences system. I don't care how small the percentage of pissed-off returners may be, there is morally no need for it to be greater than zero. BethNaught (talk) 20:20, 9 September 2015 (UTC)
  • Strong Oppose. Based on my reading of the results here, the Visual Editor simply doesn't seem to helpful in any significant way (and, depending on how you read the slightly longer time to save, may even be harder to use.) In particular, the total failure to show any improvement in editor retention undermines the entire reason the Visual Editor was created in the first place, doesn't it? Given that splitting the userbase and offering multiple ways of editing has intrinsic disadvantages, the negative results from that study strike me as enough of a reason to halt any efforts to encourage its use. It was an experiment with noble goals, but it was still ultimately just an experiment, and it hasn't worked out -- continuing to try and push adaptation at this point, with no evidence that it's actually achieving anything worthwhile, strikes me as falling into a sunk cost fallacy with regards to the amount of resources that were already wasted developing it. --Aquillion (talk) 21:56, 9 September 2015 (UTC)
  • Strong Oppose as my concerns raised at Wikipedia:Village_pump_(proposals)/Archive_125#Gradually_enabling_VisualEditor_for_new_accounts still haven't been addressed. There is no proven benefit to Visual Editor, and it still has significant issues that have not been fixed. The May 2015 study looked at a population of 20,000 editors, half of whom had VisualEditor enabled as default. Of these two groups, nearly identical numbers (3386 vs 3363) made an edit, nearly identical numbers (2502 vs 2551) edited more than one article, nearly identical numbers made productive unreverted edits (1778 vs 1772), and an identical number were still editing 3-7 days after registration (287). If anything, this shows that Wikicode doesn't scare off new editors any more than VE does. So what's the reason for the switch? What problem are you trying to fix? I'd want to see evidence that VisualEditor has a significant positive impact on editor retention and constructive contributions before it's rolled out. We shouldn't have to start cleaning up <nowiki/> tags everywhere for no good reason. --Ahecht (TALK
    PAGE    ) 22:51, 9 September 2015 (UTC)
  • Strong oppose If people want their settings changes they can change them. We do ourselves a disservice by hiding the complexity of wiki code from them with a pretty GUI, using automated tools to edit manually created mark up is only going to result in people changing things they do not understand. That editor is a pain in the ass and frankly I think if it was really something the community wanted it is something they would have embraced, rather than something that needs to be slowly pushed on them. The lack of interest should be a strong clue. I understand the foundation is invested in this, but the community rejects things that people have invested in all the time, we all of to deal with that. Chillum 15:10, 11 September 2015 (UTC)
  • Question For people who have Visual Editor enabled, is there any data on what percentage of their edits are made using it vs. editing the code? I saw it as a beta testing option and enabled it, but I rarely use it because unless it's a simple typo fix (e.g. adn -> and) editing the code is much easier (for me at least). Before enabling it for more people, I'd like statistics on how much use it gets amongst people who already have it enabled. ~ ONUnicorn(Talk|Contribs)problem solving 17:37, 11 September 2015 (UTC)
@ONUnicorn: For your question about how much people are using the visual editor, this dashboard has some specific numbers – on Wednesday, about 1000 editors who joined post-2013 used the visual editor, against about 3000 who used the wikitext editor (some will have used both, of course). For "old hands” editing from before 2013, the numbers are 168 and about 5000. By comparison, for the French Wikipedia (where the visual editor has been available to all for years), the equivalent numbers are 229 using the visual editor and 352 using the wikitext editor for newer editors, and 118 against 802 for older editors; both groups edit less than logged-out editors, however.
There's a whole bunch of other data that we now publish at our more modern dashboard, and that might interest you as well. This covers numbers related to editing tools, each split between the wikitext editor and the visual editor. It's a bit of a thicket, but you can learn some odd things from the data (when it isn't subject to data interruptions and corruptions; it's still a work in progress).
For example, here's the last fortnight's average data of 'edit success' (what proportion of times the editor was loaded and the resulting edit was finished and saved), comparing the visual editor to the wikitext editor by the 'cohort' of how many edits the user (account) had ever made before that edit:
Cohort All wikis English Wikipedia French Wikipedia Δ between editor software
VE WT VE WT VE WT
IP editors 16% 3% N/A 6% 20% 2% Greatly better with the visual editor
1st edit 31% 18% 34% 18% 35% 18% Much better
2nd–5th edit 41% 28% 42% 35% 44% 32% A fair bit better
6th–100th edit 51% 45% 51% 51% 55% 49% A bit better
101st+ edit 59% 58% 61% 58% 55% 61% About the same
As you can see, there's a dramatic difference for the first few edits, but it's not as profound once you've learnt the ropes of what kinds of edit get reverted and how to write an edit that other people will like. There's also plenty of anecdotes about how using the visual editor is pleasing for some experienced editors, but that kind of fuzzy happiness won't have much impact on the hard numbers that this dashboard shows.
If you want, you can play with this data for yourself at https://edit-analysis.wmflabs.org/compare/ as different wikis have different editing patterns. (Note that data for some wikis' cohorts are very shallow as they don’t get many edits – for example, here on the English Wikipedia, IP editors don’t see a tab for the visual editor, so numbers there are for the few developers and test bots loading the editor in testing.)
When we talk about the value of the visual editor for editors, it sounds abstract and possibly wrong, but hopefully this gives some context. It's used millions of times (over a million times on this wiki alone), and is clearly liked and useful, however much those of us who prefer wikitext don't want or need it. :-)
Jdforrester (WMF) (talk) 21:08, 11 September 2015 (UTC)
If I'm reading this right, that means that on Wednesday the normal editor was preferred over the Visual Editor by a 3.2 to 1 among new users, and a staggering 33 to 1 among old users ( with anons it's not really a fair comparison, but the number is a ghastly 112 to 1). With that degree of rejection do you seriously, genuinely, and with a straight face say that this is good software with a bright future? Heck, more people liked New Coke than this abysmal flop. Andrew Lenahan - Starblind 00:29, 13 September 2015 (UTC)
What the old dashboard shows is that VE usage is related to many factors, availability being a main one, and the reason for proposals like the current one (nothing like all existing registered editors have VE enabled; it's the same for new registered editors). This is perhaps clearer when looking at the data for wikis where anonymous editors get the VE tab. Basically, there slightly more people who use VE than those who use wikitext, with variance between different wikis based on lots of reasons (fr - he - ru - sv - it). We also know that VE is even more popular in some communities for which unfortunately we don’t have dashboards available (like the Catalan Wikipedia). Anyway, it only makes sense that there are more edits made with wikitext: the wikitext editor is plumbed into many more things, like the 'undo' button (so those are never VE edits); you can’t do literally everything with VE yet; and even edits started with VE but finished in wikitext mode count as “wikitext” ones. HTH! Elitre (WMF) (talk) 11:42, 17 September 2015 (UTC)


  • Strong Oppose - To be absolute blunt it's shite - It was shite last year and it's shite now, Learning how to use wikitext is great and can help you develop skills in the IT area whereas using a crappy editor that does everything for you gives you no knowledge at all, I know this may sound sad but when MySpace was the new thing and everyone could use HTML/CSS - I loved it and at that time so did everyone else, So personally I feel Wikitext is far more knowledgeable to people than VE and so I don't believe it should be enabled for inexperienced/dormant accounts. –Davey2010Talk 01:15, 12 September 2015 (UTC)
  • Support - VE is working pretty well for basic gnoming, and newbies at editathons do much better with it. It was confusing at a recent event when one newbie had VE enabled, but one didn't. For experienced editors, I'm fine with leaving VE in the preference menu for now. VE has some glitches, there are some fancier things I can't get it to do, and once in a while, it's choked up on me, but overall VE is much, much faster than wikitext for basic copyediting and upgrading citations. Copyediting and citations are what new editors need to do, and unless the new people come in with a strong HTML background, VE is working for much better for them than wikicode at the events I've attended. I'm interested in getting the expertise of people who can't be bothered to learn Wikitext-- so I'd like to see VE enabled as a tab, as long as it is still possible to switch to the "edit source" tab. No need to further antagonize expert editors by enabling VE for them.
My overall impression is that there is a big group of nights-and-weekends coders here who feel their hobby coding project is the whole point of this encyclopedia, and that the content and experts contributing the content are an afterthought. It seems doubtful to me that a sustainable Media Wiki with fast response time, high reliability, chat / messaging capability, and full spectrum multimedia support is going to be built by a group of hobbyist coders making volunteer contributions in their spare time-- no matter how experienced, talented, or dedicated they are! Volunteer-driven, "whoever shows up" projects always have some rough edges, where no volunteers showed up, because that piece of the puzzle required way too much work that was no fun for volunteers. I am hopeful that Lila's initiatives to create a working software development organization of full-time professionals will continue to bear fruit, so that we can start to re-focus the organization on what's most important, which is the content and performance of the encyclopedia, and the health of the community which supports it. I wish the technical side of the organization all the best as they attempt to incorporate the input of a passionately opinionated volunteer developer community; and I urge the developer community not to view people unwilling to learn wikicode as unworthy of participation as Wikipedia editors.
For all the people who hate VE, let me give you a challenge: I get more edits done in less time with VE for routine quality control of fixing bare urls and adding cites. Hotshot coder folks, try your own A-B experiment: Pick any WikiProject cleanup list, and try fixing bare URLS and adding citations, with VE and without. Try out the "Automatic" URL feature for adding quick cites from major outlets like BBC and Googoe Books. Could you do this task just as fast both ways, VE and wikicode? Fixing citations and adding citations is not glamorous work, but it needs to be done, and if VE makes this important task quicker, is it really such an awful thing? Yes, it's a waste of skills to ask people with major coding talents to spend their time fixing bare URLs and adding citations, but if the coder folks never try it for themselves, they're unlikely to appreciate the difference VE makes, especially for less skilled typists who are in the 45 WPM range and make errors. --Djembayz (talk) 13:01, 23 September 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Propose adding "Social media" or "Verified social media" parameter to relevant infobox templates

Latest comment: 9 years ago6 comments6 people in discussion

My main reason for thinking that these references may be of use for readers is the prevalence of false accounts. This addition would better enable readers to find official and verified accounts.

The blank template for such a parameter might present something on the lines of:

| Social media = <!-- Due to the prevalence of fake accounts associated to notable people and organisations, all entries must be verified. Use main platforms used preferably using format: [[https://example reference|name of platform]] or, in cases where facility is available -->

Should editors agree to the development of further templates we might also add information on the use of contents such as {{facebook|/example}} {{twitter|/example}} {{youtube|/channel/example}} etc.

These later formats may be of use if at some time in the future, a decision is taken to replace platform names with platform logos/symbols.

GregKaye 07:57, 20 September 2015 (UTC)

Maybe you should get and add these values from Wikidata, so other wiki's can profit from this. There is already some data there. Sjoerd de Bruin (talk) 09:27, 20 September 2015 (UTC)
I'm not sure I understand the reasoning here. But if this proposal would require a social media account in order to get a Wikipedia account, I'm agin it! If it makes it harder for people world such accounts to get Wp accounts, I'm inclined against it. --Thnidu (talk) 02:32, 24 September 2015 (UTC)
Not sure why an encyclopedia would want this information. Also, Info boxes are [should only be used] to summarize what is in the body of the article. GenQuest "Talk to Me" 12:06, 24 September 2015 (UTC)
Not sure whether, or which, social media sources might be WP:RSes. Wtmitchell (talk) (earlier Boracay Bill) 12:25, 24 September 2015 (UTC)
WP:ELMINOFFICIAL Bazj (talk) 13:00, 24 September 2015 (UTC)

Request for input on video proposal

Latest comment: 9 years ago1 comment1 person in discussion

Dear Wikimedia colleagues:

I am developing a proposal for a video series that's designed to introduce Wikimedia to new contributors (particularly in GLAM and education programs), and to motivate them to participate in the community in a constructive way. I would appreciate your input. The video is intended for translation into multiple languages; there are already volunteers for Spanish, German and Greek translation.

The proposal's main draft page is here.

The proposal talk page is here; it includes a draft outline of specific subjects that the video may cover.

Please note that the scope and budget of the project are still under consideration. At this point it would be especially helpful to have input on the subjects that the video should cover, and how best to cover them. This information will help as the project scope and budget are refined.

Please add your questions and comments to the talk page.

If you would like to support the project with your endorsement, please do so here

If you would like to volunteer to translate the video, please email me or comment on the talk page.

Thanks and regards,

--Pine✉ 22:13, 24 September 2015 (UTC)

Allow any level of redirection in WhatLinksHere

Latest comment: 9 years ago3 comments3 people in discussion

Special:WhatLinksHere should allow stopping at any level of redirection, the default being to show the WhatLinksHere page (indented) only up to double redirects. GeoffreyT2000 (talk) 01:02, 17 September 2015 (UTC)

Whenever I see a proposal like this, I feel compelled to ask the proposer to explain why their suggestion is a good one. Double redirects (let alone triple or quadruple) are a bad thing and in most cases are deleted or re-targeted to bypass the second redirect. I'm not at all sure what it is you are even proposing here. Beeblebrox (talk) 04:32, 18 September 2015 (UTC)
I think that it's more critical for WhatLinksHere to allow to sort entries by name, first edit, last edit, number of edits, byte size, traffic, etc. Same with categories, or any arbitrary list. --NaBUru38 (talk) 22:54, 24 September 2015 (UTC)

consistent style usage on referring to the Catholic Church

Latest comment: 9 years ago6 comments5 people in discussion

Please make a global change in how Wikipedia refers to the Catholic Church.

Currently, moderators use the term "Roman Catholic Church", which is NOT how Catholics overwhelmingly refer to themselves.

Since the Catholic Church is comprised of 24 rites, only ONE of which is the Roman Rite, to refer to the whole as the "Roman Catholic Church" is entirely inappropriate and insulting to the other rites. Yes, the Church is 'headquartered' in the Vatican, which in Rome, but that does not justify labeling it as such. No one refers to the LDS church as the "Salt Lake City Church of Latter Day Saints".

"Roman" is at best an out-dated, archaic term. At worst, it is a subtle political label meant to qualify the Church as but one Catholic church among many (e.g. the Anglican Church). The insistence on denominating the Church as "Roman" seems to indicate a deep anti-Catholic, Protestant bias within Wikipedia. Anti-Catholic Protestants for centuries have insisted on denigrating the Catholic Church as merely "Roman". Terms such as "the Roman Church" and "Romanism" were used to smear the Church and cast it as foreign and particular, rather than universal. Since in the Apostles' Creed and Nicene Creed many profess belief in "one, holy, catholic, and apostolic Church" - many Protestants insisted on referring to the Catholic Church as simply the Roman Church. There is also an historical confusion with the Holy Roman Empire, which was a political kingdom unrelated to the Church.

Since there is no "official" name of the Church (it is simply the Church!), we must rely on common usage. Both historically and around the globe, the overwhelming usage of Catholics is to refer to the Church as the Catholic Church. Please update Wikipedia's terminology to reflect both fact and common usage as well as self-identified consensus.

Sincerely,

mnewhous

I always understood the "Roman" to refer to acknowledging the Roman Pontiff", not the Roman rite. There are now and have always been other rites in use. The problem with "Catholic Church" is that many other Christian denominations consider themselves Catholic. DGG ( talk ) 04:20, 24 September 2015 (UTC)
Mnewhous, Apart from
you'd like us to ditch the pillar of Wikipedia which requires neutrality and fall into line with (what you percieve to be) the RC view and start using a non-specific term? Shall we start referring to Mormons as Saints then, to fall in line with their usage? Or change all references to any faith to "the church"?
Context is everything. You may refer to the RC church as "the church", but would you do so if talking to a protestant and the context could be misconstrued? Would you refer to it as the Catholic church if you were talking to an Old Catholic? Well here, on Wikipedia, you're talking to everybody. Assume nothing, be specific. Regards, Bazj (talk) 14:26, 24 September 2015 (UTC)
I would generally assume a reference to the 'Roman Catholic Church' to be a reference to the largest Catholic church; whether or not it includes the other particular Catholic churches (such as the Maronites) - which in the narrowest sense it should not - depends on context. Insisting on the church's own usage as the only correct usage would seem to be unduly biased. (But then I'm an Anglo-Catholic, so I'm also biased.) AlexTiefling (talk) 14:31, 24 September 2015 (UTC)
Dear AlexTiefling, I seriously doubt that the original poster would "like us to ditch the neutrality pillar". If you think that renaming the "Roman Catholic Church" to "Catholic Church" wouldn't be neutral, please explain it politely. -NaBUru38 (talk) 23:06, 24 September 2015 (UTC)
NaBUru38, The comment you're complaining about is mine, not Alex's. Re-reading it, in its entirety, and in the context of Mnewhous' edit history and the cautions on his/her talk page, I'm quite content with the message. Bazj (talk) 08:38, 25 September 2015 (UTC)
Article titles can be a really hard thing to do neutrally, because there isn't the possibility of explaining the controversy in the title itself. You'll see that Catholic Church is the main article for the church, as you would desire, and Roman Catholic (term) explains the problems with names. I (not a Catholic-in-communion-with-the-bishop-of-Rome) agree that, in the absence of ambiguity, "Catholic" can be used to refer to the Church-in-communion-with-the-bishop-of-Rome. But there are times when ambiguity is present, and there the word "Roman" is not itself derogatory. (Though "the Roman Church", "the Church of Rome" and "Romanism" all are.) Indeed, the PCPCU use the word "Roman" where not to do so would cause offence/confusion.
Finally, note that "Roman Catholic" and "Latin Rite Catholic" are entirely different terms. There are "Roman Catholics" of other rites, and there are (arguably) Latin Rite Catholics who are not "Roman Catholic".
It's complicated and difficult, but I think Wikipedia's articles on the subject do a reasonably neutral job. Relentlessly (talk) 08:31, 25 September 2015 (UTC)

Change "px" to "upright="/"size percentage" for all infoboxes?

Latest comment: 9 years ago8 comments4 people in discussion

Now that we have size options, including newest "400px" option, for image display, we should respect people's image preferences per WP:IUP. Somehow, the model of using "px" in infoboxes is detrimental to others wanting to see a big (or small) image initially. Perhaps we should change settings from px to image size percentage/upright. Agree? --George Ho (talk) 06:46, 23 September 2015 (UTC)

@George Ho: It's been agreed to scrap the "upright" option for images in the next few months/years, so I'd recommend against that. Jdforrester (WMF) (talk) 08:41, 23 September 2015 (UTC)
If they decided to scrap out "upright" option, how would this affect WP:IUP? Are we gonna use "px" again for all users? --George Ho (talk) 08:45, 23 September 2015 (UTC)
@George Ho: I believe the aspiration is also to deprecate pixel-specifying too, and instead move to semantic image types, but that's not agreed yet (and I'm not working on it myself, sorry). There are more details at the RfC to which I linked. Jdforrester (WMF) (talk) 08:46, 23 September 2015 (UTC)
I don't think scrapping out "px" works well. It would affect very tiny icons, like flags and checkmarks. Reading that link, I wonder whether they were discussing frameless images (with or without |frameless|). --George Ho (talk) 08:57, 23 September 2015 (UTC)
@George Ho: It's quite a wide-ranging proposal to totally change how media transclusions work, yeah. Needs some serious thought, as you say. Jdforrester (WMF) (talk) 17:33, 23 September 2015 (UTC)

It's already bad that Template:Flag has different flag widths, just because it was preferred to have a standard height (if I'm not mistaken).

If fixed pixel parameters are removed, it would get even worse. --NaBUru38 (talk) 22:59, 24 September 2015 (UTC)

It's not true that flag icons "have a standard height". Both the width and the height are fixed (the default is 23x15px), so whichever size (23px width or 15px height) causes a smaller icon is used. The same list looks like this with fixed width:
And like this with fixed height:
WT:WPFT or Template talk:Flag would be a better place to discuss the default size of flag templates, though. SiBr4 (talk) 12:06, 25 September 2015 (UTC)

Allow the {{db-c1}} template to be removed by the creator

Latest comment: 9 years ago4 comments3 people in discussion

Should {{db-c1}} be able to be removed by the creator? Discuss below. --189.25.240.76 (talk) 16:11, 24 September 2015 (UTC)

Why? --Jayron32 12:02, 25 September 2015 (UTC)
I've removed speedy templates from template categories I created several times, where pages had actually been added but were not shown yet; e.g. this one. (When templates are categorized through their documentation subpages, they may not show up in the category until days or even weeks afterwards, because the job queue has to catch up.)
A more frequent scenario may be that a user creates a category, forgets (or doesn't know how) to add pages to it, sees the C1 tag after a few days, and only then adds pages to the category. SiBr4 (talk) 12:51, 25 September 2015 (UTC)
Then create the category page again. No big whoop. --Jayron32 16:07, 25 September 2015 (UTC)

OOUI for deletion confirmation

Latest comment: 9 years ago12 comments8 people in discussion

Recently, the move form has been switched to OOUI. The upload wizard will switch to OOUI next week. The deletion confirmation form (for administrators) should also be switched to OOUI. GeoffreyT2000 (talk) 15:58, 25 September 2015 (UTC)

@GeoffreyT2000: I've created T113758 for this; thanks for the reminder. Jdforrester (WMF) (talk) 16:49, 25 September 2015 (UTC)
@Jdforrester (WMF): What necessitates OOUI? Any form? Any form with multiple end states? I'm thinking special:log and special:Contributions off the cuff, though special:preferences has a button here or there. Special:MIMESearch too? Maybe someone should scrub the Special:Specialpages. There didn't seem to be a task for all of those. --Izno (talk) 17:24, 25 September 2015 (UTC)
@Izno: The plan is to eventually replace every UI interface component with OOUI, and delete e.g. jQuery.UI and other deprecated systems. T100161 is the overall ticket for converting all of MediaWiki. T107037 is for all special pages, but there aren't yet sub-tickets for Log, Contributions or indeed most of them. Jdforrester (WMF) (talk) 11:35, 26 September 2015 (UTC)
Would this discussion be better suited for WP:VPT. Your magical incantations don't really make much sense to us Muggles, and you're likely to get better participation from more knowledgeable people over there. --Jayron32 17:35, 25 September 2015 (UTC)
@Jayron32: VPT isn't the right venue either for asking for participation for writing code; input is welcome in the form of git patches, which go on gerrit:. :-) Jdforrester (WMF) (talk) 11:35, 26 September 2015 (UTC)
Ok. I'll bite. What the heck is an OOUI? And that gerritt thing; is that in the same family as a ferret? GenQuest "Talk to Me" 11:48, 26 September 2015 (UTC)
OOUI. "Gerrit" is the given name of Gerrit Rietveld. --83.255.51.226 (talk) 08:17, 29 September 2015 (UTC)

Can someone explain to me what the benefit of "OOUI" is? I've read the article linked above, but I fail to see how the new move form is more "object-oriented" than the old one. Jenks24 (talk) 14:23, 29 September 2015 (UTC)

OOUI when in the context of MediaWiki refers to OOjs UI (demo). This is a modern widget toolkit written with the goals of MediaWiki and Wikipedia in mind. It can be generated in both PHP and Javascript, is accessible, consistent, skinnable, mobile optimized etc. It also allows for easy creation of MediaWiki specific widgets such as an input field for Article titles with autocompletion. It's first user was Visual Editor and the long term plan is that this will be used for all controls at some point. The idea is that not every developer has to reinvent the wheel. You use what is in OOUI already, or you build something new on the foundations that this platform provides you, but you don't start from scratch. —TheDJ (talk • contribs) 15:54, 29 September 2015 (UTC)
Thanks for the response. So basically it makes things easier for devs? And also it would be nice for things to be consistent? Both of these seem like good things so that's fine. But the change to the move interface has made my work here more difficult. I've now had to file two bugs about it and even once they are both fixed, the old interface will still have been quicker for me (and most others, I assume) to use. Is there any guarantee a change to the deletion interface won't have the same problems? Or am I understating how useful this is on the backend and these minor hassles for editors are worth it? (I realise you, TheDJ, might not necessarily have answers to these questions, they're more general for anyone with knowledge on the subject.) Jenks24 (talk) 16:46, 29 September 2015 (UTC)
Let's put it like this: I'm sure you love your house full of unique, handcrafted, slightly imperfect yet beautiful, efficient and very expensive furniture, but IKEA has a lot of benefits to it. Currently a lot of community requests are about making things more 'interactive', 'smarter', 'n00b proof' etc. But without changing some fundamentals, many of those requests are actually difficult and expensive to implement consistently in multiple areas of the wiki, for multiple target audiences and multiple target devices (and not breaking on browsers without Javascript). OOjs UI will create new handles for both community and developers to provide some of those changes. —TheDJ (talk • contribs) 17:36, 29 September 2015 (UTC)

Prefix suggestion: TP: for Template:

Latest comment: 9 years ago21 comments16 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is no consensus for this proposal. The arguments on both sides are good, but the arguments are pretty evenly split. AlbinoFerret 20:39, 29 September 2015 (UTC)

My idea is so that we could make search "fstr". We already have WP: for Wikipedia:, so let us have that prefix. Gamingforfun365 (talk) 01:26, 30 August 2015 (UTC)

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

We Have Created a Timeline for Every English language Wikipedia Article.

Latest comment: 9 years ago15 comments5 people in discussion

To: WhatamIdoing, Mdennis (WMF), Jimbo Wales, iridescent, User:Coren

We have accomplished the task of creating a visual, scrolling timeline of every Wikipedia article. Of course, not every article is historical in nature. Of the 5,000,000 English Wikipedia articles, our estimates are that around 250,000 could use a decent visual, contemporaneous presentation. That is a lot of timelines. We believe it would be one of the most exciting things to happen to history, on the internet, in a long time.

We have put a (mind blowing) demo together at:

http://wikitimelines.net/

In regards to potentially placing timelines on select Wikipedia articles. It would be just 1 small SCRIPT tag and 1 small DIV tag, per Wikipedia article.

It is surprisingly simple to do now.

All I am asking for is a Wikipedia server to install this on. Wikipedia would, of course, have complete authentication authority over this server. This will take less than one day to do.

OR:

I could give Wikipedia.org authentication authority over my "Amazon Web Services" server and Wikipedia would give me permission to use it (I will even pay for it).

Then we can test it on 1 Wikipedia.org article and see what happens.

We cannot believe how well this turned out. We can't stop timelining Wikipedia articles, it is so compelling and fun.

I forgot to mention. This whole thing is NEW. Nobody has ever seen this as of today (making timelines out of Wikipedia articles). We have only shown this technology to like 3 other people.

Thanks Jeff Roehl

Jroehl (talk) 21:54, 13 September 2015 (UTC)
Have you considered making this tool work using dumps of the Wikipedia database or other "local copy" of Wikipedia? davidwr/(talk)/(contribs) 23:16, 13 September 2015 (UTC)
To davidwr
I am not sure what you mean by: "dumps of the Wikipedia database"
Can you be more specific?
Thanks
Jeff Roehl
Jroehl (talk) 23:46, 13 September 2015 (UTC)
See Wikipedia:Database download. davidwr/(talk)/(contribs) 00:30, 14 September 2015 (UTC)

David = davidwr,

Yes, I would like to get the data from wherever Wikipedia is getting it. If we could get this to run on the same rackspace as the core of Wikipedia. That would be super-fast. And it would be very inexpensive, not taking any TCP/IP resources. Could I get the data in HTML? I am not sure if you guys take your Wiki language and immediately parse out the HTML on an article edit/save. My widget is pretty straight forward. It is aware of what page it is on. So if we placed the widget on:

https://en.wikipedia.org/wiki/Queen_Victoria

And the widget was on a LAN at Wikipedia, this could be translated as:

c:\wikidata\articles\Queen_Victoria\index.htm


Or what ever it is there and serve it out to the user. The key to me is to parse out the current version of the article. So the timeline will exactly match the article every single time. All I need to do is pull the article (locally) and pull the paragraphs out of the article. If I can pull the article in milliseconds, it would be super fast. The slowest part would be serving up the javascript to the widget on the users page. So all I would need is a big outbound pipe.

And I really don't need a lot of diskspace. My biggest worry, in processing millions of timelines a day is deletion of temporary files and releasing that diskspace back to the operating system. Each request for a timeline will produce 5 or so temporary files (SQL output). But those will be deleted within milliseconds after processing. We just have to make sure they are getting deleted. I can set the location of the temporary file location, so we can monitor this.

I may be able to write the system to work with no disk writes (convert all the tables to memory arrays), but that would be a LOT of work. That would be a multi week thing, for sure. So we should leave it the way it is now and see if it ramps up well.

Just my professional assessment, your experience may be different.

Thanks Jeff Roehl Jroehl (talk) 16:01, 14 September 2015 (UTC)

David = davidwr,

One more thing. Of course we don't want a timeline loading up on a historical Wikipedia article, every time it is accessed. What we really like is the "collapseButton" span tags, usually at the bottom of substantial articles. They are very classy. All we would have to do is add a "collapseButton" to the Queen Victoria page and put my SCRIPT tag and DIV tag in there. So when you opened up the "collapseButton" the widget JavaScript would be fired off and populate this area with the timeline HTML and JavaScript.

And if we could get my brilliant http://184.72.231.130/load1.js to fire at that point it would be all "no worries" after that.

Of course, the problem with this is the "collapseButton" controls are way at the bottom of the Wikipedia pages. I mean WAY down at the bottom. Below the Citations. And that is not good for "our team". Then again, timelines in Wikipedia may be so compelling that everybody might know where they are, by word of mouth, within a short time.

Thanks Jeff Roehl Jroehl (talk) 17:07, 14 September 2015 (UTC)

I tried it on Timeline of women's basketball for which it would seem to be uniquely well-suited. It was a bust. Did I do something wrong?--S Philbrick(Talk) 19:20, 15 September 2015 (UTC)
No S Philbrick you did nothing wrong. As of this writing, for the sake of speed and narrative content, we are only placing data on the timeline that is part of a paragraph in any Wikipedia article. That is any content that inside paragraph tags. We will eventually have to write a separate parser for "Wikipedia timelines". One issue is there is no standard format for Wikipedia timeline lists, so it is a trick to parse them. We will be happy to do this, even to the point of writing a program to re-write all Wikipedia timelines into one standard format. Try https://en.wikipedia.org/wiki/Women%27s_basketball which has some paragraph tags with content.
Thanks
Jeff Roehl Jroehl (talk) 18:06, 18 September 2015 (UTC)
I also recall seeing this a few weeks ago despite the claim that it's new today. I didn't save the link to the discussion and can't seem to find it easily at the moment. Found it Wikipedia:Village_pump_(proposals)/Archive_126#I_would_like_to_put_a_timeline_on_a_wikipedia_page I know there was discussion about getting the Foundation involved so I'd like to hear what is happening on that front.--S Philbrick(Talk) 19:24, 15 September 2015 (UTC)

Yes S Philbrick not much has happened. Rome wasn't built in a day. All we are requesting is 1 computer to display 1 timeline on 1 Wikipedia article. And then we might see where this goes. We have a 6 month period of time chunked out right now where we can focus on this. From 15 October 2015 to 15 March 2015, possibly 8 hours a day or 1000 hours (if not total hours of work, but our undivided attention and full measure of our devotion). I can't guarantee resources like this will be available after that. I think timelines would be much better understood if we could place a timeline on 10 Wikipedia pages. Then we could debate this content and then possibly take a consensus vote on inclusion. Some articles make better timelines than others and consensus would dictate inclusion in any article.

All we need is 1 server that "The Foundation" has administrative privileges/authentication on, whether that is a server we pay for or not. That is not a very big first step.

We are also going to write a grant application for this and related endeavors (also within the scope of the 1000 hours mentioned above). Any help with this would also be greatly appreciated. So anybody who knows of any organizations issuing grants for "Comparative History" or history in general, give us a heads up on that.

Thanks Jeff Roehl Jroehl (talk) 18:42, 18 September 2015 (UTC)

Who would make the decision to put 1 timeline on 1 article in Wikipedia?

Thanks Jeff Roehl 64.39.94.189 (talk) 17:11, 23 September 2015 (UTC)

Ok, lets go back a step.

Who would make a decision to allow me to install and configure a Wikipedia server with my timelining widget software backend?

Jroehl (talk) 15:20, 27 September 2015 (UTC)

It … doesn't work like that. I'd recommend installing a copy of your software on your own server and using the API to retrieve content on which to render a timeline. If that works well, your next step would presumably be to rewrite your software as a MediaWiki extension (and make it free and open-source if it isn't already), and then campaign for it to be added to Wikipedia proper. {{Nihiltres |talk |edits}} 17:34, 27 September 2015 (UTC)

Thankyou Nihiltres. I will have my guys look into this. Doing something like this, you never know until somebody tells you how things work. Jroehl (talk) 14:52, 30 September 2015 (UTC)

And we took the demonstration site down for now. Jroehl (talk) 15:52, 30 September 2015 (UTC)

Motion: AUSC Extension

Latest comment: 9 years ago1 comment1 person in discussion

The Arbitration Committee is currently examining several reforms of the Audit Subcommittee and asks for community input on how they would like to see the Subcommittee function in the future. Because of this, the current Audit Subcommittee (AUSC) members' terms are hereby extended to 23:59, 30 September 2015 (UTC).

Supporting: AGK, Doug Weller, GorillaWarfare, Guerillero, LFaraone, NativeForeigner, Salvio giuliano, Thryduulf, Yunshui
Opposing: Courcelles

For the Arbitration Committee, --Guerillero | Parlez Moi 02:10, 5 September 2015 (UTC)

Discuss this and the future of the AUSC at: Wikipedia talk:Arbitration Committee/Noticeboard#Motion: AUSC Extension

Direct links to Commons edit page

Latest comment: 9 years ago1 comment1 person in discussion

When you attempt to create a description page here for an image that's on Commons, you're presented with the message from MediaWiki:Sharedupload-desc-create, basically a little warning of "This image is on Commons, so please don't create this page", and a link to the Commons URL is provided. See [8] for an example of this message in use. I went to WP:HD asking how to change the URL. Right now, when you go to File:Armed Klansman in southeastern Ohio, 1987.jpg and try to edit its page, the URL in the message is [9], while I was planning to edit the MediaWiki page so that it instead went to [10], the edit page instead of the description page. PrimeHunter gave me the code, but he also opposed the idea, so I'm not going to make the change without chatting here first.

Proposal Change the URL in the MediaWiki page so that it sends you directly to the screen to edit the Commons description page, rather than sending you to the page itself. My rationale was "it seems reasonable that the typical person editing the page was intending to edit the Commons page, so it will save a step by sending them directly to the edit page instead of making them detour through the description page." PrimeHunter opposed with "[the local file] is missing several features on [the Commons description page] such as Commons categories, section edit links, History tab, and links to the uploader and their contributions...I don't like the idea of cross-wiki edit links. I think users should at least view a wiki before trying to edit it. I wouldn't want Commons or other wikis to have direct edit links to us."

So which is it? Should we change the link as I want it, or keep it unchanged, or modify some other way? Nyttend (talk) 00:33, 2 October 2015 (UTC)

Delete talk page and/or subpages when moving

Latest comment: 9 years ago6 comments4 people in discussion
Tracked in Phabricator
Task T20260
Tracked in Phabricator
Task T67479

When an administrator moves a page, an existing talk page under the new title should be deleted if the "Move associated talk page" box is checked. Also, existing subpages of the new title should be deleted if the "Move subpages" box is checked, and if the "Move associated talk page" box is checked, also subpages of the talk page. GeoffreyT2000 (talk) 14:33, 1 October 2015 (UTC)

Not quite [edit: "Not quite agreeing with everything"], but if the "Delete this page" is marked for the article, it should delete the old talk page and move the new one. I'm often opposed to this kind of thing [edit: "I'm often opposed to proposals of this sort, because they enable foolish or uninformed editors to do stupid things"], but here the admin can always just delete the talk page and do the move manually: your proposal wouldn't do much to retard the foolish admin, but it would make it a lot simpler for ordinary moves. I am, however, opposed to deleting subpages: unlike main talk pages, talk page subpages are very easy to overlook, very easy to miss by accident, because if nothing else they don't cause tabs to change from red to blue. I don't want to run the risk of trashing subpages that I never knew about, especially because the pages to be deleted are pages that I might never have seen or edited. Nyttend (talk) 00:39, 2 October 2015 (UTC)
Completely agreed with Nyttend. A tick box to also 'delete and move' for the talk page would be handy, but having it for subpages is a recipe for disaster, especially in cases where a page and its subpages have been moved back and forth – you'd end up with cases where the actual content is deleted to move a redirect over the top of it. Jenks24 (talk) 01:13, 2 October 2015 (UTC)
I've interpolated a couple of things just now, so Jenks' comments don't necessarily apply to them. Nyttend (talk) 12:20, 2 October 2015 (UTC)
Rather than enabling automatic deletion, I think it would be better if the UI could provide an alert that sub-pages exist and that the person moving should assess what should be done with them. older ≠ wiser 12:45, 2 October 2015 (UTC)
Yes, that's a good idea. Both currently and under this proposal, the only effect of having subpages is the extra check box to "Move subpages (up to 100), if applicable". It would be quite helpful if we had an automated notice saying that subpages exist. Nyttend (talk) 13:15, 2 October 2015 (UTC)

Talk:Main_Page#Proposal:_Remove_WP:In_the_news_from_the_main_page.

Latest comment: 9 years ago1 comment1 person in discussion

Giving a courtesy link to the poll. Adam Cuerden (talk) 10:30, 3 October 2015 (UTC)

Properly delete user and user talk pages when renaming

Latest comment: 9 years ago1 comment1 person in discussion
Tracked in Phabricator
Task T97536

When renaming a user, existing user pages, user talk pages, and their subpages under the new username should be properly deleted with MediaWiki:Delete and move reason (on each individual wiki) for the reason. Currently, the existing pages have no deletion log and the moves are "over redirect". GeoffreyT2000 (talk) 03:49, 7 October 2015 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_127&oldid=1142561005"